[Ns-developers] Csma, ethernet length field, NSC and the link mtu...

[Mathieu Lacage]

On Wed, 2008-07-23 at 12:39 -0700, craigdo at ee.washington.edu wrote:

> > > Now, there's the question of MTU.  The Ethernet MTU is 1500 
> > bytes.  The MTU
> > > is 1500 bytes independent of what kind of headers and 
> > trailers are added by
> > > the device, right?
> > 
> > No, MTU is the maximum IP packet size carred by the device.  If the 
> > device has different headers/trailers (such as LLC/SNAP), the MTU 
> > changes accordingly.
> 
> Okay.  Let me be more specific about the problem I wanted to address.  I'm
> concerned about consistency in setting and getting MTUs with slightly
> different semantics.
> 
> I've worked with networks in an environment where a critical issue was the
> number of bits that can go on the wire as determined by underlying hardware.
> This interpretation leads to an Ethernet MTU being fixed at 1,500 bytes; ATM
> MTUs being fixed at 48 bytes and other random hardware-defined
> point-to-point links having fixed MTU of around 2,000 bytes.  
>
>
> Another sense of MTU I have run into is the number of bytes of payload that
> higher levels can put into frames moving across a link.  This is the sense
> that you are using above.  These are not necessarily the same.  My point is
> that we need to avoid confusing them, or helping users confuse them.

Sure but NetDevice::GetMtu is about the number of bytes of payload
higher levels can put into frames moving across the link. The other
thing you refer to is a PHY-level concept which higher layers should not
have anything to do with.

> So, let me work through how this would be used at bit:  First, the subject
> came up regarding an MTU attribute that would be associated with a net
> device.  If I was thinking about this attribute, for Ethernet I would
> intuitively expect this to default to 1500 bytes.  This is the value tossed
> around by pretty much all the literature since the beginning of time.  If I
> set the attribute to 1500 bytes, I would expect to be able to see packets of
> 1500 bytes on my link.

The NetDevice object abstracts the MAC+PHY layer. The MTU reported by
the NetDevice is the MAC layer MTU, not the PHY layer MTU. So, what you
see on the physical link does not necessarily have anything to do with
what you specified with NetDevice::Set/GetMtu.

> However, if we really use the payload interpretation of MTU, and the csma
> net device also used LLC/SNAP it would mean either 1) the net device would
> have to *mysteriously* fail since we would be trying to send 1508 bytes or

::Send should not fail if the caller conforms to GetMtu. If the caller
does not conform, it could fail.

> 2) the real payload is eight bytes less than the MTU just set.  In this
> case, a client who called GetMtu would need to receive 1492 after she just
> set MTU to 1500.  That seems quite counter-intuitive.  Clearly there needs
> to be consistency and independence from the protocol implementation of the
> net device (the client shouldn't have to understand that there is an active
> LLC/SNAP option and that he has got to correct values passed to SetMtu to
> get the right result).

SetMtu is expected to fail and return false if the value given is not
compatible with the configuration of the underlying device. Now, if you
make the Mtu an attribute, you will need to make sure that setting that
value through the attribute system conforms to the device's bounds and,
if these bounds are not static (as is the case for the csma netdevice
which can be dynamically configured to behave in different ways), you
will have to provide your own implementation of AttributeChecker which
performs bounds checking based on the device's configuration.

Mathieu