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

From: Robin Whittle <[email-masked]>
Date: Wed, 17 Oct 2007 03:55:21 +1000

I would appreciate feedback on an extension to Ivip I am planning.
Depending on how it fares in discussion on this list, I will add it
to a future version of the Ivip ID.  It will be some months before I
write a new version, because I want to develop some better ideas for
the Replicator system, and because I can't spend much time on this
at present.

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

This is IPv4-centric at present.

I propose the ITR use a TCP link, UDP probe packets and a simple new
protocol (together with traditional RFC1911 PMTUD) to determine the
MTU of the path to the ETR.  While it does this, it fragments longer
packets which it tunnels to the ETR, even if the sending host set
the DF bit.  After the ITR has a reliable estimate of the MTU, it
does not fragment packets, but rejects (with an ICMP Packet too Big
message) those packets which, when encapsulated, would be too long
for the estimated MTU of the path to the ETR.

Since Ivip uses the sending host's address for the outer header, I
suggest that Traceroute can be made to work for all routers,
including those in the tunnel, as long as the sending host uses a
somewhat modified Traceroute program, which is looking for the ICMP
packets generated by routers in the tunneled part of the path.  Such
a program could display the identity of the ITR and ETR in the path too.

Am I correct in thinking that the Traceroute program and principles
of operation are only used for diagnostic purposes?  That no other
protocol or application relies on Traceroute?  I would have to check
whether this is true of tricky protocols - STUN comes to mind.

As far as I know, no other ITR-ETR proposal currently has a method
of dealing with the problems of tunneling overhead and failure of
traditional RFC1191 Path MTU Discovery leading to fragmentation
(IPv4) or maybe dropped packets with no proper message getting to
the sending host (IPv6).  The closest is Bill Herrin's TRRP-via-02
proposal:

  http://bill.herrin.us/network/trrp-via02.html

but this relies on option headers, which are regarded as unsuitable
for most BGP routers:

  http://psg.com/lists/rrg/2007/msg00350.html

The new page also contains a critique of Fred Templin's sprite-mtu
proposal (draft-templin-inetmtu-04) - that it drops the first long
packets to ETR which is new to any one ITR, and that the sending
host will initially be forced to send lots of very short packets.

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

    - Robin

--
to unsubscribe send a message to [email-masked] 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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Oct 2007 14:28:47 +0200

On Wed, Oct 17, 2007 at 03:55:21AM +1000,
 Robin Whittle <[email-masked]> wrote 
 a message of 63 lines which said:

> I suggest that Traceroute can be made to work for all routers,
> packets generated by routers in the tunneled part of the path.

Isn't it exactly what RFC 4950 traceroutes do? (An example is NANOG
traceroute, in ftp://ftp.login.com/pub/software/traceroute/, which
does implement RFC 4950 even before it was pubslihed.)

> of operation are only used for diagnostic purposes?

I believe so, yes.

---

From: Robin Whittle <[email-masked]>
Date: Thu, 18 Oct 2007 00:03:55 +1000

Hi Stephane,

I hadn't heard of RFC 4950 before.  It involves changed router
functionality to send back a more informative ICMP message when a
packet is undeliverable (such as with Traceroute TTL hitting zero)
when the packet has an MPLS header.

My proposal has a broadly similar goal, but is rather different,
because it involves altering the Traceroute software at the sending
host so it recognises the ICMP messages generated by unmodified
routers, where those routers are in the tunneled part of the path.

Thanks for confirming my understanding that Traceroute is not used
as part of any application or other protocol.

By the way, I think that what I propose for Ivip:

should work equally well for LISP-CONS, LISP-NERD, eFIT-APT and TRRP
- except that the Traceroute won't work for routers in tunnelled
part of the path, since none of these proposals have the outer
header's source address being that of the sending host.

  - Robin

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Oct 2007 13:34:48 +1300

On 2007-10-17 06:55, Robin Whittle wrote:
...
> ...  While it does this, it fragments longer
> the DF bit.  

As written, that seems to be a direct violation of RFC 791.
I doubt we can anticipate all the unintended consequences.
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.

    Brian

---

From: Robin Whittle <[email-masked]>
Date: Thu, 18 Oct 2007 12:45:35 +1000

Hi Brian,

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

> 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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Oct 2007 06:41:38 -0700

Robin,

Please check the new draft version, which has been awaiting
submission approval since 10/15. It has also been delayed
for several days in the I-D submission process somehow, but
I am hoping it will be taken into the repository soon. For
now, you can view the new draft version at:

  http://ipvlx.org/spritemtu-05.txt

This version asserts that there is nothing fundamentaly wrong
in the normative tunnel MTU handling specifications (RFCs 2003;
4213) - only that they are incomplete. All that is needed for
completion is:

  1) a means for avoiding MTU-related black holes
  2) a means for avoiding corruption in reassembly buffers

Anything else (like improved convergence and efficiency)
might be considered as just a "nice to have" bonus. Again,
please re-check with the new version, but IMHO this is more
of an engineering-oriented document and should perhaps be
taken up on the IETF lists.

Fred
[email-masked]

> -----Original Message-----
> From: Robin Whittle [mailto:[email-masked]] 
> Sent: Tuesday, October 16, 2007 10:55 AM
> To: Routing Research Group list
> Subject: [RRG] Ivip's fix for tunnel o-head, PMTUD & 
> fragmentation problems
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Oct 2007 13:12:02 -0700

FYI, the updated sprite-mtu proposal is now in the
I-D database:

http://www.ietf.org/internet-drafts/draft-templin-inetmtu-05.txt

Fred

> From: Templin, Fred L 
> Sent: Tuesday, October 23, 2007 6:42 AM
> To: Robin Whittle; Routing Research Group list
> Subject: RE: [RRG] Ivip's fix for tunnel o-head, PMTUD & 
> fragmentation problems
> 
> Robin,
>