[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] Ivip's fix for tunnel o-head, PMTUD & fragmentation problems
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
fred.l.templin@boeing.com
> -----Original Message-----
> 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,
>
> 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
> fred.l.templin@boeing.com
>
>
> > -----Original Message-----
> > From: Robin Whittle [mailto:rw@firstpr.com.au]
> > 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
> >
> > 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 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
> >
>
> --
> 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
>
--
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