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

From: mirjak <[email-masked]>
Date: Tue, 01 Dec 2020 07:39:34 -0800

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.

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

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 01 Dec 2020 16:01:32 -0800

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

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

---

From: kixelated <[email-masked]>
Date: Tue, 01 Dec 2020 16:45:16 -0800

@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](https://tools.ietf.org/html/draft-ietf-quic-recovery-32#section-7.8).

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.

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

---

From: kixelated <[email-masked]>
Date: Tue, 01 Dec 2020 16:50:28 -0800

Closed #4415.

-- 
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#event-4059888173

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 01 Dec 2020 16:51:08 -0800

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.

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

---

From: mirjak <[email-masked]>
Date: Wed, 02 Dec 2020 02:19:07 -0800

@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)!

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

---

From: kixelated <[email-masked]>
Date: Fri, 04 Dec 2020 00:06:10 -0800

@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 PROBE 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.

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