Subject: [QUIC] Why not be explicit about Stream 3 flow control exception?

From: "Aron ." <[email-masked]>
Date: Mon, 14 Nov 2016 15:45:14 -0500

Hello,

[draft-hamilton-quic-transport-protocol-01] states (p. 35):

o The crypto handshake stream, Stream 1, MUST NOT be subject to
congestion control or connection-level flow control, but MUST be
subject to stream-level flow control.
o An application MAY exclude specific stream IDs from connection-level
flow control. If so, these streams MUST NOT be subject to
connection-level flow control.

The second bullet point is obviously about Stream 3.  Seeing that there is
no way(?) to negotiate which streams are to be excluded, why not spell out
that Streams 1 and 3 are not subject to connection-level congestion control?

  Aron.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 14 Nov 2016 22:32:16 +0000

Presumably because other protocols might need more, or different, or no, streams to be exempted.  The thing that’s actually missing is the definition of a mechanism for the application protocol to tell the transport which streams to exclude.  (And I’d be inclined to have something sent on the wire so the other side knows what you’re doing, though there’s a case to be made that application protocol agreement includes both sides agreeing to make the same call into their QUIC stack.)

From: QUIC [mailto:[email-masked]] On Behalf Of Aron .
Sent: Tuesday, November 15, 2016 5:45 AM
To: [email-masked]
Subject: [QUIC] Why not be explicit about Stream 3 flow control exception?

Hello,

The second bullet point is obviously about Stream 3.  Seeing that there is no way(?) to negotiate which streams are to be excluded, why not spell out that Streams 1 and 3 are not subject to connection-level congestion control?

  Aron.

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 29 Nov 2016 10:45:26 -0800

Hi Aron,

Apologies for getting to this late -- the IETF kept me busy.

> that Streams 1 and 3 are not subject to connection-level congestion control?

The second bullet point is about any application-chosen stream. An
application may choose to not exempt any stream if there are no special
streams.

This need not be negotiated on the wire, but can be known for any given
application. Specifically, the http-mapping draft is the document which, in
the current design, should say that stream 3 should be excluded from
connection-level flow control.

- jana

---

From: "Aron ." <[email-masked]>
Date: Tue, 29 Nov 2016 13:51:05 -0500

This is interesting.  Is there a way for QUIC peer to tell which protocol
over QUIC is used?  In other words, at which point do I realize that it's
not HTTP/QUIC I am talking to?  Is it for upper-level code to figure out?

On Tue, Nov 29, 2016 at 1:45 PM, Jana Iyengar <[email-masked]> wrote:

>> The second bullet point is obviously about Stream 3.  Seeing that there
>> is no way(?) to negotiate which streams are to be excluded, why not spell
>> out that Streams 1 and 3 are not subject to connection-level congestion
>> control?
>>
>

---

From: Mike Bishop <[email-masked]>
Date: Tue, 29 Nov 2016 23:08:15 +0000

Protocol negotiation (like many areas) needs to be ironed out.  I see some obvious paths here:

  *   Use ALPN in the TLS handshake
     *   Implies a general requirement on the crypto handshake to support app-layer protocol agreement
  *   Use port numbers, like TCP/UDP already do
     *   QUIC is a new transport that shares the UDP port space; same rules for interpreting incoming messages can apply

I tend toward a combination of the two, since we’ve already seen HTTP/2 get into the pickle that I still need to do version negotiation even once I know it’s some flavor of HTTP.

From: QUIC [mailto:[email-masked]] On Behalf Of Aron .
Sent: Tuesday, November 29, 2016 10:51 AM
To: Jana Iyengar <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
Subject: Re: [QUIC] Why not be explicit about Stream 3 flow control exception?

This is interesting.  Is there a way for QUIC peer to tell which protocol over QUIC is used?  In other words, at which point do I realize that it's not HTTP/QUIC I am talking to?  Is it for upper-level code to figure out?

On Tue, Nov 29, 2016 at 1:45 PM, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Aron,

The second bullet point is about any application-chosen stream. An application may choose to not exempt any stream if there are no special streams.

This need not be negotiated on the wire, but can be known for any given application. Specifically, the http-mapping draft is the document which, in the current design, should say that stream 3 should be excluded from connection-level flow control.

- jana

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 29 Nov 2016 17:17:47 -0800

Right, agreed.

On Tue, Nov 29, 2016 at 3:08 PM, Mike Bishop <[email-masked]>
wrote:

>    - Use ALPN in the TLS handshake
>       - Implies a general requirement on the crypto handshake to support
>       app-layer protocol agreement
>    - Use port numbers, like TCP/UDP already do
>       - QUIC is a new transport that shares the UDP port space; same
>       rules for interpreting incoming messages can apply
>
>
>
> I tend toward a combination of the two, since we’ve already seen HTTP/2
> get into the pickle that I still need to do version negotiation even once I
> know it’s some flavor of HTTP.
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Aron .
> *Sent:* Tuesday, November 29, 2016 10:51 AM
> *To:* Jana Iyengar <[email-masked]>
> *Cc:* IETF QUIC WG <[email-masked]>
> *Subject:* Re: [QUIC] Why not be explicit about Stream 3 flow control
> exception?
>
>
>