RE: [RRG] Re: LISP PMTU & fragmentation problems

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

Hi Dino, 

>-----Original Message-----
>From: Dino Farinacci [mailto:dino@cisco.com] 
>Sent: Sunday, March 09, 2008 6:29 PM
>To: Templin, Fred L
>Cc: Robin Whittle; Routing Research Group
>Subject: Re: [RRG] Re: LISP PMTU & fragmentation problems
>
>> I have to agree that the new LISP text reads like a
>> "slacker's guide" to MTU handling. First, it only does
>
>Call it what you wish, but we are trying to be practical and simple at

>the same time. You know we really want to deploy this and not just  
>create paper with all kinds of protocol machinery just for the sake of

>solving problems. Some problems don't need to be solved. Some problems

>are not real problems.

That's not at all what SEAL is about, if that is what you
mean. SEAL actively fixes real-world problems when there
are *definitely* small MTU links, and is available as hot
standby when there *may* be small MTU links. Think of it
as an uninterruptible power supply; it is ordinarily
dormant, but kicks in when needed and keeps the system
up and running until the small MTU links are identified
and replaced.

>> the splitting for IPv4 packets that had DF=0 from the
>> original host, and there really aren't very many of those
>
>So if you say DF=0 is non existent, then we say that small MTU links  
>are non-existent as well.

I didn't say DF=0 was non-existent; only that it is rare.
Two words that don't fly in this context are "always" and
"never".

>> in-the-wild these days. Second, for IPv6 and IPv4 with DF=1,
>> the original source will be told a degenerate MTU that would
>> go against the principle of least surprise ("I expected 1500,
>> but only got 1464") plus it *always* results in packet loss
>
>Well, sorry it's the real effective MTU, 1464 that is. And why is this

>surprising?

With SEAL, the effective MTU is 1500 and the hosts never have
to deal with PTBs. No loss due to MTU restrictions; no wasted
resources for delivering PTBs, plus the 1500 MSS negotiated
by the TCPs never has to be revised.

The other aspect of sending the PTB with MTU=1464 is that,
if the source was another tunnel endpoint (e.g., a security
gateway) there is no guarantee that it will be able to
translate the PTB for transmission back to the original
source. RFC2923 also identifies other uncertainties about
classical path MTU discovery.

>> until MTU discovery has converged. Finally, there is no
>> provision for discovering MTUs larger than 1500 even though
>> the core may soon transition to all-GigE.
>
>The MTU discovery will be contained inside of the site. That is a lot  
>better than all the way to the destination host.

So, you seem to be arguing against large MTUs in the interdomain
context? RFC4821 supports that scenario, but won't work if your
routers won't let it.

IMHO, we want to evolve to a "GigE-jumboframe-everywhere"
Internet, and setting a fixed and too-small MTU at the
routers will not allow that to happen.

>> You have said that you believe the core is comprised almost
>> completely of links that can do quite a bit more than 1500.
>> Why not trust your judgement and just run SEAL; that way, you
>> get to enjoy the larger MTUs and will have no fragmentation
>> unless a degenerate link shows up on the path - in which case
>> SEAL will detect and correct it.
>
>Too much machinery, it is not needed and we want to be stateless. Do  
>you not agree that our proposal is even simpler than SEAL?

In the interdomain, I believe it will be not unreasonable
to find 1500 MTU links but completely unreasonable to find
anything appreciably smaller. As such, SEAL will never split
a packet into more than 2 pieces the same as what the LISP
text says. The only difference is that SEAL will split DF=1
packets the same as for DF=0 packets. The final destination
will reassemble the latter, while the ETR will reassemble
the former (up to a modest limit of 2KB). But, the ETR
already has to support reassembly for IPv4 and IPv6 anyway.

AFAICT, the choice is to tell the original source a too-small
MTU once and for always (which may not always work), or to
allow a little bit of robust segmentation and reassembly
between the ITR and ETR. All things in moderation...

Fred
fred.l.templin@boeing.com

>
>Dino
>

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg