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

From: Vincent Roca <[email-masked]>
Date: Thu, 4 Jan 2018 16:15:25 +0100

Hello everybody,

> * Please send an email to this list if you would like to see this work adopted in TSVWG, or you have comments on the suitability for adoption.
>  
> * Please indicate if you are willing to REVIEW such a document during its development.

As I said during IETF100 meeting, I support this I-D adoption and agree to review it.

Cheers,

  Vincent

---

From: "Proshin, Maksim" <[email-masked]>
Date: Mon, 8 Jan 2018 13:02:43 +0000

Hi,

As I said during TSVWG session at IETF100, I'd like to see it adopted and I also plan to review it.

BR, Maksim

________________________________
From: Black, David <[email-masked]<mailto:[email-masked]>>
Date: Thu, Dec 14, 2017 at 11:27 PM
Subject: [tsvwg] Adoption call: draft-fairhurst-tsvwg-datagram-plpmtud-02 to end 10th January 2018
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>

I'm tardy in getting to this action item from the TSVWG meeting in Singapore ...

The TSVWG chairs are considering adoption of the draft

"Packetization Layer Path MTU Discovery for Datagram Transports".

This draft has been discussed at the previous IETF meeting and on the list, and the chairs are now looking for input from the group to help inform whether TSVWG should adopt this draft.

Please send all notes of support/comments to the TSVWG list or the WG chairs by the date above.

Best wishes,

David and Wes.

(TSVWG Co-Chairs) [Gorry is recused from this adoption decision, as he is an author of this draft.]

[The time period for this adoption call is longer than usual to allow for the winter holidays - may yours be joyous!]

Abstract

   This document describes a robust method for Path MTU Discovery

   (PMTUD) for datagram Packetization layers.  The method allows a

   Packetization layer (or a datagram application that uses it) to probe

   an network path with progressively larger packets to determine a

   maximum packet size.  The document describes as an extension to RFC

   1191 and RFC 8201, which specify ICMP-based Path MTU Discovery for

   IPv4 and IPv6.  This provides functionally for datagram transports

   that is equivalent to the Packetization layer PMTUD specification for

   TCP, specified in RFC4821.

---

From: "Eggert, Lars" <[email-masked]>
Date: Tue, 9 Jan 2018 11:11:35 +0000

Hi,

would someone clarify what the intended relationship of the mechanism described in the document and QUIC is? For example, is the intention here that QUIC should implement this,  is this unrelated, or anything in between?

Asking, because if there is an intended relationship, it would be good to discuss this sooner rather than later.

Thanks,
Lars

> On 2017-12-15, at 7:27, Black, David <[email-masked]> wrote:
> 
> I’m tardy in getting to this action item from the TSVWG meeting in Singapore …
> 
> [The time period for this adoption call is longer than usual to allow for the winter holidays – may yours be joyous!]
> 
> Abstract
>

---

From: Derek Fawcus <[email-masked]>
Date: Wed, 10 Jan 2018 14:16:44 +0000

> Asking, because if there is an intended relationship, it would be good to discuss this sooner rather than later.

Similarly in section 1 (para 1 & 9) mention is made of its applicability to DCCP,
but then nothing is mentioned about it subsequently.

Should this document also cover the details for DCCP at the same level as for UDP?

DF

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 10 Jan 2018 15:32:32 +0000

On 10/01/2018, 14:16, Derek Fawcus wrote:
> Similarly in section 1 (para 1&  9) mention is made of its applicability to DCCP,

The DCCP Spec includes content on PMTUD, therefore it's not quite the 
same case as UDP, but the concepts of probing coild be applicable - 
although I do not know of any DCCP implementation that considered PMTUD. 
I'd be happy to thinkl about inputs from people using DCCP - speak up if 
there are key issues that you're experiencing with PMTU discovery and 
DCCP or with DCCP/UDP.

Gorry

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 10 Jan 2018 15:38:56 +0000

On 09/01/2018, 11:11, Eggert, Lars wrote:
> Hi,
>
> would someone clarify what the intended relationship of the mechanism 
> described in the document and QUIC is? For example, is the intention 
> here that QUIC should implement this,  is this unrelated, or anything 
> in between?
>
The work originates from updates to the IPv6 base spec, and the need to 
consider how to do PLPMTUD for transports other than TCP.  There's 
practical code for UDP-Options, and SCTP, and that is presently evolving 
with the Spec.

I suspect someone could use the final method with QUIC - since it's also 
a UDP-based transport. I don' knopw of anyone planning PMTUD for QUIC - 
please get in touch if that is on your radar.
> Asking, because if there is an intended relationship, it would be good 
> to discuss this sooner rather than later.
> Thanks,
> Lars
>
Best wishes,
Gorry
>> On 2017-12-15, at 7:27, Black, David <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> This draft has been discussed at the previous IETF meeting and on the 
>> list, and the chairs are now looking for input from the group to help 
>> inform whether TSVWG should adopt this draft.
>> * Please send an email to this list if you would like to see this 
>> work adopted in TSVWG, or you have comments on the suitability for 
>> adoption.
>> [The time period for this adoption call is longer than usual to allow 
>> for the winter holidays – may yours be joyous!]
>> Abstract

---

From: Christian Huitema <[email-masked]>
Date: Wed, 10 Jan 2018 08:22:50 -1000

> On Jan 10, 2018, at 5:38 AM, Gorry Fairhurst <[email-masked]> wrote:
> ...
> 
> I suspect someone could use the final method with QUIC - since it's also a UDP-based transport. I don' knopw of anyone planning PMTUD for QUIC - please get in touch if that is on your radar.

