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

[Martin Duke <[e-mail]>]

Responses inline

On Sat, Dec 7, 2019 at 8:04 AM Michael Tuexen <
[e-mail]> wrote:

> > On 7. Dec 2019, at 02:03, Martin Duke <[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.


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