Subject: stream 0 and flow control

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Thu, 10 Aug 2017 21:24:26 +0900

Hi,

The current spec says that stream 0 is exempt from connection level flow
control.  It is still subject to stream-level flow control.  But the spec
does not allow MAX_STREAM_DATA frame in Client cleartext and Server
cleartext.  So if credit is exhausted, peer cannot send more STREAM frame,
and opposite peer also cannot extend the offset, which creates deadlock.
Is it just an editorial issue that MAX_STREAM_DATA is missing in Client
cleartext or Server cleartext?  Or are there any other way to handle this
situation?  Should we assume that initial max offset is sufficient for TLS
handshake?

Best regards,
Tatsuhiro Tsujikawa

---

From: Ian Swett <[email-masked]>
Date: Thu, 10 Aug 2017 12:46:06 -0400

I believe the assumption is that the initial max offsets are sufficient for
the TLS handshake.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Aug 2017 12:09:13 +1000

s/initial/default, but yes.

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 11 Aug 2017 19:00:30 +0900

2017/08/11 11:09 "Martin Thomson" <[email-masked]>:

> I believe the assumption is that the initial max offsets are sufficient
for

Thank you.  What should implementation do when that assumption fails?
As for default max stream data, I failed to find it anywhere in the docs.
I thought that max stream data in transport parameters is applied to stream
0 as well, but do you mean that stream 0 always gets the default max stream
data, unaffected by transport parameters?

Best regards,
Tatsuhiro Tsujikawa

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Aug 2017 20:32:11 +1000

> Thank you.  What should implementation do when that assumption fails?

The client has to start over if it receives HelloRetryRequest (we
should write that down), so it only has one ClientHello to send before
it receives transport parameters from the server.  That means that it
has whatever the initial value is, less up to just near 1200 octets in
its second flight.  If the server asks for a client certificate, then
it is possible to blow out the handshake, but you'd have to try.  63k
is a very bloated certificate.  If you did somehow manage to get one
of those, then the server can send MAX_[STREAM_]DATA in its "0.5 RTT
data", so it's not fatal even if you did blow the limit (it just
delays the completion of the handshake).

The server could genuinely be a problem, because it can't receive
anything but the transport parameters that set MAX_STREAM_DATA from
the client before the handshake is complete.  It also has a larger
handshake more often.  It still largely comes down to certificate
size, and if it can't fit a certificate in the space that the client
gives it, then that's a big problem with the certificate.

If the server has too large a certificate and the client sets too low
an initial MAX_STREAM_DATA, I think that we have a choice:

  https://github.com/quicwg/base-drafts/issues/725

> As for default max stream data, I failed to find it anywhere in the docs.

Yeah, I spoke to hastily before.  We don't need defaults or initial
values because no peer other than the client sends a packet in
ignorance of the limits of the other side.  The only packet that the
client sends is the ClientHello, which is size-limited (at least by
the MTU - I guess in theory it could take up a whole 64k jumbogram).

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Fri, 11 Aug 2017 23:28:05 +0900

2017/08/11 19:32 "Martin Thomson" <[email-masked]>:

Thank you for detailed explanation.  I have not noticed .5 rtt data, it's
clever idea.

Best regards,
Tatsuhiro Tsujikawa