Subject: [quicwg/base-drafts] PADDING frames consume congestion window (#4415)

From: kixelated <[email-masked]>
Date: Mon, 30 Nov 2020 15:12:47 -0800

See [this section](https://www.ietf.org/archive/id/draft-ietf-quic-transport-32.html#section-13.2.7).

I may be missing some context, but I can only think of a single use-case involving PADDING only packets. 

A congestion control algorithm could use PADDING-only packets to fill the congestion control window when application-limited to probe for higher window values. The idea is to use PADDING packets instead of PING packets to reduce spurious ACKs, but this is flawed:

1. The aforementioned deadlock is possible.
To avoid this deadlock, PING packets need to be sent after PADDING packets, although they are susceptible to packet loss. The RFC vaguely recommends sending regular PING frames to compensate, which partially defeats the purpose of using PADDING frames.

2. This only tests the network in one direction. 
The goal is to test the network capacity before utilizing it, but the additional ACK load will not be tested. This is a problem for asymmetric links that may have capacity for PADDING packets, but do not have capacity for STREAM+ACK packets.

3. This probing only works for loss-based algorithms.
Delay-based congestion control algorithms like BBR will need explicit ACKs to measure RTT. They would use PING instead of PADDING.

-- 
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/issues/4415

---

From: kixelated <[email-masked]>
Date: Mon, 30 Nov 2020 15:12:57 -0800

I think that this hypothetical congestion control algorithm should use PING-only packets instead of PADDING-only packets. I don’t think there’s any reason to have this special case and dangerous support for non-congestion-controlled PADDING-only frames.

In general, only ack-eliciting packets should contribute to the congestion control window. Frames like ACK and PADDING do not trigger an acknowledgement to free the congestion control window, so they should not consume it.

-- 
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/issues/4415#issuecomment-736111325

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 30 Nov 2020 15:43:13 -0800

The protocol permits PADDING-only packets, so this text is a treatment to their implications.

I think we're well beyond the point where we can consider prohibiting PADDING-only packets as a design change to the protocol.

-- 
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/issues/4415#issuecomment-736121946