Subject: [tsvwg] DPLPMTUD comments

From: Wesley Eddy <[email-masked]>
Date: Wed, 17 Jul 2019 21:30:25 -0400

Here are some questions and comments I had on reading the DPLPMTUD draft 
(version -08):

Technical items:

-  Interaction w/ UDP optoins: I think there is an implicit assumption 
about code for DPLPMTUD needing to be aware of the actual UDP datagram 
size when UDP options are used, and not the length from the UDP 
header?   So, the application that's asking for UDP options to be tacked 
on needs to also know how big those options will wind up being, 
including possible padding, in order to stay within the PMTU.  It seems 
like there should be some description  of how this interaction needs to 
work or be handled in an application or library.

- Reading Section 1.1 & 1.2, I was wondering if another motivation could 
be that ICMP is totally unauthenticated, making it another problem to 
rely on for classical PMTUD (it can be spoofed, etc).

- Sec. 3 bullet #8 saying "MUST be robust to the wide variety of 
underlying network forwarding behaviors" seems pretty useless to me 
(even though I don't argue that it's true).  It's just not specific 
enough for an implementer to do anything specific with. I believe that's 
more of a rationale for why we do things in the specification rather 
than a requirement for implementation.

- Section 3 in the bullet on "When to probe", I'm not sure how path 
changes would actually be known to the end host.  Can we give a hint 
about what some of these methods for determining a path change might 
be?  Are you thinking about L2 and L3 triggers and signalling?

- In 4.4.2, the rule uses the symbol MIN_PMTU, but the text below uses 
68 and 1280 bytes sepaately for IPv4 and IPv6 paths ... is that really 
necessary since the whole point of having MIN_PMTU defined seems to be 
to represent the correct value?

- I'm not sure if there are any complications with regard to IPv4/IPv6 
protocol translation / NAT-PT in the path?

- In 4.4.2, the bullet "The information could be utilized as an input to 
trigger enabling a resilience mode." ... I have no idea what this is 
trying to say.  Either we should recommend some specific behavior be 
triggered or not, but this statement seems like a vague hint.

- There's an author's note at the end of Sec. 4 about how to handle 
PTB_SIZE = 0.  I was wondering what would cause this, if it's a real 
possibility or not?  Also, wouldn't PTB_SIZE < BASE_PMTU be the more 
general  condition to handle, that would also encompass the zero value?

- Section 5 says "DPLPMTUD SHOULD NOT be used by an application if it is 
already used in a lower layer", but there doesn't seem to be rationale 
for that ... is it just something that scares us, or is there a problem 
we're trying to avoid?  Also, how would a higher layer know if a lower 
layer implements it or not?

- The relation between phases and the actual state machine is slightly 
fuzzy.  It seems kind of duplicative, since it seems like the state 
machine description is sufficient by itself, and the description of 
phases is just a higher-level version of what it contains?

- Security considerations says "Parallel forwarding paths SHOULD be 
considered."  This seems to need a bit more work.  Of course it's true, 
but it seems like we the working group need to consider it and say what 
the security threats and risks are, or where in the spec the correct 
behavior is described that makes it robust.

Purely editorial:

- In Sec. 1.1, first paragraph, should "method that from" be "method from"?

- Sec. 3 bullet #8 mentions the destination cache and 6.1 mentions the 
"PLPMTU cache", but I think these both need to be first mentioned in the 
terminology section.

- In 4.4.2, the BASE_PMTU and MIN_PMTU are used, even though they're 
undefined at this point.  They come later in 5.1.2 where constants are 
defined.

- Change "folloowing" to "following"

---

From: Joe Touch <[email-masked]>
Date: Wed, 17 Jul 2019 18:43:18 -0700

Hi, Wes,

