Subject: HTTP requests on one stream #692

From: Lucas Pardue <[email-masked]>
Date: Fri, 21 Jul 2017 15:20:16 +0000

Hi,

Apologies if this was discussed already in Prague but I'd like some clarification on the intended lifetime scope of the changes in PR#692<https://github.com/quicwg/base-drafts/pull/692/files>.

  1.  Is the intention that this change unblocks specification / development so that the WG can continue?
  2.  Will these changes be unwound once progress has been made?
     *   The DATA frame has been resurrected (I presume to demark frames in the same stream). Will it be struck with a wooden stake in the future, or continue to hang around?

Thanks
Lucas

---

From: Mike Bishop <[email-masked]>
Date: Sat, 22 Jul 2017 01:04:03 +0000

No, the consensus both in Paris and Prague was a single stream, which means the DATA frame is back to stay.  The HPACK-without-dynamic-table piece is temporary, until we pick a direction for header compression.

Sent from my Windows 10 phone

From: Lucas Pardue<mailto:[email-masked]>
Sent: Friday, July 21, 2017 8:20 AM
To: IETF QUIC WG<mailto:[email-masked]>
Subject: HTTP requests on one stream #692

Hi,

Apologies if this was discussed already in Prague but I’d like some clarification on the intended lifetime scope of the changes in PR#692<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F692%2Ffiles&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C1a66873ec983497bf7de08d4d04c0326%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636362472283415347&sdata=dZMXpiCYo5b7tVuKrbJCsnaPP42mqRVi%2B3x4garWrvI%3D&reserved=0>.

Thanks
Lucas

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Sun, 23 Jul 2017 10:56:49 +0200

Hi,

too bad that I missed that discussion. 

Separating DATA and Request/Response to different streams would be beneficial if we add unreliable streams. I will try to write up something (at least considerations) before the interim. 

> On 22. Jul 2017, at 03:04, Mike Bishop <[email-masked]> wrote:
> 
> From: Lucas Pardue <mailto:[email-masked]>
> To: IETF QUIC WG <mailto:[email-masked]>
> Apologies if this was discussed already in Prague but I’d like some clarification on the intended lifetime scope of the changes in PR#692 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F692%2Ffiles&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C1a66873ec983497bf7de08d4d04c0326%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636362472283415347&sdata=dZMXpiCYo5b7tVuKrbJCsnaPP42mqRVi%2B3x4garWrvI%3D&reserved=0>. 
>  
> Is the intention that this change unblocks specification / development so that the WG can continue?
> Will these changes be unwound once progress has been made?
> The DATA frame has been resurrected (I presume to demark frames in the same stream). Will it be struck with a wooden stake in the future, or continue to hang around?
>  
> Thanks
> Lucas

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])----'

---

From: Ian Swett <[email-masked]>
Date: Sun, 23 Jul 2017 05:58:30 -0400

A few comments on unreliable streams in QUIC, and this may be a longer
discussion and I'd be curious to read the considerations you have in mind.

QUIC as specified today definitely enables unreliability.  For example, I
can send stream data once, and if some portion of it is lost, at that point
I can decide if I want to retransmit it or just cancel the stream.  I
generally consider unreliability to be a matter of sender side policy.

Making this work well may require a more robust interface between the
application and QUIC stream, or may just require some new features, we'll
see.  I can't think of anything about moving from 2 to 1 streams changes
this, especially given the new header compression schemes will allow
cancellation of the headers as well as the payload, unlike before.

On Sun, Jul 23, 2017 at 4:56 AM, Philipp S. Tiesel <[email-masked]>
wrote:

