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

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

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