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

[Christian Huitema <[e-mail]>]

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.

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...

-- Christian Huitema