Re: draft-tiesel-quic-unreliable-streams-01 - comments

[Christian Huitema <[e-mail]>]

On 11/1/2017 6:03 AM, Roni Even wrote:

> Hi,
>
>  
>
> I think support for unreliable streams is important for unidirectional
> and bi-directional streams and even if it is V2 we still need to take
> support for it into account. One use case is RTP over QUIC.
>

I used to think that too, but I wonder whether something like RTP in
QUIC is best achieved by overloading the concept of streams, or by
defining a completely independent system, maybe using RTP and RTCP frame
types instead of regular streams types.

My main reason to say that is that regular stream data is more or less
treated as a byte stream, and RTP is not. The transport is free to send
stream data segments containing some of the stream's bytes, depending on
flow control, multiplexing conditions, packet size, etc. In contrast,
RTP data is sent as series of well delimited packets, each packet
corresponding to some well defined time slice of the media. Whatever
framing we use in QUIC will have to respect these packet boundaries.

Another reason has to do with forward error correction, which is
commonly applied to large video frames sent over several packets. Many
systems use packet-erasure-correction schemes, which rely on correctly
identifying which packet was lost -- or, in QUIC, which of the
video-carrying frames was lost. That would require some frame numbering
scheme. Some of that is probably best left to the application, but at a
minimum QUIC shall be able to respect frame boundaries. And that's
probably easier if the data is sent in some specialized RTP framing,
rather than as regular STREAM DATA frames.

>  
>
> Small comments:
>
>  
>
> In section 4.2 “ The loss of such a frame does not introduce state at
> the perceived receiver”. If new streams are opened with higher stream
> ID,  it implicitly opens this one frame stream that was lost in the
> receiver. I think it still requires the sender to send a reliable FIN
> to close this stream.
>
>  
>
> In the security section “ An active, on path attacker can drop
> selected frames“ . What does it mean selected frames, the whole
> payload is encrypted.
>

We probably need to assume that real time stream will be set up by the
application, using something like SIP or RTSP in conjunction with SDP.
The end of the real time stream could also be signaled by the
application in pretty much the same way.

Frankly, I don't think that we are ready to define RTP over QUIC right
now, as the priority is to finish the base spec. But what we can do is
experiment with extension mechanism. For example, define an experiment
in which QUIC that can carry RTP, and verify that we can use the various
extension mechanisms to field that. We might learn something about these
extension tools: version numbers, transport parameter negotiation, maybe
experimental frame types.

-- Christian Huitema