Csma, ethernet length field, NSC and the link mtu...

[Florian Westphal-4]

Hello ns-3 developers,

i'm currently writing a few ns-3 simulations to
demonstrate some of NSCs features.

I have encountered the following problem:
In my script[1], i'm building a simple csma network with a few TCP flows.
Now, all the trace files look bogus when viewed with tools like
tcpdump or wiresharhark, that is, I often see 'Ethernet 2 Frames'
without tcpdump or wireshark decoding the next protocol header.

The problem is that the MTU that is currently hardcoded
to 1500 byte in nsc is too large.
(I'd like to use the actual device MTU, but ->GetMtu()
just returns 0xFFFF...)

Now, length values are not allowed to exceed 1500 bytes
when a 802.3 LLC header is added (Values above are reserved for
Type-Ids).

Now, i worked around this by hardcoding an MTU of 1482.
This still looked strange to me, as this would not show
1514 bytes for the whole ethernet packet, as i expected.

So, i took a look at the csma code.

In CsmaNetDevice::AddHeader we have this:
    case LLC: {
      lengthType = p->GetSize () + header.GetSerializedSize () +
        trailer.GetSerializedSize ();
      LlcSnapHeader llc;
      llc.SetType (protocolNumber);
      p->AddHeader (llc);
    } break;

This looks bogus -- Why is the LLC header size ignored?
And is the ethernet header really expected to be accounted for in the length field?
Also, could we add an NS_ASSERT in there that checks that the length is <= 1500 inside
the LLC label?

If I replace that header.GetSerializedSize() with an llc.GetSerializedSize()
the tcpdump/wireshark outputs look much saner to me, i.e.
I see an 1514 byte ethernet frame with a length field of 1500.

Of course this doesn't solve my actual problem, namely
how do I avoid hardcoding MTU values in the nsc glue?

Thoughts?
Regards, Florian

[1] http://strlen.de/fw/tcp-nsc-zoo.cc
--
Florian Westphal <fw@...> // http://www.strlen.de
1024D/F260502D 2005-10-20
Key fingerprint = 1C81 1AD5 EA8F 3047 7555  E8EE 5E2F DA6C F260 502D

[Mathieu Lacage]

On Wed, 2008-07-23 at 01:08 +0200, Florian Westphal wrote:

> Hello ns-3 developers,
>
> i'm currently writing a few ns-3 simulations to
> demonstrate some of NSCs features.
>
> I have encountered the following problem:
> In my script[1], i'm building a simple csma network with a few TCP flows.
> Now, all the trace files look bogus when viewed with tools like
> tcpdump or wiresharhark, that is, I often see 'Ethernet 2 Frames'
> without tcpdump or wireshark decoding the next protocol header.
>
> The problem is that the MTU that is currently hardcoded
> to 1500 byte in nsc is too large.
> (I'd like to use the actual device MTU, but ->GetMtu()
> just returns 0xFFFF...)

This looks like a bug in the csma code which, indeeds, hardcodes this
value to 0xffff. A patch to make that be an attribute and maybe change
it to a more sane default value would be probably a step in the right
direction.

> Now, length values are not allowed to exceed 1500 bytes
> when a 802.3 LLC header is added (Values above are reserved for
> Type-Ids).
>
> Now, i worked around this by hardcoding an MTU of 1482.
> This still looked strange to me, as this would not show
> 1514 bytes for the whole ethernet packet, as i expected.
>
> So, i took a look at the csma code.
>
> In CsmaNetDevice::AddHeader we have this:
>     case LLC: {
>       lengthType = p->GetSize () + header.GetSerializedSize () +
>         trailer.GetSerializedSize ();
>       LlcSnapHeader llc;
>       llc.SetType (protocolNumber);
>       p->AddHeader (llc);
>     } break;
>
> This looks bogus -- Why is the LLC header size ignored?
> And is the ethernet header really expected to be accounted for in the length field?

no idea.

> Also, could we add an NS_ASSERT in there that checks that the length is <= 1500 inside
> the LLC label?

+1

>
> If I replace that header.GetSerializedSize() with an llc.GetSerializedSize()
> the tcpdump/wireshark outputs look much saner to me, i.e.
> I see an 1514 byte ethernet frame with a length field of 1500.
>
> Of course this doesn't solve my actual problem, namely
> how do I avoid hardcoding MTU values in the nsc glue?

CsmaNetDevice::GetMtu should return the right value.

Mathieu

[craigdo]

> > In CsmaNetDevice::AddHeader we have this:
> >     case LLC: {
> >       lengthType = p->GetSize () + header.GetSerializedSize () +
> >         trailer.GetSerializedSize ();
> >       LlcSnapHeader llc;
> >       llc.SetType (protocolNumber);
> >       p->AddHeader (llc);
> >     } break;
> >
> > This looks bogus -- Why is the LLC header size ignored?
> > And is the ethernet header really expected to be accounted
> for in the length field?
>
> no idea.

