Re: Unreliable Stream (was: Re: HTTP requests on one stream #692)

[Mirja Kühlewind <[e-mail]>]

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 <[e-mail]>:
> 
> 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 ([e-mail]) wrote:
> 
>> An open question is question is how to present a stream with “holes” to the application.