Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

["Dan Wing" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Jeroen Massar
> Sent: Thursday, October 20, 2011 9:42 AM
> To: james woodyatt
> Cc: IPv6 Operations; [e-mail]
> Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis
> 
> On 2011-10-20 18:13 , james woodyatt wrote:
> > On Oct 20, 2011, at 6:16 AM, Lorenzo Colitti wrote:
> >>
> >> Yes, if the upstream MTU is lower than the default LAN link MTU.
> >> Otherwise you'll experience latency issues whenever you connect to a
> >> new host on the Internet.
> >
> > Because, as we all know, hosts on the LAN never ever communicate
> > directly with one another at full media speeds using jumbo frames, as
> > they all require every last one of their interactions to be mediated
> by
> > the Cloud Buzzphrase Horsefeathers in the SkyT or the terrorists win.
> 
> <sarcasme>
> You mean iCloud? :)
> </sarcasme>
> 
> I almost commented a similar thing about local MTU needing to be the
> same, till I re-read it again and till I rephrased that sentence in my
> head as:
> 
> "The MTU on the upstream might be different (be that lower or higher),
> if you don't set it properly, then you might have extra latency because
> of packets will get dropped when it is wrong and packets will
> disappear"
> 
> As such, according to that, the following setup, which is very common
> is
> totally acceptable:
> 
> LAN (4000) -> upstream-link (1480) -> internet (1280) -> remote host
> (1500)
> 
> Which is of course very logical and why we have Path MTU discovery.
> 
> Maybe the better comment is to definitely not filter ICMP Packet Too
> Bigs and friends unless really needed.

Lost that war.  Let's try different approaches, such as PLPMTUD 
(packetization layer Path MTU Discovery) or a way to indicate 
different MTUs to the host:

Unfortunately, PLPMTUD with TCP (RFC4821) is unlikely to win hearts 
because it can be slow to notice an MTU problem, and can stall a 
connection while it is figuring that out.  PLPMTUD in SCTP, however,
is pretty neat stuff.

Indicating different MTUs to the host could go a long way towards 
solving the issue that James brought up -- we need a clean way to 
indicate to the host which routes or paths have small MTUs, so 
that communications within a network can use a large MTU.  If
it is known, a priori, that all communications to non-local 
addresses needs a small MTU (and can communicate that to the host)
we avoid Lorenzo's concern about slowing down Internet-
destined traffic that has to re-learn the path MTU again and
again.

-d