> Separating DATA and Request/Response to different streams would be
> beneficial if we add unreliable streams. I will try to write up something
> (at least considerations) before the interim.
>
>
> No, the consensus both in Paris and Prague was a single stream, which
> means the DATA frame is back to stay.  The HPACK-without-dynamic-table
> piece is temporary, until we pick a direction for header compression.
>
> *From: *Lucas Pardue <[email-masked]>
> *Sent: *Friday, July 21, 2017 8:20 AM
> *To: *IETF QUIC WG <[email-masked]>
> *Subject: *HTTP requests on one stream #692
>
> Hi,
>
> Apologies if this was discussed already in Prague but I’d like some
> clarification on the intended lifetime scope of the changes in PR#692
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F692%2Ffiles&data=02%7C01%7Cmichael.bishop%40microsoft.com%7C1a66873ec983497bf7de08d4d04c0326%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636362472283415347&sdata=dZMXpiCYo5b7tVuKrbJCsnaPP42mqRVi%2B3x4garWrvI%3D&reserved=0>
> .
>
>
>       1. The DATA frame has been resurrected (I presume to demark frames
>       in the same stream). Will it be struck with a wooden stake in the future,
>       or continue to hang around?
>
>
> Thanks
> Lucas
>
>
> AVE!
> :wq!  <----(phone: +49-179-6737439 <+49%20179%206737439>)---<---(jabber:
> [email-masked])----'
>
>

---

From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Sun, 23 Jul 2017 11:57:46 +0000

A few comments linline.

Thomas

From: QUIC [mailto:[email-masked]] On Behalf Of Ian Swett
Sent: 23 July 2017 10:59
To: Philipp S. Tiesel <[email-masked]>
Cc: Lucas Pardue <[email-masked]>; Mike Bishop <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: HTTP requests on one stream #692

A few comments on unreliable streams in QUIC, and this may be a longer discussion and I'd be curious to read the considerations you have in mind.

QUIC as specified today definitely enables unreliability.  For example, I can send stream data once, and if some portion of it is lost, at that point I can decide if I want to retransmit it or just cancel the stream.
[Thomas Swindells] As stream frames contain the offset  client potentially also has the option of just acknowledging reception even it didn’t actually receive them - though obviously this would and cause problems if non-stream frames were also being acknowledged when in fact the client hadn’t acknowledge them. .
I generally consider unreliability to be a matter of sender side policy.
[Thomas Swindells] I don’t think I agree with that. Often it is the client which has the knowledge about whether data is or is not important. Live video streaming is the best example for this, if the client has enough buffer and is playing the output out live then it would prefer to get the data re-transmitted, however data over a certain age isn’t useful and it may prefer to lose some frames and jump back up to live. However if the client is actually recording the output (or has a longer buffer) it may prefer to stall and get all the data.

Making this work well may require a more robust interface between the application and QUIC stream, or may just require some new features, we'll see.  I can't think of anything about moving from 2 to 1 streams changes this, especially given the new header compression schemes will allow cancellation of the headers as well as the payload, unlike before.

On Sun, Jul 23, 2017 at 4:56 AM, Philipp S. Tiesel <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

On 22. Jul 2017, at 03:04, Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Thanks
Lucas

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

---

From: Ian Swett <[email-masked]>
Date: Sun, 23 Jul 2017 09:02:56 -0400

On Sun, Jul 23, 2017 at 7:57 AM, Swindells, Thomas (Nokia - GB/Cambridge,
UK) <[email-masked]> wrote:

> A few comments linline.
>
>
>
> Thomas
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Ian Swett
> *Sent:* 23 July 2017 10:59
> *To:* Philipp S. Tiesel <[email-masked]>
> *Cc:* Lucas Pardue <[email-masked]>; Mike Bishop <
> [email-masked]>; IETF QUIC WG <[email-masked]>
> *Subject:* Re: HTTP requests on one stream #692
>
>
>
> I can decide if I want to retransmit it or just cancel the stream.
>
> *[Thomas Swindells] As stream frames contain the offset  client
> potentially also has the option of just acknowledging reception even it
> didn’t actually receive them - though obviously this would and cause
> problems if non-stream frames were also being acknowledged when in fact the
> client hadn’t acknowledge them. .*
>

This is prohibited currently, and for good reason, since acking packets you
haven't received breaks congestion control and potentially flow control.
Also, you'd be assuming what was in the packets was what you expected, and
if you were wrong, it could go really poorly.  ie: imagine if you acked a
packet containing QPACK compression context, but didn't receive it.  The
connection would then be in a completely invalid state.

