Re: [quicwg/base-drafts] DPLPMTU merge tweaks (#3702)

[msvoelker <[e-mail]>]

@msvoelker commented on this pull request.



> +
+From the perspective of DPLPMTUD, QUIC transport is an acknowledged
+packetization layer (PL). A sender can therefore enter the DPLPMTUD BASE state
+when the QUIC connection handshake has been completed.
+
+
+### Sending QUIC DPLPMTUD Probe Packets
+
+DPLPMTU probe packets are ack-eliciting packets.  Probe packets that use the
+PADDING frame implement "Probing using padding data", as defined in
+Section 4.1 of {{!DPLPMTUD}}.  Endpoints could limit the content of probe
+packets to PING and PADDING frames as packets that are larger than the current
+maximum packet size are more likely to be dropped by the network.
+
+DPLPMTU probe packets consume congestion window, which could delay subsequent
+transmission by an application.

I think here is more to consider. QUIC's loss detection will trigger on a lost probe packet. Even tough this does not lead to a retransmission, since PING and PAD frames won't be retransmitted, one could misinterpret the loss as a congestion signal. It might worth to note that a lost probe packet should not be treated as a congestion signal by the congestion control.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3702#pullrequestreview-420247600