The initial packets in QUIC are sent with min IPv6 MTU. During the initial exchange, the nodes send the maximum packet size that they might accept. QUIC does not specify the actual probing algorithm but does specify that PMTU is per path.

Several QUIC implementations do PMTUD already, building simple probes with QUIC's Ping and Padding frames. Probes are then encrypted, and sent as QUIC packets in UDP with segmentation turned off. If the probe packet is acknowledged, the applications know that this much MTU can be sent.

Note the encrypted part. Replacing such mechanisms by a clear text exchange is not desirable.

-- Christian Huitema

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 10 Jan 2018 19:57:22 +0100

> On 10. Jan 2018, at 19:22, Christian Huitema <[email-masked]> wrote:
> 
> 
Your description of the probe packets is the one we have in mind. It just needs to be specified.
The more interesting part of the document is the way (when and which size) you probe,
not how you probe.
> Note the encrypted part. Replacing such mechanisms by a clear text exchange is not desirable.
And not intended...

Best regards
Michael

---

From: Christian Huitema <[email-masked]>
Date: Sat, 20 Jan 2018 20:10:34 -1000

>> Note the encrypted part. Replacing such mechanisms by a clear text exchange is not desirable.

Since you mentioned it, I implemented "application level" PMTUD in my
implementation of QUIC (https://github.com/private-octopus/picoquic).
Basic "probe" strategy. Start with the min value (from IPv6), then learn
the peer-supported value during the handshake (standard QUIC), then send
probes to perform a binary search between min and max. Stop the binary
search if the range of search is less than 10 bytes. No ICMP dependency.
Some overhead, but that is amortized by sending a dozen packets or so at
the maximum size instead of the default size.

-- Christian Huitema

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 21 Jan 2018 00:28:32 -0800

Since you mentioned it, I implemented "application level" PMTUD in my
implementation of QUIC (https://github.com/private-octopus/picoquic). Basic
"probe" strategy. Start with the min value (from IPv6), then learn the
peer-supported value during the handshake (standard QUIC), then send probes
to perform a binary search between min and max. Stop the binary search if
the range of search is less than 10 bytes. No ICMP dependency. Some
overhead, but that is amortized by sending a dozen packets or so at the
maximum size instead of the default size.

-- Christian Huitema

How you considered exponential search where you start with a conservative
limit for the upper bound, then exponentially increase that limit until
maxPMTU. It is not faster than binary search if each size is equally
likely, but that is probably not true.
I assume it would use less bandwidth if the max is much larger than the
typical PMTU, and allow the application to start using larger MTU’s earlier
since early guesses are more likely to succeed.

/* roughly like this - untestet */
a = minPMTU
b = maxPMTU
k = initDelta /* 1 or larger, e.g. minPMTU / 4 */
while a <= b
  k = min(a + k, b) - a
  n = binsearch(a, a + k - 1)
  if n return n
  a = a + k /* this doubles the search range */
end
return not found

https://en.wikipedia.org/wiki/Exponential_search

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 21 Jan 2018 01:50:28 -0800

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 */

Kind Regards,
Mikkel Fahnøe Jørgensen

On 21 January 2018 at 09.28.32, Mikkel Fahnøe Jørgensen ([email-masked])
wrote:

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Sun, 21 Jan 2018 18:42:27 -1000

On 1/20/2018 11:50 PM, Mikkel Fahnøe Jørgensen wrote:
> Not sure it is any better, but the intention is to avoid probing very
> large packets too early.
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

---

From: Tom Jones <[email-masked]>
Date: Thu, 25 Jan 2018 10:40:57 +0000

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

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

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Thu, 25 Jan 2018 14:00:14 +0100

> On 25. Jan 2018, at 11:40, Tom Jones <[email-masked]> wrote:
> 

Ack; – I think the main question is whether you want a generic
algorithm or something that is optimised for today’s Internet,
but also somehow works otherwise.

> found it from the host? maxdgram on my machine is 9216.

1500 is default for Ethernet without Jumbo Frames.

> then falling back to a search algorithm to close the gap if it is a

I think the table from RFC1191 will need updating, but I think this
approach works best:
 - validating the base ~1280
 - probe table of common MTUs (linear or binary search) 
   including Max MTU 
 - do some search between the largest working / smallest non-working MTU

Whereby I would use some exponential search variant (not tested):
 
 MTUsearch (a,b,step):
   if probeMTU(b-step):
      MTU := b-step
      a   := b-step
      step = step/2
   else
      b = b-step
      step = step*2
   if b > a
      MTUsearch(a,b,step)    
 
Rational behind that is that MTUs will usually be LL-MTU (hopefully in the table) minus some encapsulation.

AVE!
  Philipp S. Tiesel / phils…

---

From: Joe Touch <[email-masked]>
Date: Thu, 25 Jan 2018 07:34:38 -0800

> On Jan 25, 2018, at 5:00 AM, Philipp S. Tiesel <[email-masked]> wrote:
> 
> 
> 
>> On 25. Jan 2018, at 11:40, Tom Jones <[email-masked] <mailto:[email-masked]>> wrote:
>> ...

1) we should have a generic algorithm that should be applicable across all PLPMTUD variants, unless there are specific reasons otherwise. This is a wheel that should not be reinvented for each packetization layer protocol.

2) whatever you *think* “today’s Internet is”, you’re wrong today and you’ll be very wrong in the future. Design to work well in most environments most of the time, and you’ll have “optimized” for the most important case for the Internet - ubiquity and longevity.

Joe