[tsvwg] DPLPMTUD comments

[Wesley Eddy <[e-mail]>]

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"