Subject: Re: [quicwg/base-drafts] Stream Flow Control on Stream 0 (#1252)

From: martinduke <[email-masked]>
Date: Sat, 07 Apr 2018 12:37:06 -0700

@siyengar The specific case I am worried about is when there are missing bytes in the transport and the TLS buffers don't come into play. According to the spec, there is no bound as to what the transport must buffer on stream 0.

I agree that QUIC flow control is irrelevant when we're talking about TLS buffers.

Allowing flow control during the handshake would allow the server to limit its memory usage until the client fills in the missing bytes.

-- 
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/1252#issuecomment-379493909

---

From: Subodh Iyengar <[email-masked]>
Date: Sat, 07 Apr 2018 20:03:13 +0000 (UTC)

@martinduke What I'm suggesting is that even if there is flow control, a rational receiver will never set flow control < tls buffer size at which point it doesn't really matter whether the buffer is in the transport buffer out of order or in order, which means that flow control is not useful.

-- 
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/1252#issuecomment-379495515

---

From: Ryan Hamilton <[email-masked]>
Date: Sun, 08 Apr 2018 02:08:28 +0000 (UTC)

I agree with martin duke. Instead of an implicit limit, we should have
explicit limits. If there is no flow control at the QUIC layer, then a
malicious peer will be able to consume unlimited memory in the receive
buffer by sending all but the first byte on stream 0. This is clearly a
non-starter so an endpoint is definitely going to impose a limit. I can't
see any upside to having an implicit limit here, and only downsides.

-- 
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/1252#issuecomment-379513320

---

From: Subodh Iyengar <[email-masked]>
Date: Sat, 07 Apr 2018 19:32:27 -0700

@RyanAtGoogle don't understand what you mean, the sender would set a limit. Setting a limit below the limit that tls imposes is useless. I think communicating that limit is fine, but flow control is the wrong tool for that job because the limit is not an independent limit but due to the reasoning I laid out it's facetious to communicate any limit < tls limit. 

-- 
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/1252#issuecomment-379514369

---

From: Ryan Hamilton <[email-masked]>
Date: Sat, 07 Apr 2018 20:42:08 -0700

Not imposing a limit smaller than TLS seems reasonable. But that does not
seem to me to be an argument AGAINST 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/1252#issuecomment-379517559

---

From: Subodh Iyengar <[email-masked]>
Date: Sat, 07 Apr 2018 22:37:45 -0700

We don't need flow control to impose a limit >= TLS. If TLS legitimately needed more bytes to complete, an implementation to increase the "flow control" limit to match it even for out of order bytes, at which point what use is flow control? 

In the case where bytes arrived in order, flow control is giving us a facetious sense of limit, because if TLS is actually buffering the bytes and then we would advertise a larger number of bytes which potentially could go beyond the bounds of what TLS would accept.

My point is that flow control in the sense of the way it is implemented for other streams is inappropriate for the crypto stream.

-- 
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/1252#issuecomment-379522088

---

From: martinduke <[email-masked]>
Date: Fri, 13 Apr 2018 21:48:53 -0700

Hi Subodh,

I can see from this thread that we are talking past each other. Someone (probably me) is being dense about what to worry and not worry about. If Ekr doesn't obviate the whole discussion with crypto streams, let's talk about this face-to-face in Stockholm.

-- 
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/1252#issuecomment-381303298

---

From: Subodh Iyengar <[email-masked]>
Date: Sat, 14 Apr 2018 07:03:39 +0000 (UTC)

sounds great, @martinduke

-- 
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/1252#issuecomment-381309051