RE: Unreliable Stream Support for QUIC

[Mike Bishop <[e-mail]>]

Reading through the draft, a few thoughts with no particular organization.

Your proposal says that "Unreliable streams are subject to regular congestion control.  CLOSE_STREAM Frames are, like ACK and RST_STREAM frames not subject to congestion control."  I'm not sure where you're finding that ACK and RST_STREAM frames are ignored by congestion control, nor what it means for a frame not to be subject to congestion control (which deals with packets).

I think in 5.3 you might want to expand on what you mean by "UDP-like behavior."  Perhaps something like "Unreliable streams prefer data loss rather than delayed delivery due to retransmission.  Applications which need to avoid delays in the initial transmission would also need to ensure..."

I really dislike the "zombie stream" issue.  I'm not opposed to the CLOSE_STREAM design, though I'd note that you could as easily say that a STREAM frame bearing a FIN MUST be delivered reliably.  If an implementation wants to retransmit it without data, that would still be valid.  Either way, flow control requires that the final offset be delivered reliably regardless of whether the data is.

My other hesitation with a CLOSE_STREAM frame is that it increases the overhead of an application using the stream-as-message abstraction.  (And using RST_STREAM NO_ERROR to indicate normal closure even more so -- spending the bytes to transport an error code for every stream when most of them won't need it seems excessive.)

As with #720, this adds even more stream properties.  I am wondering whether there's value in simply having a collected declaration of what a stream's properties are, and how we might handle this with a minimum of bytes per the previous thought.

-----Original Message-----
From: QUIC [mailto:[e-mail]] On Behalf Of Philipp S. Tiesel
Sent: Tuesday, September 5, 2017 9:30 AM
To: QUIC WG <[e-mail]>
Subject: Unreliable Stream Support for QUIC

Hi,

as promised, we just submitted a draft on unreliable streams for QUIC, including support for partial reliability: 
   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tiesel-quic-unreliable-streams%2F&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Cc14329b9f7ac46f21d6508d4f47b6f88%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636402258384840440&sdata=8DIkFAbzCylWgO6%2FSB5EjBSSt50z5Pp51VJcOPWrits%3D&reserved=0

TL;DR: 

 - In principal, supporting unreliable streams in QUIC
   does not require changes to the datft-05 wire-protocol.

 - To get a nice interface between QUIC transport and the
   application, we need one bit in the stream frame header
   to indicate whether a stream is supposed to be reliable.


To give an application example, we did also draft how HTTP/2 over QUIC can be extended to support partial reliability based on the draft above:
   https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-tiesel-quic-unreliable-http%2F&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Cc14329b9f7ac46f21d6508d4f47b6f88%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636402258384840440&sdata=hBcFX4o0aE5Z8i4MZszSkLXh23DT7GjMFwW4FgrpAec%3D&reserved=0

We have no finished implementation yet, but are working on one. 

AVE!
  Philipp S. Tiesel / phils…