Re: [tsvwg] Review: draft-ietf-datagram-plpmtud-12

[Gorry Fairhurst <[e-mail]>]

See below on losses.

On 07/12/2019, 19:27, Martin Duke wrote:
> Responses inline
>
> On Sat, Dec 7, 2019 at 8:04 AM Michael Tuexen 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     > On 7. Dec 2019, at 02:03, Martin Duke <[e-mail]
>     <mailto:[e-mail]>> wrote:
>     >
>     >
>     > 1. Unless I missed it, there is no guidance as to whether probe
>     packets should count against flightsize for congestion control.  I
>     would suggest that this standard exempt MTU probes from CC if not
>     using application data (possibly preempting other standards).
>     At least this is what is done for SCTP:
>
>     6.2.  DPLPMTUD for SCTP
>
>     Section 10.2 of [RFC4821] specifies a recommended PLPMTUD probing
>     method for SCTP.  It recommends the use of the PAD chunk, defined in
>     [RFC4820] to be attached to a minimum length HEARTBEAT chunk to build
>     a probe packet.  This enables probing without affecting the transfer
>     of user messages and without interfering with congestion control.
>     This is preferred to using DATA chunks (with padding as required) as
>     path probes.
>
>     Maybe we should replace "without interfering with congestion control"
>     by "without interfering with congestion control and flow control"
>
>
> I agree that the SCTP section addresses SCTP specifically, but I would 
> hope for more general guidance.
>
>     >
>     > Cons:
>     > - This is conflicts with existing protocol designs (like QUIC)
>     I thought in QUIC you also have the possibility to probe with
>     non-user data.. Am I wrong?
>
>
> QUIC has plenty of non-user data. However, PADDING frames count 
> against flightsize according to the quic-recovery draft. Probe packets 
> are already an exception to congestion control in their loss response, 
> and I'm arguing for a further exception for flightsize.
>
>     >
>     > Personally, I find the 4821 language to be quite vague and I
>     would like an example safe algorithm (for example, off the top of
>     my head, " decrement PROBE_COUNT for each non-probe packet lost
>     between when the probe packet is sent and it is declared lost").
>     Why would the handling of non-probe packets affect PROBE_COUNT?
>
>
> IMO a naive reading of Section 5 is that I should increment 
> PROBE_COUNT for each loss of a probe regardless of the overall loss 
> context. 4821 recommends simply ignoring the probe loss (not 
> incrementing PROBE_COUNT) if there are other losses. I would like 
> something of this nature explicitly discussed in Sec 5.
True RFC4821 allows a sender to have a heueristic that can differentiate 
isolated probe loss, and loss as a part of a wider loss event, and then 
to count a loss during a wide loss event as "congestion" loss (i.e., 
reneging on the probe not being considered congestion-controlled and 
making the approriate adjustments retrospectively to cwnd, even though 
the probes were not originally counted as congetsion-controlled.) That 
makes the congestion control reaction slightly stronger, and would 
enable a probe count to not be adjusted (because the probe was no longer 
treated as a special non-CC packet), and would then allow the probe to 
be resent any number of times following some heuristic determines it is 
safe to resend.

This is complicated  and as  RFC4281 notes "

    Most of the difficulty in implementing PLPMTUD arises because it
    needs to be implemented in several different places within a single
    node."

and  I am also unaware of running code that actually implemented these 
more complex interactions that RFC4821 permits.

In contrast DPLPMTUD takes the approach that this complexity can be 
avoided by simply limiting the probing - such that failed probes are not 
counted against the cwnd, but then only a certain number (max probes) of 
unproductive probes can be sent, before the sender concludes that PLPMTU 
is not raised.

If that's acceptable, do we need to ad to Requirement 7 in Section 3 , 
which currently says this:

Loss of a probe packet SHOULD NOT be treated as an indication of congestion.
- That can be improved if you have suggestions.



>     >
>     > Sec 6.2.3.4 I think it is too strong to say that DTLS makes SCTP
>     Common Header validation "not possible". There are certainly
>     somewhat expensive options like storing the beginning of each
>     encrypted packet or re-encrypting a stored copy of the plaintext
>     packet to compare.
>     So you advocating that the DTLS layer
>     (a) stores the last N messages sent out
>     (b) does the ICMP handling and packet verification.
>     Are you aware of a DTLS implementation doing this?
>     Is the necessary verification step specified?
>
> I am certainly not advocating for anything like this. I am merely 
> nitpicking that the statement that this is "not possible" is too strong.
>
> Thanks,
> Martin
Gorry