I have general sympathy for things that would improve the ability of end
nodes to send larger packet sizes. As LAN and WAN speeds rise, latency
goes down since each packet takes less time on the medium, but packet
processing overhead goes up, since you must be able to receive 10x as
many existing-size packets in a given second over a 10xfaster link.
In that regard, Herbie Robertson raised what seems like an important
issue that could be addressed with a small "nit" fix to the IPv6 specs:
I still remember implementing path MTU discovery thinking about the
big performance win I was going to get in IPv6 from 9K packets (vs
1500 byte packets) only to discover that certain router vendors had
interpreted one of the RFCs to mean they didn't have to send
packet-too-big messages if the packet in question was larger then 1500
bytes (because one of the RFCs stated that IPv6 implementations only
have to support 1500 bytes). Yes, the RFCs could be interpreted that
way, but that interpretation clearly violates the intent (to make path
MTU reliable). The real world upshot of that is that anything over
1500 bytes is still a black hole and using path MTU can really only
get you a whopping 300 bytes (from 1200 to 1500).
Should we consider clarifying the IPv6 specs to state that routers and
end-user nodes will send ICMP packet-too-big responses when receiving a
too-big packet *OF ANY SIZE* which they can't forward onto the next
interface due to an MTU limit? (Or which the end node can't process
due to a limit in its NIC or elsewhere in its implementation.)
If so, Intarea could take a tiny step toward nodes being able to
eventually detect and use existing 9000 byte jumbo frame support by
default. Having working auto-detection of 9000 byte frames would also
encourage future hardware to increase frame sizes further, knowing that
existing software will automatically use them where possible.
John
_______________________________________________
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area
