Re: [tsvwg] DPLPMTUD comments

[Joe Touch <[e-mail]>]

Some additional comments below...

> On Jul 18, 2019, at 2:05 AM, Gorry Fairhurst <[e-mail]> wrote:
> 
> 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:
> 
> Here are some questions and comments I had on reading the DPLPMTUD draft
> (version -08):
> 
> Technical items:
> 
> -  Interaction w/ UDP options: 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.
> 
> 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

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.

> - 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.
> 
> - 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.
> 
> GF: Agree: /MUST be/needs to be/
> 
> - 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?
> 
> 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.

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.

> - 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.
> 
> - I'm not sure if there are any complications with regard to IPv4/IPv6
> protocol translation / NAT-PT in the path?
> 
> 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.

FWIW, that sort of error makes sense to me.

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

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