If the SNR for B is strong, A may wish to inform B that a larger MTU (e.g. 1500 bytes) is acceptable. Conversely, if the SNR for C is weak, A may wish to inform C that a smaller MTU (e.g. 1300 bytes) is desired.
This kind of dynamic MTU negotiation (requires at least one round-trip!)
seems rather complex to me. Even more so that the original proposal
seemed to be ("node A advertises that a larger MTU is OK").
There is no need for any full-blown negotiation. A node can simply announce the desired/supported maximum packet size at the time of neighbor discovery and be done with it.
2) Constrained nodes on large links: On large-MTU media (e.g., HiPPI, Gig-E, etc.), nodes with small receive buffers (e.g. boot ROMs, embedded devices) may wish to receive smaller packets than
the MTU for the link.
Are you sure such deployments are feasible to begin with? Such low-end equipment is very unlikely equipped with e.g. Gig-E interfaces. (Note: Gig-E MTU maximum is about 9K already, so it's a bit more reasonable than 64K.)
Hm, if we look back 15 years we see that hosts needed to support 1500 bytes for 10 Mbps ethernet. A typical example of such a host was a PC with less than 1 MB memory. Today networks are 100 times as fast (GE is now cheaper than 10 Mbps 15 years ago), we typically have 500 times as much memory but our maximum packet size has increased by a whopping six times...
I agree that it is unlikely a host with GE or similar would be unable to support a decent maximum packet size, but it can't hurt to have the option of triggering a smaller packet size.
A typical assumption for most kinds of multi-access shared-media links is that they have similar properties regarding MTU.
Shared media? That is sooo last century...
This is also the case for larger MTU's.
This problem is nowhere near non-trivial. Consider e.g. an IPv6 link
which is separated by two Ethernet switches, one which supports
jumboframes (MTU=9K) and one which does not. How would the hosts be able
to, with simple and robust mechanisms, to determine the MTUs to be used on
such environment?
This is why we need routers to explicitly advertise the maximum MTU using a new option. It is unlikely that people who need the extra performance gained by the use of jumboframes are also the ones that hook up a $20 switch to a $600 one.
It wouldn't hurt if the IEEE picked this up, though.
The dynamic, wireless multiple-access media seems to have even more challenging problems of having to probe and adjust MTU's all the time.
802.11 does this at layer 2, which seems the right thing to do.
Think about an application using UDP (ie., has to do optimize for the MTU
value itself) that runs longer than the lifetime of this probing. You
expect these to adjust all the time as well?
This approach seems to be adding complexity of L2 to IP layer where it doesn't belong. If we need to tackle this issue at L3, why not just simply use MTU 1280 or MTU 1500 and fragment the packet when needed?
In IPv6, fragmentation overhead is too hideous and probably not supported below 1280 bytes without changes anyway.
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
