[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [RRG] MTU/fragmentation AGAIN
Brian,
Thanks for the thoughts, but you are not saying anything
here that isn't already well understood and/or has been
said many times in the past. First, path MTU from A->B
does not necessarily have any relation to path MTU from
B->A; it is well understood that the paths can easily
be asymmetric and so the MTU discovery is simplex in
both the A->B and B->A directions. As a result, the
paths have to be probed with a large probe request sent
in the forward direction and a tiny probe reply returned
in the reverse. Sprite-mtu defines a way of doing just
that - but this gives me an idea for a minor change which
entails respecifying the sprite-reply to be minimum-sized
rather than requiring perishable padding for the
sprite-request. Thanks for that.
About MTU changes due to path changes, that is a problem
that needs to be dealt with in any case and not just the
map-and-encaps case. The two ways of detecting this are
to begin receiving packet-too-bigs when none were
received previously, or to proactively probe the path,
or both. (In the map-and-encaps case, sprite-mtu probing
can be used for proactive probing by the ITR.)
About end-to-end MTU involvement from TCPs, RFC4821 already
provides a published standards-track specification for just
such a method.
Thanks - Fred
fred.l.templin@boeing.com
> -----Original Message-----
> From: Brian Dickson [mailto:briand@ca.afilias.info]
> Sent: Wednesday, January 02, 2008 12:20 PM
> To: Iljitsch van Beijnum
> Cc: Routing Research Group list
> Subject: Re: [RRG] MTU/fragmentation AGAIN
>
> Iljitsch van Beijnum wrote:
> > Sorry about that.
> >
> > As I said a few days ago, Fred's fragmentation model makes a lot of
> > sense if we want to allow fragmentation in the first place.
> Let's see
> > where we stand if we don't want to allow fragmentation.
> >
> Here, here! :-)
> > If the path between the ITR and ETR supports 1500 bytes +
> > encapsulation there shouldn't be any issues with path MTU discovery
> > that aren't there without the encapsulation, too. (I'm using LISP
> > terminology but this applies to all map/encap schemes.)
> >
> > There are two possible other cases:
> >
> > - the path doesn't support 1500+E and the ITR knows this
> > - the path doesn't support 1500+E but the ITR doesn't know this
> Just to dig a bit deeper, is my understanding on PMTUD
> correct, as follows?
>
> The MTU to be discovered from A->B is not necessarily related
> to the MTU
> to be discovered B->A
> A needs to know MTU-A for A->B, and vice versa, to avoid
> fragmentation.
> If A can do PMTUD, A does (or should) not depend on B in any way to
> accomplish this.
>
> So, PMTUD can be considered two simplex problems - A->B and B->A.
>
> Okay so far?
>
> But, with encaps/decaps, we have A->ITR->path-1->ETR->B,
> which can change to A->ITR->path-2->ETR->B, at any time.
> And it is possible that MTU(path-1) != MTU(path-2).
>
> Does this do bad things to PMTUD?
>
> If we are able to produce a newer, better, PMTUD, that requires
> deployment of new TCP stacks, and achieves 99.9% of the
> desired benefit
> (no fragmentation), when deployed only on the server-side of things,
> would that be worthy of spending time on?
>
> Here's what I'm thinking:
>
> For TCP, all the window-size stuff is based on
> bandwidth*delay. Number
> of packets and rate of transmission.
>
> If the slow-start and back-off stuff, also used MTU as a parameter,
> PMTUD could become an implicit part of TCP.
>
> By shrinking packet size, the effective window shrinks. Grow packet
> size, grow window. Adapt the packet size first, then the rate, to
> achieve the optimum TCP window.
>
> And, if MTU is exceeded, without having (or needing!) any ICMP or
> fragmentation, packet loss would result in lowering of MTU until the
> right MTU was used.
>
> It's a bit wasteful in the presence of true PMTUD, but in its
> absence,
> it makes things "just work".
>
> Thoughts?
>
> Brian Dickson
>
> --
> 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