Re: [RRG] Ivip's fix for tunnel o-head, PMTUD & fragmentation problems

[Robin Whittle <rw@firstpr.com.au>]

Hi Brian,

You wrote:

>> ...  While it does this, it fragments longer
>> packets which it tunnels to the ETR, even if the sending host set
>> the DF bit.  
> 
> As written, that seems to be a direct violation of RFC 791.

Perhaps so.  RFC 791 doesn't mention "tunnel".

In redesigning the architecture of the Internet, we may well decide
that our 2008-2009 invention of an ITR-ETR tunnel should contradict
or re-interpret something which was written 27 years earlier.

> I doubt we can anticipate all the unintended consequences.

This is bound to be true when introducing a major architectural
change.  In this case, most of the consequences will be limited to
the tunneled part of the path.  There will also temporarily be
marginal loss of efficiency, longer time of transit, and/or greater
packet loss - which affects the final arrival of packets at the
recipient host.

> A tunnel, like a link layer, is fully entitled transparently
> to fragment *and reassemble* the packets that it carries, but
> that isn't what you propose.

I specifically propose the ETR reassembles the packet at the end of
the tunnel, before decapsulating the inner packet.  I tried to keep
the mailing list message short, so I didn't go into such detail.

In the terse description:

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/#terse

  Else (if the encapsulated packet's length is greater than this
       ETR's EMTU):

       If the ITR has not attempted to discover the actual MTU to
       this ETR or is in the process of trying to discover it:

            The ITR fragments the packet (even if the DF flag on the
            original packet was set) and begins an ETR-Path MTU
            Discovery phase, which should be complete in a few
            seconds.

I have just added at this point:

            ***The two fragments are reassembled by the ETR before
            the inner packet is decapsulated.***


This was made explicit in the more detailed description which follows:

  The ETR's main datapath (FIB) activities are unchanged by this
  addition to Ivip, other than that the ETR is assumed to be able to
  reassemble a fragmented packet from the ITR before decapsulating
  it.


I have named this proposal IPTM - "ITR Probes Tunnel MTU".  I think
it is just as applicable to the other ITR-ETR proposals as to Ivip -
but the Traceroute functionality is specific to Ivip, since the
other proposals use the ITR's address as the Source Address for
tunneled packets.

I have added a section on potentially multiple ITRs being the start
of the tunnel, and given the Traceroute material its own heading.

  - Robin


--
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