> On Jul 17, 2019, at 6:30 PM, Wesley Eddy <[email-masked]> wrote:
> 
> Here are some questions and comments I had on reading the DPLPMTUD draft (version -08):
> 
> Technical items:
> 
> -  Interaction w/ UDP optoins: I think there is an implicit assumption about code for DPLPMTUD needing to be aware of the actual UDP datagram size when UDP options are used, and not the length from the UDP header?   So, the application that's asking for UDP options to be tacked on needs to also know how big those options will wind up being, including possible padding, in order to stay within the PMTU.  It seems like there should be some description  of how this interaction needs to work or be handled in an application or library.

Yes, and this is the same (FWIW) as TCP. MTU means TCP payload *irrespective of TCP options*, and the same is true here. Worth mentioning (and worth noting as the same).

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 18 Jul 2019 10:05:48 +0100

Thanks Wes for your careful read, that is really helpful!!!

Please see responses in-line below. Other people do please also comment,
and we'll incorporate all the editorial corrections next rev., and propose
text for the outcomes from the other points from this thread.

---
Wes:

Technical items:

-  Interaction w/ UDP options: I think there is an implicit assumption

GF: This seems true to me, in that any PL has to know the max size
of data it is allowed to send. This could also be said in UDP-Options.

TJ: If the application cannot learn the option overhead, it just because a
strange tunnel with variable overhead. I would hope that nothing tries
to do dplpmtud on top of udp options. This is potentially another case
of dplpmtud/dplpmtud

  - Reading Section 1.1&  1.2, I was wondering if another motivation could
be that ICMP is totally unauthenticated, making it another problem to
rely on for classical PMTUD (it can be spoofed, etc).

GF: True. ICMP processing does not provide authentication protection.
The validation described at least provides a check that a sender of
an ICMP message had on-path information. We can add text.

GF: Agree: /MUST be/needs to be/

GF: Perhaps, and that would be OK to say. I was also thinking that
the RTO expiry in a transport is usually regarded as a potential
signal that the path characteristics have changed. I am interested
in more wisdom here, because the current statement seems to lack
detail.

TJ: I think detecting path changes is still open. The mechanism you
suggest are one way to do it, there might be more. PANRG might be
interested in figuring this out.

  - In 4.4.2, the rule uses the symbol MIN_PMTU, but the text below uses
68 and 1280 bytes separately for IPv4 and IPv6 paths ... is that really
necessary since the whole point of having MIN_PMTU defined seems to be
to represent the correct value?

TJ: The values we provide are our definitions of MIN_PMTU for v4
and v6. There is redundancy, but the numbers are good to have.

GF: Possibly, this could find a v4 segment of the path that
doesn't support the MIN_PMTU for IPv6. This doesn't change that.
I'm not sure what you would like to be written?

TJ: Ah! This seems to be a great way to offer a path that doesn't
support v6 MIN MTU. I think we get kicked into the error state
if we are a v6 sender on a NAT-PT path with a small PMTU.

GF: The options are to ignore or treat as Error (we can think of more
clever things to do, but currently we think a simple approach
is best to standardise). I think the simplest would be to ignore this
case (in which case we can remove this bullet and leave the remains text).

- There's an author's note at the end of Sec. 4 about how to handle
PTB_SIZE = 0.  I was wondering what would cause this, if it's a real
possibility or not?  Also, wouldn't PTB_SIZE<  BASE_PMTU be the more
general  condition to handle, that would also encompass the zero value?

GF: I do not have any more detail about how common it is to receive
PTB_SIZE = 0. My co-authors may be able to say more.
Something perhaps to measure in future?