This seems wrong to me.  The LlcSnapHeader header comes after the
dst/src/length and consumes eight bytes.  This means the maximum payload
should be reduced to 1492 bytes when LLC/SNAP encapsulation is used.  

The EthernetHeader (header in the code above) represents the dst/src/length
of the packet.  The LLC + SNAP header represents the LLC part
(DSAP/SSAP/HDLC Mode) and the SNAP part (ORG/EtherType).  So my take is that
the above code should really be,

      LlcSnapHeader llc;
      llc.SetType (protocolNumber);
      p->AddHeader (llc);
      lengthType = header.GetSerializedSize () + llc.GetSerializedSize +
        p->GetSize () + trailer.GetSerializedSize ();

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?

Aren't we really talking about having an MTU of 1500 bytes and a maximum SDU
(service data unit) of 1492 bytes in this case?  Is that being too pedantic?

I can take care of getting the counts right, putting in a rational MTU and
updating the regression traces tomorrow AM.

I'm thinking that we should add a GetSdu to net-device.h that works with the
current MTU and mode and returns a max payload value that can be used by
clients.  This probably also applies to the point-to-point device since I
remember adding a ppp header but not finding any place to reduce a payload
(it also has a 0xffff MTU where this all probably descended from).  Wifi
too?

-- Craig

[Florian Westphal-4]

craigdo@... <craigdo@...> wrote:

> > > In CsmaNetDevice::AddHeader we have this:
> > >     case LLC: {
> > >       lengthType = p->GetSize () + header.GetSerializedSize () +
> > >         trailer.GetSerializedSize ();
> > >       LlcSnapHeader llc;
> > >       llc.SetType (protocolNumber);
> > >       p->AddHeader (llc);
> > >     } break;
> > >
> > > This looks bogus -- Why is the LLC header size ignored?
> > > And is the ethernet header really expected to be accounted
> > for in the length field?
> >
> > no idea.
>
> This seems wrong to me.

[..]

> The EthernetHeader (header in the code above) represents the dst/src/length
> of the packet.  The LLC + SNAP header represents the LLC part
> (DSAP/SSAP/HDLC Mode) and the SNAP part (ORG/EtherType).  So my take is that
> the above code should really be,
>
>       LlcSnapHeader llc;
>       llc.SetType (protocolNumber);
>       p->AddHeader (llc);
>       lengthType = header.GetSerializedSize () + llc.GetSerializedSize +
>         p->GetSize () + trailer.GetSerializedSize ();
>
> 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?

Yes, but I'd like fix this up properly. I'm too tired right now to read
docs, i'll check this tomorrow (i'm fairly certain the ethernet header
doesn't belong there; think about it -- if you're not using LLC, there
is no length field in the first place, and if you use LLC adding the
ethernet header length reduces the maximum data you can carry by 14 bytes,
since the length field isn't allowed to exceed 1500).

I'll check literature & some OS implementations tomorrow to make sure
that we have something that at least tries to stay in touch with
reality...

Thanks, Florian

[craigdo]

> Yes, but I'd like fix this up properly. I'm too tired right
> now to read
> docs, i'll check this tomorrow (i'm fairly certain the ethernet header
> doesn't belong there; think about it -- if you're not using LLC, there
> is no length field in the first place, and if you use LLC adding the
> ethernet header length reduces the maximum data you can carry
> by 14 bytes,
> since the length field isn't allowed to exceed 1500).

See RFC 1042, page two.  First comes 802.3 MAC, then 802.2 LLC then 802.2
SNAP.

> I'll check literature & some OS implementations tomorrow to make sure
> that we have something that at least tries to stay in touch with
> reality...

I'm a dinosaur.  It's possible there's something newer than RFC 1042 that I
don't know about.

BTW, reality is overrated :-)

-- Craig
 

[Mathieu Lacage]

On Tue, 2008-07-22 at 17:47 -0700, craigdo@... wrote:

> I'm thinking that we should add a GetSdu to net-device.h that works with the
> current MTU and mode and returns a max payload value that can be used by
> clients.  This probably also applies to the point-to-point device since I

I don't really see what you would use this getsdu thing for:
NetDevice::GetMtu should return the max size of data you can give to
NetDevice::Send* methods. What else do you need from the point of view
of the client ?

> remember adding a ppp header but not finding any place to reduce a payload
> (it also has a 0xffff MTU where this all probably descended from).  Wifi
> too?

No, wifi should get this right for now (I think).

Mathieu

[Tom Henderson-2]

craigdo@... wrote:

