Re: Unreliable Stream Support for QUIC

["Philipp S. Tiesel" <[e-mail]>]

> On 6. Sep 2017, at 20:30, Mike Bishop <[e-mail]> wrote:
> 
> 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).

It might be that i got the congestion control draft wrong, but I thought most control messages can even be sent if the congestion window or max data are depleted.

Besides that, what byte counts are used for CC seem really weird - as I read it now, all bytes of packets count except “ack only frames” (why not “ack only packets?”) 
That reads for me that a packet containing only an ACK a is not subject to congestion control, but a packet containing an ACK and a MAX_DATA frame is subject to congestion control.
I see no description of what can be sent if congestion window is depleted at all.


> 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…"

Ack


> 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.

Either design solves the "zombie stream issue” and provides input needed for flow control.
We did not add the FIN retransmission variant to the proposal appendix because we ran out of bits to signal unreliable streams.

> 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.

I totally agree. 

I fear #720 does not go well with unreliable streams. It would be sufficient to signal whether a stream is unreliable, bit also needs to be retransmitted if lost and therefore introduce additional head of line blocking.

I guess the best solution would be having a “short” and a “long” stream frame header.
Unreliable, unidirectional and a few other things can be signalled in a “long" stream frame header. Streams can switch to the short header format once packets carrying those flags got acknowledged. I could also imagine to allow 32bit byte offsets only in the long header and that way safe another bit.


> 
> -----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…
> 

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([e-mail])--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: [phone])---<---(jabber: [e-mail])----'