RTP over QUIC experiments

[Ingemar Johansson S <[e-mail]>]

Hi Jörg, Mathis + others

 

It was nice to learn about your activity to try and use SCReAM as example
algorithm to integrate with QUIC. Pages 14-25 in
https://datatracker.ietf.org/meeting/112/materials/slides-112-avtcore-ietf-1
12-avtcore-03

Did you use the new gsteamer plugin from
https://github.com/EricssonResearch/scream/tree/master/gstscream  ?

 

Observations/Comments: 

+ SCReAM + Reno : Strange that the throughput dropped like that but perhaps
an unlucky outcome of two cascaded congestion controls. 

 

+ Split of network congestion control and media rate control : QUIC already
today has the congestion control on the connection level, it is then up to
the individual streams to deliver media, subject to the individual stream
priorities. SCReAM is quite similar in that respect, one difference is
perhaps the implementation of the media rate control.  
I think that with QUIC one should do a full split and do the network
congestion control on the QUIC connection level. The congestion control
would then be some low latency version, perhaps BBRv2? or something similar,
I am not sure that the network congestion control in SCReAM is the idea
choice here as it is quite a lot tailored for RTP media. 
The media rate control is done on the stream level and is then subject to
stream priority. This should give a more clean split of functionality. 
My SCReAM experience is that one need to leak some of the congestion signals
from the connection level congestion control up to the stream rate control,
to make the whole thing responsive enough. In the SCReAM code one can see
that the exotic variable queueDelayTrend as well as ECN marks and loss
events are used for this purpose. I believe that something like that is
needed for an RTP (or whatever low latency) media over QUIC. I believe that
it is necessary to leak congestion information from the connection level up
to the stream level, especially to be able to exploit L4S fully, even though
it is a bit of a protocol layer violation.

 

+ Stream prioritization : … is a problematic area, especially if one stream
is low latency video and another stream is a large chunk of data for e.g. a
large web page. With a simple round robin scheduler, the stream with the
large chunk of data will easily win because it is quite likely to always
have data to transmit. So some WRR is needed. I have even had problems with
the algorithm in SCReAM that prioritizes between two cameras/video coders,
this because the two cameras see different views and thus provide differing
information content/compression need.

 

+ Page 18 : Inferring the receive timestamp. What is suspect is that you
will essentially halve the estimated queue delay (I assume here that the
reverse path is uncongested). One alternative could be to compute 
receive-ts = send-ts + latest_rtt + min_rtt
where min_rtt is the min RTT over a given time interval

 

 

Regards

/Ingemar