>>> In CsmaNetDevice::AddHeader we have this:
>>>     case LLC: {
>>>       lengthType = p->GetSize () + header.GetSerializedSize () +
>>>         trailer.GetSerializedSize ();
>>>       LlcSnapHeader llc;
>>>       llc.SetType (protocolNumber);
>>>       p->AddHeader (llc);
>>>     } break;
>>>
>>> This looks bogus -- Why is the LLC header size ignored?
>>> And is the ethernet header really expected to be accounted
>> for in the length field?
>>
>> no idea.
>
> This seems wrong to me.  The LlcSnapHeader header comes after the
> dst/src/length and consumes eight bytes.  This means the maximum payload
> should be reduced to 1492 bytes when LLC/SNAP encapsulation is used.  
>
> The EthernetHeader (header in the code above) represents the dst/src/length
> of the packet.  The LLC + SNAP header represents the LLC part
> (DSAP/SSAP/HDLC Mode) and the SNAP part (ORG/EtherType).  So my take is that
> the above code should really be,
>
>       LlcSnapHeader llc;
>       llc.SetType (protocolNumber);
>       p->AddHeader (llc);
>       lengthType = header.GetSerializedSize () + llc.GetSerializedSize +
>         p->GetSize () + trailer.GetSerializedSize ();
>
> 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.

>
> Aren't we really talking about having an MTU of 1500 bytes and a maximum SDU
> (service data unit) of 1492 bytes in this case?  Is that being too pedantic?

I think we are talking about having an MTU of 1500 when IpArp
encapsulation is used, and an MTU of 1492 bytes when LLC/SNAP
encapsulation is used.

>
> I can take care of getting the counts right, putting in a rational MTU and
> updating the regression traces tomorrow AM.
>
> I'm thinking that we should add a GetSdu to net-device.h that works with the
> current MTU and mode and returns a max payload value that can be used by
> clients.  This probably also applies to the point-to-point device since I
> remember adding a ppp header but not finding any place to reduce a payload
> (it also has a 0xffff MTU where this all probably descended from).  Wifi
> too?
>

I do not think that adding SDU really adds anything.  The MTU is the
Ethernet SDU, but I haven't typically heard the SDU/PDU terminology when
talking about TCP/IP.

I suggest the default for Csma should be the DIX frame variant, not the
LLC.  We call this "IpArp" encapsulation, I believe.  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.

Tom

[Florian Westphal-4]

craigdo@... <craigdo@...> wrote:

> > Yes, but I'd like fix this up properly. I'm too tired right
> > now to read
> > docs, i'll check this tomorrow (i'm fairly certain the ethernet header
> > doesn't belong there; think about it -- if you're not using LLC, there
> > is no length field in the first place, and if you use LLC adding the
> > ethernet header length reduces the maximum data you can carry
> > by 14 bytes,
> > since the length field isn't allowed to exceed 1500).
>
> See RFC 1042, page two.  First comes 802.3 MAC, then 802.2 LLC then 802.2
> SNAP.

Yes, but when you look at page 6 (For IEEE 802.3), it says:

"This allows 1518 - 18 (MAC header+trailer) - 8 (LLC+SNAP header) =
1492 for the IP datagram (including the IP header).  Note that
1492 is not equal to 1500 which is the MTU for Ethernet networks."

Also,
http://standards.ieee.org/getieee802/download/802.3-2005_section1.pdf
Section 3.2.6
a) says:
[..] indicates the number of MAC client data octets contained
in the _subsequent_ data field of the frame [..] (emphasis mine)

In fact, 'data field' sounds to me as if the trailer doesn't belong there
either.
Just using llc header length and the payload size results in
1500 (maximum length allowed) - 8 (llc header length) = 1492 (for the
actual payload without Llc header)  which conveniently matches the
RFC 1042 quote above.
I propose something like this:

csma: Fix LLC header length calculation

Must only count the actual data payload (including LLC header).
The ethernet header/trailer must not be counted.

Also, add NS_ASSERT to make sure the LLC length does not exceed the 1500
byte limit.

diff -r 6cd7d91ba8c8 -r 8101ec181e2b src/devices/csma/csma-net-device.cc
--- a/src/devices/csma/csma-net-device.cc Tue Jul 22 20:09:07 2008 +0200
+++ b/src/devices/csma/csma-net-device.cc Wed Jul 24 14:04:32 2008 +0200
@@ -201,11 +201,16 @@
       lengthType = protocolNumber;
       break;
     case LLC: {
-      lengthType = p->GetSize () + header.GetSerializedSize () +
-        trailer.GetSerializedSize ();
       LlcSnapHeader llc;
       llc.SetType (protocolNumber);
       p->AddHeader (llc);
+      /*
+       * the ethernet header and trailer are not counted, see RFC 1042 and
+       * http://standards.ieee.org/getieee802/download/802.3-2005_section1.pdf,
+       * Section 3.2.6 a)
+       */
+      lengthType = p->GetSize ();
+      NS_ASSERT_MSG (lengthType <= 1500, "802.3/LLC length must not exceed 1500; reduce MTU");
     } break;
     case RAW:
       NS_ASSERT (false);

