[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