RE: draft-lubashev-quic-partial-reliability

["Lubashev, Igor" <[e-mail]>]

The two proposals are similar in a way that both effectively contain a “zero-fill” frame, though MIN_STREAM_DATA proposal is explicit about notifying the receiver about a gap in data and does not just fill with 0x00.

Since QUIC is likely to be a library linked into an application, they are scheduled together.  But in any case, I find it important to allow applications full control over when to expire data, although some QUIC implementations could provide higher-level abstractions for message expiration.


From: Mikkel Fahnøe Jørgensen [mailto:[e-mail]]
Sent: Tuesday, December 19, 2017 2:40 PM
To: Lubashev, Igor <[e-mail]>; Christian Huitema <[e-mail]>; QUIC WG <[e-mail]>
Subject: Re: draft-lubashev-quic-partial-reliability

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_issues_433&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=4OKe8eZRrhTX1wql3X2hD9bN3t056-dLmp5rte7hsrM&s=hJuopoxDzIyFbhIYR3bZdHCSotkqVTsGCSjUcpwOfRg&e=>

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]<mailto:[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