PADDING frames consume congestion window

[kixelated]

See this section.

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.

[kixelated]

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 and dangerous support for 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.

[LPardue]

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.

[mirjak]

You should not send large amount of data for "probing" beyond your congestion window. Your congestion control does implement this probing already. That's the whole idea of congestion control.

[janaiyengar]

I propose closing this with no action, per @LPardue's comment above.

[kixelated]

@mirjak If the application is unable to fully saturate the congestion control window, then it is not possible to increase the window. See this section.

PADDING packets can be used to fully utilize the congestion window such that the window can be increased. My interpretation is that the RFC counts PADDING-only frames towards the congestion window solely for this purpose. I don't think this is justifiable and the RFC would be simpler/safer if the congestion control window only applied to packets with an elicit frame (currently it's an elicit or padding frame).

That being said, yeah it's far too late in the process to make changes now. I wish I had gotten involved earlier! Feel free to close with no action.

[LPardue]

Another purpose of padding is to send QUIC packets when there might otherwise be nothing to send, a possible means of improving privacy protections against traffic analysis. Since the packets consume a resource, its important to recommend a safe default behaviour for congestion.

[mirjak]

@kixelated if the scenario is to fill the cwnd window when there is not enough application traffic in order to further open the cwnd for later, then counting padding into the cwnd is the right thing to do (as you should not send more data then the cwnd allows for this probing)!

[kixelated]

@LPardue Good idea, but a network observer could easily detect that these PADDING packets are not ack-eliciting. You would use PING frames if you wanted to fake STREAM traffic. The only thing you could use PADDING frames for would be to fake ACK-only packets... except your PADDING packets are subject to congestion control. A network observer could potentially use this fact to identify ACK-only versus PADDING-only packets.

@mirjak You would fill the congestion window with PING frames instead of PADDING frames. The difference is that PING frames elicit ACKs, both freeing up the congestion window while verifying the network can handle the additional ACK load.