Re: "RFC 2461bis" issue: MTU handling

[Fred Templin <ftemplin@iprg.nokia.com>]

Pekka Savola wrote:

> 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").
No; the proposal is that node A initially advertises to B and C the largest
packet size it would like to receive from each of them. A then sits back and
passively accepts packets from B and C until it senses some change in 
conditions
(e.g., B's SNR degrades or C's SNR improves). A can then send an 
*unsolicited*
message to B and/or C to inform that a new maximum packet size is desired.
(A should of course give some consideration to rate limiting the unsolicited
messages it sends.)

> >  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.)
Well, every node on a link should at least be able to receive a packet as
large as the MTU of the link. But, some nodes might prefer to receive
smaller packets and so should have some means of telling neighbors that
smaller packets are desired.

> (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?
You are entering the realm of bridging L2 media with diverse MTUs;
IPv6/IPv4 path MTU discovery doesn't work in this case unless the
bridges are "transluscent" and send ICMP "packet too big" messages
as they drop the too-big packets. (Note that a "transparent" bridge would
not look into the L3 header and simply drop the too-big packet w/o
sending any  error message at all.)

Can we augment path MTU discovery to work with transparent bridges
that connect media with diverse MTUs? Seems like we need to - whether
the links are multi-access shared media or point-to-point.

> 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?
As I said above, consideration to rate limiting the unsolicited MTU
change messages needs to be given in order to dampen the frequency.

> 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?
We will miss out on the opportunity to take advantage of larger MTUs
if we set a static MTU and just let IP fragment the packets. Also, if we
have transparent bridges in the path we won't have the required IP
fragmentation support at all forwarding nodes and we'll get black holes.

Fred
ftemplin@iprg.nokia.com



--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------