Subject: Unreliable Stream Support for QUIC

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 5 Sep 2017 18:29:48 +0200

Hi,

as promised, we just submitted a draft on unreliable streams for QUIC,
including support for partial reliability: 
   https://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-streams/

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://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-http/

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

AVE!
  Philipp S. Tiesel / phils…

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 5 Sep 2017 17:20:32 +0000

Hi Philipp,

Thanks for publishing these. I've only had a chance to skim read so I only have a basic question right now.

For the HTTP/QUIC mapping, have you considered server push? The document doesn't mention anything but I wonder if you have some ideas. I'm thinking that the push promise includes your request header to indicate to the client that the pushed body will be unreliable. An alternative would be to have all pushed streams inherit the reliability of the parent stream. 

Kind regards
Lucas
________________________________________
From: QUIC [[email-masked]] on behalf of Philipp S. Tiesel [[email-masked]]
Sent: 05 September 2017 17:29
To: QUIC WG
Subject: Unreliable Stream Support for QUIC

Hi,

TL;DR:

AVE!

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Wed, 6 Sep 2017 11:37:08 +0200

> On 5. Sep 2017, at 19:20, Lucas Pardue <[email-masked]> wrote:
> 
> Hi Philipp,
> 

We have not thought about server push yet.

As the server knows from the QUIC handshake that the client, in principle, supports unreliable streams, HTTP/2 can use this knowledge.

For draft-04, I agree with your first proposal, as the push-promise headers should be the same as the request headers. The push stream is then opened as unreliable stream.
 
For draft-05, the Server push description looks kind of broken to me. It still references the request/response streams as used in -04 and the frames needed for reference are gone.
Assuming a sensible implementation with a new stream first carrying a PUSH_PROMISE frame, then a bunch of DATA frames, the server must open the push stream as unreliable and only retransmit the content of the PUSH_PROMISE and probably late HEADERS frames.

While I linke the design and will include it in the next version of the draft, I fear it might not work well over multicast.

AVE!

---

From: Mike Bishop <[email-masked]>
Date: Wed, 6 Sep 2017 18:30:30 +0000

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:[email-masked]] On Behalf Of Philipp S. Tiesel
Sent: Tuesday, September 5, 2017 9:30 AM
To: QUIC WG <[email-masked]>
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: 

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

AVE!

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Thu, 7 Sep 2017 14:10:48 +0200

> On 6. Sep 2017, at 20:30, Mike Bishop <[email-masked]> wrote:
> 

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

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.

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

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.

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([email-masked])--->---(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: +49-179-6737439)---<---(jabber: [email-masked])----'