Subject: [quicwg/base-drafts] Packet reordering / loss distorts open stream limits (#217)

From: Mike Bishop <[email-masked]>
Date: Mon, 23 Jan 2017 21:23:16 -0800

For illustrative purposes, consider a server with an max open stream limit of 2.  The client sends packets with frames in the following order:

1. Open stream 3
2. Open stream 5
3. Close stream 5
4. Open stream 7

The network reorders packets 3 and 4. From the server's perspective, the client has violated the maximum.  In order to deal with this, the server will presumably need something more complicated than just "if violated, kill" -- maybe kill the connection if it *remains* violated for more than 1-2 RTT?

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

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 23 Jan 2017 21:38:26 -0800

The problem will become more apparent when using push, since the server will open _and_ close the streams opposed to pull in which in normal case a client opens the streams and a server closes them.

-- 
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/217#issuecomment-274714668

---

From: Aron-Schats <[email-masked]>
Date: Tue, 24 Jan 2017 10:48:24 -0800

Similar scenario is described in issue #200.  This was discussed in proto-quic:

https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/27ee0fWisTc

-- 
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/217#issuecomment-274897884

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 Jan 2017 15:34:15 -0800

I don't like the notion that we have to have some "slop" in the limits.  That's an opening that an attacker might use for denial of service.

This could be addressed by having an endpoint consider a stream up until the point that it receives acknowledgment of its close, as Ryan claims that Google's code currently does.

However, I don't think that Ryan's point about waiting for a server FIN is enough.  That only works if the client completes its transmissions before the server completes its transmissions (i.e., the server FIN is an implicit acknowledgment of a client FIN).  We've plenty of cases where servers finish first in HTTP/2, see #165 for an example.

Contrary to what @kazuho suggests, this could work when a server pushes because the client does have to send a FIN on the server-initiated streams.  QUIC doesn't transition from the reserved state into a half-closed state like in HTTP/2, so the client has to close its side before the stream becomes closed.  My original idea there was to insist that the client FIN as soon as possible, but it could wait and send the FIN as an acknowledgment.  Of course, that doesn't fix the problem for client-initiated streams at all.

This might be addressed by #175.

-- 
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/217#issuecomment-274973959