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 [EMAIL PROTECTED] > -----Original Message----- > From: Robin Whittle [mailto:[EMAIL PROTECTED] > 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 [EMAIL PROTECTED] 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