> *[Thomas Swindells] I don’t think I agree with that. Often it is the
> client which has the knowledge about whether data is or is not important.
> Live video streaming is the best example for this, if the client has enough
> buffer and is playing the output out live then it would prefer to get the
> data re-transmitted, however data over a certain age isn’t useful and it
> may prefer to lose some frames and jump back up to live. However if the
> client is actually recording the output (or has a longer buffer) it may
> prefer to stall and get all the data.*
>
>
>

This is definitely an interesting use case and one I think should be in
scope for HTTP over QUIC.  However, at the end of the day the server needs
to send what the client wants, so it's better to inform the server what to
send than trick it.  Given we're discussing HTTP, ideally the HTTP/2
priorities + cancellation would provide what you need, but I'll admit at
the moment it's not a natural mapping.

>    1. The DATA frame has been resurrected (I presume to demark frames in
>       the same stream). Will it be struck with a wooden stake in the future, or
>       continue to hang around?
>
>
>
> Thanks
>
> Lucas
>
>
>
> AVE!

---

From: "Swindells, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]>
Date: Sun, 23 Jul 2017 18:29:06 +0000

I agree that blindly acking packets would cause big problems with the current operations. But perhaps if/when we get onto unreliable streams a way to explicitly nack packets but state don’t bother retransmitting the ones for stream x would be a potential mechanism?

Thomas

From: Ian Swett [mailto:[email-masked]]
Sent: 23 July 2017 14:03
To: Swindells, Thomas (Nokia - GB/Cambridge, UK) <[email-masked]>
Cc: Philipp S. Tiesel <[email-masked]>; Lucas Pardue <[email-masked]>; Mike Bishop <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: HTTP requests on one stream #692

On Sun, Jul 23, 2017 at 7:57 AM, Swindells, Thomas (Nokia - GB/Cambridge, UK) <[email-masked]<mailto:[email-masked]>> wrote:
A few comments linline.

Thomas

