On Fri, 24 Oct 2003, Fred Templin wrote:
> 1) Peer-to-peer wireless (e.g. IEEE 802.11):
> On certain wireless media, receiver A can sense QoS metrics (e.g. SNR)
> for the packets it receives from senders B and C. 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").
> 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. For example, a constrained node on a link with
> MTU of
> 64KB may wish to inform a neighbor that an MTU of 10KB is desired.
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.)
(from Fred's another message on the list:)
> We must face facts that there are multiple access, shared-media links
> out there and will continue to be for the forseeable future. We can wish
> for a densely-connected mesh of point-to-point links (e.g., ATM PVCs)
> but we needs-be have to support the L2 infrastructure that is already
> deployed. (Otherwise, we would have to go through an L2 transition
> before we even begin to tackle the IPv6 transition.)
Sure. There are tradeoffs in every kind of media. A typical assumption
for most kinds of multi-access shared-media links is that they have
similar properties regarding MTU. 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?
The dynamic, wireless multiple-access media seems to have even more
challenging problems of having to probe and adjust MTU's all the time.
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?
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
