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

[Martin Duke <[e-mail]>]

gorry, response below:

On Sun, Dec 8, 2019 at 12:38 AM Gorry Fairhurst <[e-mail]>
wrote:

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

I think this reply conflates three questions that need not be unified:
1) Are Probe packets counted against flightsize?
2) Are Probe packet losses treated as congestion signals?
3) Under what circumstances do probe losses indicate that the packet is too
big?

IMO these design decisions can be completely independent -- they certainly
are in our QUIC code, which uses a bastardized version of PLPMTUD.

For #1, as I replied to Michael, the SCTP section is doing the right thing
but I would like general advice for other congestion controls to not count
probes at all. At the moment the QUIC spec suggests that probes would count
against flightsize.

The draft is fine with respect to #2.

If #3 is an intentional change from the "probe inconclusive" text in 4821,
then the draft text is fine. However, Requirement 7 of Section 3 says
"*isolated* loss of a probe packet" is an indication the path does not
support the packet size. Either strike "isolated," or my original comment
stands.


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

The requirement is fine except for the comment in #3 above.

Martin