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