From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ian Swett
Sent: 23 July 2017 10:59
To: Philipp S. Tiesel <[email-masked]<mailto:[email-masked]>>
Cc: Lucas Pardue <[email-masked]<mailto:[email-masked]>>; Mike Bishop <[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: HTTP requests on one stream #692

This is prohibited currently, and for good reason, since acking packets you haven't received breaks congestion control and potentially flow control.  Also, you'd be assuming what was in the packets was what you expected, and  if you were wrong, it could go really poorly.  ie: imagine if you acked a packet containing QPACK compression context, but didn't receive it.  The connection would then be in a completely invalid state.

This is definitely an interesting use case and one I think should be in scope for HTTP over QUIC.  However, at the end of the day the server needs to send what the client wants, so it's better to inform the server what to send than trick it.  Given we're discussing HTTP, ideally the HTTP/2 priorities + cancellation would provide what you need, but I'll admit at the moment it's not a natural mapping.

Hi,

Thanks
Lucas

AVE!

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Sun, 23 Jul 2017 14:53:05 -0400

If stream identifiers move to 64 bit, unidirectional streams can be used as
unreliable streams by storing an association context at the start of each
stream. Then ack/nack becomes irrelevant because the receiver can just send
a no longer interested frame instead (if it makes sense - since it might be
too late). This has the benefit that packet boundaries are neatly defined
in the length of the stream. I previously tried to define an unreliable
concept within a single stream but it was not nearly as elegant as using
separate streams. However, if stream identifiers are 32-bit or they are not
explicitly uni-directional, this concept no longer works nearly as well.
32-bit only lasts an hour in high volume traffic.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 23 July 2017 at 20.29.19, Swindells, Thomas (Nokia - GB/Cambridge, UK) (
[email-masked]) wrote:

I agree that blindly acking packets would cause big problems with the
current operations. But perhaps if/when we get onto unreliable streams a
way to explicitly nack packets but state don’t bother retransmitting the
ones for stream x would be a potential mechanism?

Thomas

*From:* Ian Swett [mailto:[email-masked]]
*Sent:* 23 July 2017 14:03
*To:* Swindells, Thomas (Nokia - GB/Cambridge, UK) <
[email-masked]>
*Cc:* Philipp S. Tiesel <[email-masked]>; Lucas Pardue <
[email-masked]>; Mike Bishop <[email-masked]>; IETF
QUIC WG <[email-masked]>
*Subject:* Re: HTTP requests on one stream #692

A few comments linline.

Thomas

*[Thomas Swindells] As stream frames contain the offset  client potentially
also has the option of just acknowledging reception even it didn’t actually
receive them - though obviously this would and cause problems if non-stream
frames were also being acknowledged when in fact the client hadn’t
acknowledge them. .*

*[Thomas Swindells] I don’t think I agree with that. Often it is the client
which has the knowledge about whether data is or is not important. Live
video streaming is the best example for this, if the client has enough
buffer and is playing the output out live then it would prefer to get the
data re-transmitted, however data over a certain age isn’t useful and it
may prefer to lose some frames and jump back up to live. However if the
client is actually recording the output (or has a longer buffer) it may
prefer to stall and get all the data.*

Hi,

No, the consensus both in Paris and Prague was a single stream, which means
the DATA frame is back to stay.  The HPACK-without-dynamic-table piece is
temporary, until we pick a direction for header compression.

Hi,

   1. Is the intention that this change unblocks specification /
   development so that the WG can continue?
   2. Will these changes be unwound once progress has been made?

Thanks

Lucas

AVE!

---

From: Ian Swett <[email-masked]>
Date: Sun, 23 Jul 2017 16:21:04 -0400

Good points Mikkel.  When we did the math on using one stream ID per video
or audio frame in WebRTC at the Tokyo interim, I believe it worked out to
enough for 2 weeks of video.  But for other applications, it is very
possible to hit the 32 bit limit in a moderate amount of time.

On Sun, Jul 23, 2017 at 2:53 PM, Mikkel Fahnøe Jørgensen <[email-masked]

> If stream identifiers move to 64 bit, unidirectional streams can be used
> as unreliable streams by storing an association context at the start of
> each stream. Then ack/nack becomes irrelevant because the receiver can just
> send a no longer interested frame instead (if it makes sense - since it
> might be too late). This has the benefit that packet boundaries are neatly
> defined in the length of the stream. I previously tried to define an
> unreliable concept within a single stream but it was not nearly as elegant
> as using separate streams. However, if stream identifiers are 32-bit or
> they are not explicitly uni-directional, this concept no longer works
> nearly as well. 32-bit only lasts an hour in high volume traffic.
>
> Kind Regards,
> Mikkel Fahnøe Jørgensen
>
>
> This is prohibited currently, and for good reason, since acking packets
> you haven't received breaks congestion control and potentially flow
> control.  Also, you'd be assuming what was in the packets was what you
> expected, and  if you were wrong, it could go really poorly.  ie: imagine
> if you acked a packet containing QPACK compression context, but didn't
> receive it.  The connection would then be in a completely invalid state.
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Jul 2017 23:30:31 +0200

And you can't acknowledge stream data either, only packets. If you want to
keep some frames but not others, which seems likely, over-acknowledgement
doesn't work.

---

From: Mike Bishop <[email-masked]>
Date: Mon, 24 Jul 2017 05:18:52 +0000

The NACK has the same problem as over-acking – you can’t ack frames, you ack packets.  While I see the argument for saying that unreliable delivery is a client choice, not a sender one, it seems like something we could reasonable express at the application layer and then have the sender actually perform.

Simplest options I see would be:

  *   No retransmissions ever (local configuration to stack, RST_STREAM after stream completion)
  *   No retransmissions after a certain timeout (RST_STREAM on a timer, if you assume the stream data all becomes available at once)

Slightly more complex would be something like “only retransmit any given segment once” or “give up on retransmissions after a segment is X ms old.”

From: Martin Thomson [mailto:[email-masked]]
Sent: Sunday, July 23, 2017 2:31 PM
To: Swindells, Thomas (Nokia - GB) <[email-masked]>
Cc: Ian Swett <[email-masked]>; Mike Bishop <[email-masked]>; Lucas Pardue <[email-masked]>; IETF QUIC WG <[email-masked]>; Philipp S. Tiesel <[email-masked]>
Subject: RE: HTTP requests on one stream #692

And you can't acknowledge stream data either, only packets. If you want to keep some frames but not others, which seems likely, over-acknowledgement doesn't work.

On 24 Jul. 2017 04:29, "Swindells, Thomas (Nokia - GB/Cambridge, UK)" <[email-masked]<mailto:[email-masked]>> wrote:
I agree that blindly acking packets would cause big problems with the current operations. But perhaps if/when we get onto unreliable streams a way to explicitly nack packets but state don’t bother retransmitting the ones for stream x would be a potential mechanism?

Thomas

From: Ian Swett [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 23 July 2017 14:03
To: Swindells, Thomas (Nokia - GB/Cambridge, UK) <[email-masked]<mailto:[email-masked]>>
Cc: Philipp S. Tiesel <[email-masked]<mailto:[email-masked]>>; Lucas Pardue <[email-masked]<mailto:[email-masked]>>; Mike Bishop <[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: HTTP requests on one stream #692

Thomas

Hi,

Thanks
Lucas

AVE!
   {phils}--->---([email-masked]<mailto:[email-masked]>)--->---(http://phils.in-panik.de<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fphils.in-panik.de&data=02%7C01%7CMichael.Bishop%40microsoft.com%7C783ad89aece24ad1cea608d4d2120cf5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636364422427070263&sdata=uvE8A7sSLIb2bYV%2FPFJdOjFEesuycicHdf%2Bkjqmus%2FM%3D&reserved=0>)----,

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 24 Jul 2017 16:51:11 +0000

Mike,

Thanks for answering my initial questions.

The discussion has gone off on a bit of a tangent but it is very interesting.

Mike Bishop wrote:

Our implementation of HTTP over multicast QUIC<https://tools.ietf.org/html/draft-pardue-quic-http-mcast> does something similar to your first option. The sender (server) is a continual set of Server Pushes and churns out frames, it progresses stream state into completion itself. This seems similar to the description Ian gave in Prague (when talking about gQUIC Server Push) during the unidirectional streams discussion.

To echo Thomas’ view on client decision making; in our set up the QUIC context is entirely unidirectional and there is no channel for a client to express desires of partial reliability or to NACK. In the many-to-one relationship different receivers (clients) may experience different network conditions leading to variance in lost packets. With these constraints we currently delegate the loss recovery to application-layer means (HTTP byte-range requests) outside of the QUIC context (e.g. back to a CDN). A tighter integration is something we are exploring, hence why I find this discussion interesting. I can see some kind of hybrid mode as being useful i.e. server directed policy (perhaps limited to connection, path etc.) with strong client decision making assisted by client-to-server hints for each resource.

Lucas

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

---

From: Mike Bishop <[email-masked]>
Date: Mon, 24 Jul 2017 17:11:24 +0000

Which would seem to lend itself again to the idea that the sender of data decides and carries out what reliability policy it wants.  (Though of course, when you’re dealing with multicast, all loss recovery is out in the weeds.)

From: QUIC [mailto:[email-masked]] On Behalf Of Lucas Pardue
Sent: Monday, July 24, 2017 9:51 AM
To: Mike Bishop <[email-masked]>; Martin Thomson <[email-masked]>; Swindells, Thomas (Nokia - GB) <[email-masked]>
Cc: Philipp S. Tiesel <[email-masked]>; Ian Swett <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: RE: HTTP requests on one stream #692

Mike,

Mike Bishop wrote:

Our implementation of HTTP over multicast QUIC<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-pardue-quic-http-mcast&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Ca15c3f716a12417e94e008d4d2b43766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636365118860607150&sdata=7XWKjohBqgBJtp8bWjEwgt8JXKyPmtxOu79pVUeTibg%3D&reserved=0> does something similar to your first option. The sender (server) is a continual set of Server Pushes and churns out frames, it progresses stream state into completion itself. This seems similar to the description Ian gave in Prague (when talking about gQUIC Server Push) during the unidirectional streams discussion.

Lucas

http://www.bbc.co.uk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.bbc.co.uk&data=02%7C01%7Cmichael.bishop%40microsoft.com%7Ca15c3f716a12417e94e008d4d2b43766%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636365118860607150&sdata=ENaYnGifghIujmshrR7rc47DaI2XGvrXCEtrfSgFqFQ%3D&reserved=0>

---------------------

---

From: "Philipp S. Tiesel" <[email-masked]>
Date: Tue, 25 Jul 2017 14:11:23 +0200

Hi,

as the discussion is still hot, here the basic ideas we wanted to push for unreliable streams.

> On 24. Jul 2017, at 07:18, Mike Bishop <[email-masked] <mailto:[email-masked]>> wrote:
> 
> While I see the argument for saying that unreliable delivery is a client choice, not a sender one, it seems like something we could reasonable express at the application layer and then have the sender actually perform.

For the case of HTTP – Full ACK.
> No retransmissions ever (local configuration to stack, RST_STREAM after stream completion)
> No retransmissions after a certain timeout (RST_STREAM on a timer, if you assume the stream data all becomes available at once)
>  

In case of HTTP, all three options could be requested via an HTTP request header. 
Optional, in case the server does not support unreliable streams, fallback to reliable transmission.

An open question is question is how to present a stream with “holes” to the application.

On the QUIC layer, as it is much easier to implement, unreliable transmission is driven by the sender. Retransmissions can then be done depending on the applications choice.

Depending on other open discussion, the sender tells the receiver about 
unreliable transmission by ether a flag bit in the stream frame or in
the START_STREA frame. The receiver must set a RST_STREM, if it can’t handle 
unreliable streams.

AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---([email-masked] <mailto:[email-masked]>)--->---(http://phils.in-panik.de <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] <mailto:[email-masked]>)----'

---

From: Frank Kastenholz <[email-masked]>
Date: Tue, 25 Jul 2017 14:17:03 -0400

On Tue, Jul 25, 2017 at 8:11 AM, Philipp S. Tiesel <[email-masked]>
wrote:
...

> An open question is question is how to present a stream with “holes” to

Hi

At a previous job I implemented a protocol that had some similarities to
QUIC and
one of the protocol's features was that a stream could be declared to be
unreliable.
We had two not-incompatible views. First is the simple approach --- a part
of the API
included the QUIC sequence number -- the app can then use this to make the
needed
decisions.  The assumption here is that the sequence numbers increase by a
knowable
amount. Alternatively, we felt that such streams tended to consist of
fairly small (fit in one
packet) independent messages that contained their own identification (or
didn't need it).  In
this case, the application could figure out the holes, etc, on its own.  An
example might be
something like a periodic status report from some kind of sensor that
contains a time stamp.
The time stamp tells the app all it needs to know.

Neither of these are protocol issues --- presenting the seq. num. is an API
matter, and assuming
that the app and its protocol can sort it out is, well, an app matter.

On the QUIC layer, as it is much easier to implement, unreliable
> transmission is driven by the sender. Retransmissions can then be done
> depending on the applications choice.
>

In the work I did previously, we found instances where either sender or
receiver might wish
to assert reliability (or unreliability).  Continuing with the sensor I
mentioned above, a
receiver that is a logger may want every sensor reading. A receiver that
just is showing
the current value will not need reliability. So the sender (the node with
the sensor) might
wish to assert one mode, the receiver however wants the other -- and vice
versa.

This ignores the question of what to do when the receiver wants one mode
and the sender the other ... I don't have a quick answer ... we didn't have
funding at the previous gig to go into these levels of protocol
development...  Probably would have done some kind of negotiation,
with the connection failing if the parties can't agree (maybe ala the old
Telnet will/wont/do/dont
technique).

Thanks
Frank Kastenholz

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Tue, 25 Jul 2017 21:11:31 +0200

I believe Franks description suits the view if unreliable streams being
very small unidirectional streams.

As to Phillips question:

An open question is question is how to present a stream with “holes” to the
application.

The size of holes may be tricky unless, but presenting logical streams with
holes is easy:

For reliable (logical) streams you have one transport stream with many
messages and no holes. These messages must be on the stream to ensure
ordering, and you therefore need an application level message frame.

For unreliable (logical) streams you only send one message in each QUIC
transport stream. Instead of a message frame you store a logical stream id.
The transport stream id will always increase so even if unreliable, you
still know about ordering. An internal sequence number could be added if
more details are needed.

Unreliable streams may be short so there can be many in a single UDP
packet. This can drain the stream ID space.

A sending application can easily tell QUIC transport to not retransmit
frames of unreliable streams (or have some timeout etc.).

The receiving QUIC transport might struggle with seeing only the second
half of an unreliable stream. The receiving application has not easy way to
tell transport to stop waiting even if both sending and receiving
applications have negotiated what they want. To solve this problem, QUIC
transport could have a flag on frames that mark them as unreliable -
perhaps two bits for different classes / timeouts etc. The application can
the tell transport how to manage such streams.

By and large, reliable and unreliable streams work exactly the same at the
transport layer.

Note that if streams are not unidirectional there is more overhead in
keeping stream state and terminating streams. With a uni-directional stream
a sender can immediately close all stream state after sending a single
frame message. At a deeper level there  may be frame retransmission, but
this is much more lightweight. Then if frames are marked unreliable they
can also bypass the retransmission queue.

So I would like unidirectional streams with a flag to mark frames as
unreliable, and longer stream identifiers (possibly compressed).

How this works at the HTTP level I have no clue because I am still not up
to speed on this part. But I can easily imagine that a single stream per
HTTP transaction will fall short of some of those can be unreliable.

Kind Regards,
Mikkel Fahnøe Jørgensen

On 25 July 2017 at 20.17.34, Frank Kastenholz ([email-masked])
wrote:

An open question is question is how to present a stream with “holes” to the
application.

---

From: Mirja Kühlewind <[email-masked]>
Date: Wed, 26 Jul 2017 13:05:10 +0200

Hi all,

in the taps working group we are working on a new socket API, our current proposal is called post sockets. This API is message-based and reliability is realized by assigning a deadline to a message. This approach is based on the assumption that a message is only as a whole useful for the application, and only if delivered within a certain time frame (where for full reliability this time frame in infinite). As message is a data segment defined by the application which can be a frame in a video stream or a sensor report and can span one or multiple transport packets. I thinks this matches what Mikkel describes below.

The deadline is set by the sender because only the sender side can ‚measure‘ correctly when the deadline is passed. For me any signal from the client side about what the right value for this deadline is, is probably an application question and should be done in the application layer.

Mirja

> Am 25.07.2017 um 21:11 schrieb Mikkel Fahnøe Jørgensen <[email-masked]>:
> 
> I believe Franks description suits the view if unreliable streams being very small unidirectional streams.
> 
> As to Phillips question:
> The size of holes may be tricky unless, but presenting logical streams with holes is easy:
> 
> For reliable (logical) streams you have one transport stream with many messages and no holes. These messages must be on the stream to ensure ordering, and you therefore need an application level message frame.
> 
> For unreliable (logical) streams you only send one message in each QUIC transport stream. Instead of a message frame you store a logical stream id. The transport stream id will always increase so even if unreliable, you still know about ordering. An internal sequence number could be added if more details are needed.
> 
> Unreliable streams may be short so there can be many in a single UDP packet. This can drain the stream ID space.
> 
> A sending application can easily tell QUIC transport to not retransmit frames of unreliable streams (or have some timeout etc.).
> 
> The receiving QUIC transport might struggle with seeing only the second half of an unreliable stream. The receiving application has not easy way to tell transport to stop waiting even if both sending and receiving applications have negotiated what they want. To solve this problem, QUIC transport could have a flag on frames that mark them as unreliable - perhaps two bits for different classes / timeouts etc. The application can the tell transport how to manage such streams.
> 
> By and large, reliable and unreliable streams work exactly the same at the transport layer.
> 
> 
> 
> Note that if streams are not unidirectional there is more overhead in keeping stream state and terminating streams. With a uni-directional stream a sender can immediately close all stream state after sending a single frame message. At a deeper level there  may be frame retransmission, but this is much more lightweight. Then if frames are marked unreliable they can also bypass the retransmission queue.
> 
> So I would like unidirectional streams with a flag to mark frames as unreliable, and longer stream identifiers (possibly compressed).
> 
> How this works at the HTTP level I have no clue because I am still not up to speed on this part. But I can easily imagine that a single stream per HTTP transaction will fall short of some of those can be unreliable.
> 
> 
> 
> Kind Regards,
> Mikkel Fahnøe Jørgensen
> 
> 
> On 25 July 2017 at 20.17.34, Frank Kastenholz ([email-masked]) wrote:
>