partially unreliable quic streams

[Mikkel Fahnøe Jørgensen <[e-mail]>]

Hi Anja und Jörg


Regarding
https://tools.ietf.org/html/draft-tiesel-quic-unreliable-streams-00

I’m not sure where this draft fits into to the QUIC design process process
since my understanding is that unreliable streams is for a later charter in
the design process.

A quick read through the draft makes me wonder if you considering some
partial reliable ideas that have emerged out of the currently unfinished
concept of unidirectional streams and if you can incorporate these ideas
into your draft?

Essentially the idea is each stream is sequence of messages which are
reliable but suffer head of line blocking when each message is separated by
an application specific message header. In the simplest form the stream is
just one message.

For unreliable streams, the concept is inverted: each stream is a single
message which starts an application specific unreliable stream identifier
embedded in the stream/message. The ordering of messages is given by the
QUIC level stream id which always increases (effectively a message id in
this context) but there is no head of line blocking nor any delivery
ordering because each message is independent.

Thus the space consumed is the same for the two concepts but the
interpretation is different.

An implementation can further cooperate by not retransmitting sufficiently
old or otherwise outdate messages. Currently QUIC has no way to explicitly
configure this and dropping retransmission of frames might affect
congestion control. Therefore in its current form QUIC cannot properly
unreliable streams, only prevent head of line blocking.

It is worth noting that with once message per stream there can be many
messages per packet which can significantly increase the messages per
second rate and therefore also requires efficiently management of stream
state - such as discarding send state immediately after sending FIN (except
retransmission machinery).


Kind Regards,
Mikkel Fahnøe Jørgensen