GF2: It would be helpful to add text for the case for PTB_SIZE<MIN_PMTU.
- Since this is illegal, i.e. less than the permitted minimum,
I suggest we explicitly IGNORE this. (We could choose the same action as
for MIN_PMTU<  PTB_SIZE<  BASE_PMTU ... but I'd argue that case can
arise from parallel forwarding paths, etc and therefore it is appropriate
to treat in the error handling, whereas TB_SIZE<MIN_PMTU is
always inconistent with the PL's understanding of the min PMTU). Does that
seem reasonable?

GF: This can lead to inefficient use of the path. We will say that.

However, I think we could also add a note, something like:

This can result in interactions
between the different protocol mechanisms, potentially
causing erroneous state transitions.
For example, a lower (D)PLPMTUD method that uses what is described as
  "Probing using application
data and padding data" (section 4.1) could further pad
an upper layer probe packet - changing the size of probe
that was sent and potentially leading to loss (which
the upper layer could assume was congestion) and
then possibly also could
conclude that the high layer probe size did not work.
Using methods with "Probing using padding data"
is expected to mitigate such unwanted interactions.

TJ: The application can only work from prior knowledge or a signal/api
from the lower layer. This note helps app developers know that should
look below before implementing and consider that the lower layer might
be trying too.

GF: Yes, it is a higher-level description. The nuance was that
this was intended to show an implementation can be simple or
sophisticated. We can look at this again, and try to focus the text more.

GF: I agree.
This is a topic where the current authors would indeed welcome more insight.

Ideally, we'd love measurement data, understanding of pathologies that
can and do occur. That's a great research project - and we'd be keen to
do such measurements!

We'd also like to see and test ideas about how to mitigate this...

  Purely editorial:

GF: I suggest to remove:
"    The folloowing sections identify the components needed for
    implementation, provides an overvoew of the phases of operation, and
    specifies the state machine and search algorithm."

Gorry & Tom

---

From: Joe Touch <[email-masked]>
Date: Thu, 18 Jul 2019 21:56:47 -0700

Some additional comments below...

> On Jul 18, 2019, at 2:05 AM, Gorry Fairhurst <[email-masked]> wrote:
> 

This is the same as for TCP - there’s always a possibility that a tunnel needs breathing room that isn’t discoverable directly. That’s why PLPMTUD sends probes of different sizes.

The user can definitely learn the option overhead.

> interested in figuring this out.

I don’t think path changes can necessarily be detected. That’s why probes should be periodic - there’s no “failure to make progress” at the transport layer that helps you otherwise.

> if we are a v6 sender on a NAT-PT path with a small PMTU.

FWIW, that sort of error makes sense to me.

> We'd also like to see and test ideas about how to mitigate this…

Why? either they have stable PMTUs or not; especially if the paths have other similar properties, there’s nothing to do here other than keep checking PLPMTU and see if it varies or not.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 19 Jul 2019 10:25:27 +0100

On 19/07/2019, 05:56, Joe Touch wrote:
>> On Jul 18, 2019, at 2:05 AM, Gorry Fairhurst<[email-masked]>  wrote:
>>
Yes.
> I don’t think path changes can necessarily be detected. That’s why probes should be periodic - there’s no “failure to make progress” at the transport layer that helps you otherwise.
Probes are periodic, and indeed necessary.

Explicit path signals add more context to deciding to probe (and perhaps 
what probe size to first atempt).
They could in future:
-  suggest a value to probe;
-  be received before the probe timer expires (reducing black-holing of 
data sent with too large a size);
-  may help show-up variability between different devices that appear on 
path.

I think there is reasearch here - and I really hope opportunites to do 
better than present. We do not rely on this.
> FWIW, that sort of error makes sense to me.
Yes.
> Why? either they have stable PMTUs or not; especially if the paths have other similar properties, there’s nothing to do here other than keep checking PLPMTU and see if it varies or not.
We got a long way with wide-scale meaurements to inform how to proceed 
with DiffServ. I found very little data on what actually happens along 
real paths with PMTU discovery methods.

So, with my research hat on, I'd like to explore what pathologies we 
really see, and what range of signals we see. We have tantilizing data 
that showed that some paths support a larger MTU than PMTUD discovered, 
and many cases where PMTUD failed to find the PMTU.  I suggest the 
end-game could be some experimental approaches and finally some results 
to help:
(1) Avoid silly / inconsistent signals that cause spurious probing.
(2) Detect anomolies and continue (some) probing, but don't tell the app 
that a PMTU works and then shortly after discover it didn't work reliably.

IMHO this is research to be done, especially if we wish to push for 
larger PMTUs. I'm happy to do this as soon as I can find resources, and 
share what we find - but I don't imagine the results will appear 
immediately.
> Joe
Gorry