On 26-aug-2007, at 7:23, Bernard Aboba wrote:
As noted, much of the discussion is academic because in fact, bit
errors
do not happen in isolation.
Yes, it would be good to look at this in more detail.
Also, while it is possible to implement stronger frame
checking mechanisms, doing so at line rate (e.g. 10+ Gbps) is non-
trivial.
With larger payloads, it could be interesting to explore checksums
that derive their strength from a greater length rather than a strong
algorithm. But if a relatively modest packet size works better at a
certain point in time for a certain type of hardware, that's fine,
that's the whole point of automatically using the maximum possible size.
If this material is intended to remain within the document, it
needs to be
reviewed by IEEE 802.3 folks such as Pat Thaler.
Yes, it would be helpful to put the whole jumboframe/CRC issue to bed
for good.
With the advent of Energy Efficient Ethernet, it will be possible
for link rate
to be adjusted in mid-conversation. Therefore the having the
allowed MTU
vary with link speed will mean that the MTU could conceivably
change in
the middle of a conversation between two hosts.
There doesn't seem to be much information around about energy
efficient ethernet. Depending on how it's implemented, this could be
rather problematic for applications that need a certain quality of
service. It is of course easy to limit the size of outgoing packets
depending on link speed, even if the link speed is quite variable,
but it's not exactly easy to do the same for incoming packets.
Receiving a burst of 9000 byte packets when operating at 10 Mbps
isn't exactly great for applications like VoIP. For IPv6 it would be
possible to advertise a new, smaller MTU in a neighbor advertisement,
but with IPv4 that's not as easy.
Having a layer 2 switch advertise its maximum MTU will not
necessary provide
a host with useful information, since depending on the operation of
(R)STP,
the switch may or may not be in the path. Also, with Energy Efficient
Ethernet, one or more links along the path may adjust their speed; if
the MTU were to vary, this would cause changes to the path MTU that
the host would not be to predict, even knowing the link speed-MTU
relationship of its edge switch.
The idea is to listen to all broadcasts from switches and then use
the largest packet size supported by them all. But I'm thinking it's
probably easier to depend on test packets to make sure that packet
sizes are limited to what switches support so I'll remove the switch
advertisements in the next version.
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
