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

[Jana Iyengar <[e-mail]>]

Right, agreed.

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

> 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:[e-mail]] *On Behalf Of *Aron .
> *Sent:* Tuesday, November 29, 2016 10:51 AM
> *To:* Jana Iyengar <[e-mail]>
> *Cc:* IETF QUIC WG <[e-mail]>
> *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 <[e-mail]> wrote:
>
> Hi Aron,
>
>
>
> Apologies for getting to this late -- the IETF kept me busy.
>
>
>
> [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?
>
>
>
> 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
>
>
>
>
>