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

[craigdo@ee.washington.edu]

[ ... ]

> > 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.

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.

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
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).

My main point is that I think there should be two different values
somewhere.  Perhaps MTU and SDU was the wrong choice -- my background has me
being more wire-centric.  Perhaps it is MTU (which is taken to mean payload
length) and something else entirely that is hardware dependent.  Perhaps the
choice is to make the hardware limit an internal driver hard-coded thing
since this will indeed be device dependent.  Then we could document the MTU
as being an MTU only in the sense of payload.  We could then make SetMtu and
GetMtu consistent, with SetMtu failing (asserting) if the payload +
internally added headers, etc., exceeded the internal driver MTU in the
sense of total bits allowed on the wire.  In this case there wouldn't be an
MTU attribute that one would be drawn to think of as being set to 1,500.

Sound right?
 
[ ... ]

> I suggest the default for Csma should be the DIX frame 
> variant, not the 
> LLC.  

I think this is correct.  I was surprised when I saw LLC/SNAP instead of DIX
when I first looked at the csma code.

> We call this "IpArp" encapsulation, I believe.  

I was also surprised at this choice of naming ...

> Maybe 
> this should 
> be renamed to DIX or Ethernet II, or at least commented as such.
> 
> http://en.wikipedia.org/wiki/Ethernet_II_framing
> 
> Of course, ns-3 Csma is not truly Ethernet but we probably 
> are going to 
> treat it as such for now and people will put the traces 
> through Wireshark.

This is the key ...