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

[Gorry Fairhurst <[e-mail]>]

Thanks Martin - I think I am starting to understand you issue, so please 
check below:

On 09/12/2019 18:16, Martin Duke wrote:
> gorry, response below:
>
> On Sun, Dec 8, 2019 at 12:38 AM Gorry Fairhurst <[e-mail] 
> <mailto:[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?

So, do you mean that (1) a sender COULD use cwnd to determine whether to 
probe (i.e. only

probe if flight size allows), actually I am OK discounting them from 
this limit

providing they are as infrequent as specified in DPLPMTUD - but I would 
mind if a design

wanted to be a little more conservative. If I understand, this is about 
when to probe.

but (2) but the sender needs to still should realise that attempts to 
raise the PMTU

are likely to fail, so you shouldn't count loss of a probe as 
congestion, which is what

section 3, requirement 7 was about.

> 3) Under what circumstances do probe losses indicate that the packet 
> is too big?
>
That can be clarified - PLPMTU is reduced only when PROBE_COUNT>MAX_PROBES,

so never for an isolated loss.

> 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.
>
See if I understood above?
> 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.
>
Oh, I think I may see...

<<The DPLPMTUD sender treats

        isolated loss of a probe packet (with or without a corresponding
        PTB message) as a potential indication of a PMTU limit for the
        path.  >>

the word "potential" here was expected to read, "not yet confirmed, so 
try again to check...:"

- I see that isn't really clear, and we will rewrite the sentence.


I also now have a note that this could finally prove problematic, and 
we'll check how to best resolve:

<< All of the requirements in [RFC4821  <https://tools.ietf.org/html/rfc4821>] also apply to the use of the
    technique with a datagram PL. >>

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

Gorry