Re: draft-lubashev-quic-partial-reliability

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

I did come up with a proposal with segmented stream data for partial
reliability.
It’s not too coherent as it evolved, but here it is:

https://github.com/quicwg/base-drafts/issues/433

Applications could also do their internal framing and forward the min for
each internal frame and let transport decide if retransmission is
worthwhile.

If the application needs to make business decisions it might be out of the
loop for too long. QUIC might be scheduled a lot more often than
applications talking to QUIC.

Kind Regards,
Mikkel Fahnøe Jørgensen


On 19 December 2017 at 20.31.17, Christian Huitema ([e-mail])
wrote:

On 12/18/2017 7:39 PM, Lubashev, Igor wrote:

> The high-level idea is that the sender keeps track of messages within
> a stream and can “expire” old messages whenever it wants.  The
> “expiration” is a signal to the transport to not retransmit expired
> data (and a signal to the other endpoint that this data will not be
> retransmitted).  All details are in the draft.

I read your draft, and it does indeed provide "partial reliability." My
problem is that for RTP style applications, you don't want just partial
reliability. You also want application frame delimitation, such as
delivering isolated VOIP frames, doing  loss compensation, or
implementing application level FEC for large video frames. The streams
in QUIC don't provide that. They implement a "byte stream" abstraction,
not a "packet stream". So I really wonder whether FTP style applications
are better served by adding partial reliability to the current concept
of streams, or whether we should just add a different service, maybe
creating "RTP_STREAM" frames.

-- Christian Huitema