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 [EMAIL PROTECTED] > -----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 > [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 > -- 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
