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

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