Subject: [quicwg/base-drafts] Streams not contributing to connection-level flow control (#204)

From: Marten Seemann <[email-masked]>
Date: Mon, 23 Jan 2017 05:32:30 -0800

There are currently two problems with streams not contributing to connection-level flow control:

1. There is no way to negotiate which streams don't contribute (and their number is not limited one would have to negotiate an equation). For HTTP the non-contributing stream numbers are defined in the HTTP/QUIC draft, but defining those streams statically might not be suitable for every protocol. Even for HTTP this static definition "wastes" every second stream for GET requests.
2. Non-contributing create a DoS opportunity. Current implementations of the QUIC protocol use a MCSP of 100. That means that a client can consume at least 100 * initial flow control window of memory on the server (and possibly even more since there's no size limit of a GET request). That results to an additional memory consumption of more than 6 MB (for comparison: Chrome and quic-go set the connection-level flow control window to 1.5 MB).

### Possible solution

Non-contributing are needed in the following situation: A client that is uploading data will be connection-level flow control blocked if it is sending data faster than the server is consuming it. In that situation, it makes sense to stop the client from overloading the server with more data, but at the same time allowing it to issue new requests.

The problem could be solved by defining two connection-level flow control windows: One that defines the amount of data that can be sent, and one that is defines the amount of request data and other application-layer control functions. I will refer two the two windows as "data fc window" and "control fc window".

The rules are:

- When a peer opens a new stream, it defines which of the two windows the stream should be counted to (This could be done by the setting a bit in the STREAM frame public flag, but we'd have to steal it from some other field. Maybe there's a better solution?). The association of a STREAM to one of the two window cannot be changed later. Every stream has to contribute to either of the two windows.
- A receiver maintains the two connection-level flow control windows and sends connection-level WINDOW_UPDATEs appropriately (there needs to be a way to distinguish between a WINDOW_UPDATE for the data and for the control window of course. Maybe use a bit of the frame type?). 
- In HTTP all data MUST be sent in the data fc window, and all request, PRIORITY and SETTINGs frames MUST be sent in the control fc window.

The question is: Is this general enough for all protocols? Can the messages in every protocol be mapped into the two categories "data message" and "control message"?

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jan 2017 18:36:42 -0800

I don't think that we should allow for any exemptions at all.  Is there any reason for streams to be exempted?  I'm not aware of a valid reason for exemption.  The crypto handshake is the only thing that is exempted currently and even that isn't strictly necessary if we set a floor on the value.

-- 
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/204#issuecomment-274684510

---

From: Marten Seemann <[email-masked]>
Date: Mon, 23 Jan 2017 18:39:57 -0800

All the HTTP header streams don't contribute to flow control as well.

Having this is desirable. Say a client is doing multiple uploads to a server and used up the full connection-level flow control window. It would be nice if the client was still allowed to send a GET request to start a download.

-- 
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/204#issuecomment-274685021

---

From: Martin Thomson <[email-masked]>
Date: Mon, 23 Jan 2017 19:43:58 -0800

That's a problem that could be fixed by #175.  I tend to think that exempting headers from flow control was a mistake.  Particularly when interpreting headers can be blocked on progress on other streams.

-- 
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/204#issuecomment-274693443

---

From: Mike Bishop <[email-masked]>
Date: Wed, 25 Jan 2017 17:32:35 -0800

How does #175 fix this?  It doesn't change flow control, as far as I understood it.  If the headers are in the same flow control window as the bodies, then the request can be blocked.  

-- 
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/204#issuecomment-275285847

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Jan 2017 17:59:25 -0800

Actually, you are right.  #175 doesn't apply (or my frazzled brain has forgotten the chain of logic that leads to that conclusion).

As for the upload case, that's a problem solved by priority.  If the GET request isn't high enough priority to get access to the flow control window, then clearly waiting is the right thing.

-- 
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/204#issuecomment-275289834

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2017 20:14:18 -0800

Discussed in Tokyo; agreement in the room that we should not exempt anything except stream 1. Follow-on effects on HTTP need a new issue.

-- 
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/204#issuecomment-275304137

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2017 20:29:49 -0800

@MikeBishop suggests collapsing stream 1 into stream 0; editors to pursue using their discretion. Also a question of whether stream 1 should have stream-level flow 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/204#issuecomment-275305548