Re: [tsvwg] WGLC for DPLPMTUD - WGLC comments, still to be resolved.

[G Fairhurst <[e-mail]>]

Maxim, thanks again for all your comments. These comments below will 
require more help to resolve. Please help us discuss on the list, or 
help by offering some initial text proposals.

Best wishes,

Gorry

Major comments:

1.
RFC 4821 states that “an implementation SHOULD implement some form of 
MTU verification” and I don’t see how that aspect is addressed in 
DPLMTUD. Did I miss it or was it intentionally skipped?
GF: QUERY - I am unsure I understand the question - but maybe this 
relates to always probing a new PLPMTU before it is used - in which 
case, this is covered.

3.
Some PLs like SCTP can’t re-fragment data during retransmission which 
might lead to a problem if PMTU was decreased in run-time or the PLPMTU 
value was discovered wrongly. In some case the data would never be 
retransmitted. This aspect is not covered in the draft. I think it would 
be good at least to recommend to not set DF-bit for retransmitted data 
and to not fragment user data to pieces larger than BASE_PMTU (or even 
MIN_PMTU?).
GF: QUERY What does the WG think?

5.
Sec 3: “A method is REQUIRED to signal an appropriate MPS to the higher 
layer using the PL. ” – In general I don’t see how the draft addresses 
it. Is it up to the PL implementation or the PL specification? I assume 
it requires SCTP Socket API update. If so, is it out of scope of this doc?
GF: Should we specify this?

Minor comments:

6.
Im: The default value is specified for some parameters but not for all 
and without clear explanation of why such values are used as default. 
The same is for recommended values. Shouldn’t it be consistent?
GF : Which parameters do you mean?

9.
Mi: Sec 1.3. why don’t you refer to SCTP specification RFC4960 instead 
of or additionally to RFC4821. Section 7.3 of RFC4960 has a statement 
“An endpoint SHOULD apply these techniques, and SHOULD do so on a 
per-destination-address basis.” so for me it’s more relelvant to refer 
to RFC4960.
GF : Should this document update RFC4960?

17.
Im/Q: Sec 4.4: “MUST suspend” – I assume it’s valid in general even when 
PL is using the other PL like QUIC uses UDP. If so, it would be good to 
clarify.
GF: I did not understand what text to add.

25.
Im: Sec 6.2 (maybe general for Sec 6): It would be good to recommend to 
enable fragmentation (do not set DF bit) for all packets except for 
probes or at least for retransmitted packets.
GF:  i understand and know this is done. in some SCTP implementations. 
What specific text is required?

26.
Im/Q: Sec 6.2: Should or should not probe packets influence assoc and 
path error counters? I think it’s “SHOULD” when a probe is acknowledged 
and “SHOULD NOT” when it’s lost. In other words probes should only clear 
the error counters in my view.
GF: Is this correct below:
NEW:
  A successful probe updates the association and path
             counters, but an unsuccessful probe is discounted (assumed
             to be a result of choosing too large a PLPMTU).