Re: [RRG] MTU/fragmentation AGAIN

[Brian Dickson <briand@ca.afilias.info>]

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