Re: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018

[Tom Jones <[e-mail]>]

On Sun, Jan 21, 2018 at 06:42:27PM -1000, Christian Huitema wrote:
> 
> 
> On 1/20/2018 11:50 PM, Mikkel Fahnøe Jørgensen wrote:
> > Here is a Fibonacci variant the grows slower.
> > Not sure it is any better, but the intention is to avoid probing very
> > large packets too early.
> > It could probably be applied recursively to avoid bin search altogether.
> > The same idea might be applicable to reducing the congestion window as
> > opposed to doubling or halving.
> >
> > /* Fibonacci variant */
> > /* roughly like this - untestet */
> > unit = 10 /* min probe increment */
> > a = minPMTU / unit
> > b = maxPMTU / unit
> > k1 = initDelta /* 1 or larger, e.g. a / 4 */
> > k0 = 0
> > while a + k0 <= b
> >   k2 = k0 + k1
> >   n = binsearch(a + k0, min(a + k1 - 1, b), unit)
> >   if n return n
> >   k0 = k1
> >   k1 = k2
> > end
> > /* binsearch probes multiples of unit and calls
> >    updatePMTUEstimate(n) whenever n is a larger
> >    valid probe than previously reported */
> >
> Yes, there are multiple ways to go about sending probes. In the QUIC
> case, the peer sends its own version of MAX MTU during the handshake. So
> what I did was simply try the peer's MTU, and if that fail do a binary
> search between that and the initial value. The peer MTU is typically
> between 1470 and 1500, so the binary search converges very quickly.

Thanks for the comment, this is an interesting approach we probably need
some discussion of the probe size search algorithm in the draft. 

Is the ~1500 value something you have manually configured or have you
found it from the host? maxdgram on my machine is 9216. 

> There are certainly ways to do better, especially if the peer sets its
> own MTU to some large value, e.g. in a data center environment. For
> example, one could have a table of probability of finding some
> particular MTU. And then apply logic based on how much the connection
> wants to send, what it costs to send a probe, and what is the likely
> gain if the probe succeeds. You could use that to choose the next probed
> value. Or to decide to stop probing if no plausible next value can bring
> a potential gain. Or to send several probes in parallel...
> 

RFC1191 suggested a table with some common values. I would try:

	- validating the base ~1280
	- probing for ~1500
	- if that works probing for the Max MTU from the peer

then falling back to a search algorithm to close the gap if it is a
sensible size.

- [tj]