Re: draft-lubashev-quic-partial-reliability

[Ian Swett <[e-mail]>]

For message style payloads commonly carried over UDP, like RTP, I added an
issue to create a MESSAGE frame for QUIC.  Does that fit what you have in
mind?
https://github.com/quicwg/base-drafts/issues/814

On Tue, Dec 19, 2017 at 3:31 PM, Ingemar Johansson S <
[e-mail]> wrote:

> > -----Original Message-----
> > From: Christian Huitema [mailto:[e-mail]]
> > Sent: den 19 december 2017 20:31
> > To: Lubashev, Igor <[e-mail]>; QUIC WG <[e-mail]>
> > Subject: Re: draft-lubashev-quic-partial-reliability
> >
> > 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.
>
> Thanks Christian, I now understand what I did not understand with the
> partial-reliability draft. The reason is that I look at this from an RTP
> point of view. To make QUIC {partial,un}reliable streams useful for real
> time media then I agree that one need something like RTP_STREAM. With that
> said I am not sure that RTP is the best common denominator around, perhaps
> MEDIA_STREAM is a better alternative?, where one use the abstraction media
> frames (video frames, audio frames...) instead ?, that would allow support
> for other not RTP type packetization like for instance MPEG-TS .
>
> >
> > -- Christian Huitema
> >
> >
>
>