[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