RE: The IPv4 Internet MTU

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.microsoft.com] 
> Sent: Thursday, September 27, 2007 4:36 PM
> To: Templin, Fred L; Arnaud Ebalard; Rémi Denis-Courmont
> Cc: v6ops@ops.ietf.org
> Subject: RE: The IPv4 Internet MTU
> 
> > > This silly idea gets me to a default MTU for Teredo interfaces in
> > [1380,
> > > 1384]. I know it looks like cooking but it seems a fair bet and it
> > > provides in default cases almost a 10% boost of TCP MSS value for
> > Teredo
> > > clients without obvious drawbacks.
> >
> > Why not just set the Teredo interface MTU to (64KB-ENCAPS)?
> > Then, take special care to make sure the small packets get
> > through but let the big packets take care of themselves.
> 
> The problem is UDP fragmentation.

I guess you mean IPv4 fragmentation? Even so, there is
a lot we can do within the no-man's-land of the Teredo
interface after we get a packet from IPv6 and before we
give it over to IPv4. So, why not just give IPv6 an
optimistic MTU estimate then deal with reality from
within?

> By nature, it is 
> unreliable: the more fragments, the more chances to lose one 
> of them, thus causing the loss of the entire packet. This is 
> aggravated by NAT behavior: some NAT will try to reassemble 
> the packets, but others will just pass the 1st fragment and 
> drop the next ones.

That doesn't sound too good. Maybe we should just forget
about IPv4 fragmentation altogether and fall back to IPv6
fragmentation instead?
 
> That would not be too much of a problem if TCP 
> implementations could do MTU detection by just reacting to 
> packet losses. But today, many TCP implementations don't. The 
> MTU discovery is triggered by ICMP "packet too big" messages. 
> These messages are not generated if a UDP fragment is lost.

Well, that's more or less what I was driving at in terms
of taking care of the smalls and letting the bigs take
care of themselves. If we had the tunnel endpoint send
specially-padded probes to the tunnel far-end, then it
would know the largest packet it could admit into the
tunnel before either fragmenting or dropping and sending
back a PTB. But, probing for sizes larger than 1500+
would be wasteful if the original source was already
doing its own MTU detection anyway.

BTW, how big did you say those bubbles were that you 
are blowing? (Or, maybe it was the echo requests...)

Fred
fred.l.templin@boeing.com