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

[Frank Kastenholz <[e-mail]>]

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

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

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