[craigdo]

> > See RFC 1042, page two.  First comes 802.3 MAC, then 802.2
> LLC then 802.2
> > SNAP.
>
> Yes, but when you look at page 6 (For IEEE 802.3), it says:
>
> "This allows 1518 - 18 (MAC header+trailer) - 8 (LLC+SNAP header) =
> 1492 for the IP datagram (including the IP header).  Note that
> 1492 is not equal to 1500 which is the MTU for Ethernet networks."

Isn't this a paraphrase of what I wrote earlier:

"The LlcSnapHeader header comes after the dst/src/length and consumes eight
bytes.  This means the maximum payload should be reduced to 1492 bytes when
LLC/SNAP encapsulation is used."

and

"Aren't we really talking about having an MTU of 1500 bytes and a maximum
SDU
(service data unit) of 1492 bytes in this case?  Is that being too
pedantic?"

> Also,
> http://standards.ieee.org/getieee802/download/802.3-2005_section1.pdf
> Section 3.2.6
> a) says:
> [..] indicates the number of MAC client data octets contained
> in the _subsequent_ data field of the frame [..] (emphasis mine)
>
> In fact, 'data field' sounds to me as if the trailer doesn't
> belong there
> either.
> Just using llc header length and the payload size results in
> 1500 (maximum length allowed) - 8 (llc header length) = 1492 (for the
> actual payload without Llc header)  which conveniently matches the
> RFC 1042 quote above.
> I propose something like this:
>
> csma: Fix LLC header length calculation
>
> Must only count the actual data payload (including LLC header).
> The ethernet header/trailer must not be counted.

Oh, okay.  I see.  You are not really talking about how the packet should be
formed -- we agree on that; you are saying that not only does the code not
count the LLC header, it wrongly adds the lengths of the mac header and FCS
to the length.

That does seem to be the case ...
 

> Also, add NS_ASSERT to make sure the LLC length does not
> exceed the 1500
> byte limit.
>
> diff -r 6cd7d91ba8c8 -r 8101ec181e2b
> src/devices/csma/csma-net-device.cc
> --- a/src/devices/csma/csma-net-device.cc Tue Jul 22
> 20:09:07 2008 +0200
> +++ b/src/devices/csma/csma-net-device.cc Wed Jul 24
> 14:04:32 2008 +0200
> @@ -201,11 +201,16 @@
>        lengthType = protocolNumber;
>        break;
>      case LLC: {
> -      lengthType = p->GetSize () + header.GetSerializedSize () +
> -        trailer.GetSerializedSize ();
>        LlcSnapHeader llc;
>        llc.SetType (protocolNumber);
>        p->AddHeader (llc);
> +      /*
> +       * the ethernet header and trailer are not counted,
> see RFC 1042 and
> +       *
> http://standards.ieee.org/getieee802/download/802.3-2005_section1.pdf,
> +       * Section 3.2.6 a)
> +       */
> +      lengthType = p->GetSize ();
> +      NS_ASSERT_MSG (lengthType <= 1500, "802.3/LLC length
> must not exceed 1500; reduce MTU");
>      } break;
>      case RAW:
>        NS_ASSERT (false);
>

[craigdo]

[ ... ]

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

[Mathieu Lacage]

On Wed, 2008-07-23 at 12:39 -0700, craigdo@... 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

[craigdo]

[ ... ]

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

I think this means we agree.  Let me reiterate:

o No notion of separate PHY and MAC MTU numbers exist in either p2p or CSMA
devices;
o There should be an internal PHY MTU which corresponds to the 1500 byte
enet number;
o There should be a mac level MTU attribute checked against the Phy MTU;
o SetMtu should attempt to set the Mac MTU and return error if it can't;
o GetMtu should return the MAC MTU which is the payload;
o What we're talking about should be explicitly stated in the dox.

-- Craig

[Mathieu Lacage]

On Wed, 2008-07-23 at 13:37 -0700, craigdo@... wrote:

> [ ... ]
>
> > 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.
>
> I think this means we agree.  Let me reiterate:
>
> o No notion of separate PHY and MAC MTU numbers exist in either p2p or CSMA
> devices;
> o There should be an internal PHY MTU which corresponds to the 1500 byte
> enet number;
> o There should be a mac level MTU attribute checked against the Phy MTU;
> o SetMtu should attempt to set the Mac MTU and return error if it can't;
> o GetMtu should return the MAC MTU which is the payload;
> o What we're talking about should be explicitly stated in the dox.

yes.

Mathieu