[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [RRG] RE: Critique of Sprite-MTU: PMTUD, fragmentation etc.



FYI, a new version of the sprite-mtu proposal is available:

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

This version addresses the list comments and also clarifies
the use of temporary private addresses for soft state
synchronization.

Fred
fred.l.templin@boeing.com 


> -----Original Message-----
> From: Templin, Fred L 
> Sent: Tuesday, October 30, 2007 1:26 PM
> To: Robin Whittle; Routing Research Group list
> Subject: [RRG] RE: Critique of Sprite-MTU: PMTUD, fragmentation etc.
> 
> Robin,
> 
> The 576 comes from the minimum EMTU_R required of all IPv4
> nodes. Unless the sprite-mtu TNE has some other a-priori 
> knowledge of the TFE's capabilities, it can assume no more
> than this.
> 
> That said, if the sprite-mtu TNE *does* have a-priori info
> (e.g., that the TFE can accept non-initial */IPv4 fragments
> and can reassemble up to 1500 bytes or so) it can use a
> larger initial value in deciding whether/not to send a PTB.
> Maybe it would help if the document said this explicitly.
> 
> Fred
> fred.l.templin@boeing.com  
> 
> > -----Original Message-----
> > From: Robin Whittle [mailto:rw@firstpr.com.au] 
> > Sent: Tuesday, October 30, 2007 11:12 AM
> > To: Routing Research Group list
> > Cc: Templin, Fred L
> > Subject: Re: Critique of Sprite-MTU: PMTUD, fragmentation etc.
> > 
> > Hi Fred,
> > 
> > Thanks very much for your response.  I linked to it from my critique
> > page.  I will think about this some more and respond on the list in
> > the next day or two.  My 5AM thoughts are:
> > 
> > A future version of the Sprite-MTU draft is likely to resolve my
> > first two concerns.
> > 
> > I still think sending a Packet To Big message while sending the
> > packet onwards is likely to cause trouble - and that my lightweight
> > approach of fragmenting larger outer packets (for reassembly in the
> > ETR, before decapsulation), at first, even if DF=1 is set in the
> > original packet, has significant advantages, at least in an ITR-ETR
> > setting.  I think being lightweight, transparent and non-confusing
> > (such as not sending back PTB messages with spuriously low MTU
> > values), while getting the packet to the ETR even in the face of
> > lower than maximum MTU limits, are really important goals.
> > 
> > Also, my IPTM proposal with "outer source address = sending host's
> > address" is capable of supporting Traceroute, with a moderate
> > upgrade of the Traceroute client software.
> > 
> > 
> > I would appreciate some comment on my idea of setting some baseline
> > of PMTU for IPv4 which is much higher than 576, with the following
> > arrangement:
> > 
> > 1 - I assume that (however defined) the "core" of the Net supports
> >     MTUs well in excess of 1000, and in in excess of some carefully
> >     chosen value well above 1000, and so probably more than double
> >     576.  I wrote "1280" but perhaps the value needs to be somewhat
> >     below this.
> > 
> > 2 - Which "core" routers have a lower basic MTU value than 1500?
> >     Probably none - I guess.  If there are a few, lets put them on
> >     notice they should lift their game by the time an ITR-ETR scheme
> >     is deployed.
> > 
> > 3 - State in the ITR-ETR scheme that all ITR and ETR functions
> >     should be located such that they have at least a "1280"
> >     or whatever value MTU to the "core" of the Net.
> > 
> > Can anyone think of regions of the Net where some value pretty close
> > to 1500 would not be a good choice?  How many levels of tunneling,
> > and of what kinds, are likely to be encountered?  Are there in
> > practice MPLS tunnels which limit MTU below 1500?
> > 
> > You can't necessarily make such assumptions for IPv4 in your
> > Sprite-MTU system, because you intend to use it in many settings
> > other than from an ITR to an ETR.  However, perhaps some agreement
> > could be reached about the final ITR-ETR scheme requiring ITRs and
> > ETRs to have a higher MTU (1280 or maybe >1400?) to the "core" of
> > the Net.  Then Sprite-MTU could have a special IPv4 threshold much
> > higher than 576 bytes when operating in an ITR-ETR setting.
> > 
> > 
> >   Cheers
> > 
> >     - 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