RE: Updated DATAGRAM -03 draft

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

Hi Björn + others

I am personally more in favor of having the network congestion control on the transport layer, similar to how it is being done in RFC8298 (SCReAM). With that said, it is to me an open question which network congestion control that best serves the combination of real time media and other media such as file transfers, that is a possible outcome with QUIC as generally used transport protocol. It can for instance be interesting to see how well BBRv2 fares with realtime media.

 

As regards to APIs:

SCReAM has a built it push-back signal from the network congestion control to the media rate control(ers), this pushes down the media bitrate slightly when a network queue starts to build up. My experience is that SCReAM works without this push-back signal with the drawback that queues can more easily build up on the sender side. The bottom line is thus that a push-back signal from network congestion control to the media rate controllers can be useful.

 

/Ingemar

 

From: Bjorn Mellem <[e-mail]> 
Sent: den 17 juli 2019 21:52
To: Ingemar Johansson S <[e-mail]>
Cc: Tommy Pauly <[e-mail]>; Roberto Peon <[e-mail]>; Robin MARX <[e-mail]>; Mikkel Fahnøe Jørgensen <[e-mail]>; QUIC WG <[e-mail]>; Christian Huitema <[e-mail]>
Subject: Re: Updated DATAGRAM -03 draft

 

In Google's work on WebRTC-over-QUIC, we've generally used the GCC (Google Congestion Control) scheme described in this draft: https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02.

 

We're moving toward an approach that essentially tunnels media over a QUIC datagram flow.  In doing this, I've made a couple of observations about congestion-controlled datagrams:

 

 1. In cases where we control the QUIC implementation, it's simple enough to make it use GCC.  However, we'd like to be able to use it through interfaces like WebTransport (https://github.com/WICG/web-transport <https://protect2.fireeye.com/url?k=527e4dd7-0eaa474b-527e0d4c-8631fc8bdea5-802ec935843b019d&q=1&u=https%3A%2F%2Fgithub.com%2FWICG%2Fweb-transport> , https://tools.ietf.org/html/draft-vvv-webtransport-overview-00), where we do not control the QUIC transport directly.  (This could probably be solved with appropriate APIs for configuring WebTransport's congestion control.)

 

 2. GCC is work-in-progress.  There are fairly regular changes aimed at improving its performance in various edge cases.  In order to deploy changes we either need an extremely broad API or control of the transport.

 

While this might seem like an API problem, among the proposed solutions is "don't congestion control datagrams (let the application do that) and implement a circuit-breaker instead".  That would obviously require that the transport does not congestion control datagrams, either.

 

There are other possibilities that might work for real-time media, such as exposing timing information and allowing an application to set a *lower* rate if it wants to preserve latency.  But what about tunneling other protocols over QUIC datagrams?  Do we expect those to work within QUIC's congestion control?  Disable the upper-layer protocol's congestion control?  Or hook the two together in some cooperative manner?

 

Bjorn

 

On Tue, Jul 16, 2019 at 11:31 PM Ingemar Johansson S <[e-mail] <mailto:[e-mail]> > wrote:

+1. 

In the general non-QoS scenario it is to prefer that the streams share one connection and thus one congestion control. 

 

My experiments with SCReAM (RFC8298) shows that this can be made to work quite well on RTP streams, an implementation of this is found at  <https://protect2.fireeye.com/url?k=8566ae5e-d9b2a4c2-8566eec5-8631fc8bdea5-0ad521e62f5c8311&q=1&u=https%3A%2F%2Fgithub.com%2FEricssonResearch%2Fscream> https://github.com/EricssonResearch/scream. It is however not straightforward to get perfect prioritization such as 70% of the bandwidth goes to stream A and 30% to stream B when it comes to real-time low latency media. The key reason is that the low latency goal means that there are often no packets to schedule as extra delay due to queueing in the sender should be avoided, variations on source rates from video encoder makes it more challenging. 

In comparison, “Infinite” bitrate sources such as file transfers are much easier to work with as they provide data ready to schedule for transmission on the sender side until the file transfer is done.

In the SCReAM case I have so far managed to get something like ball-park weighted fairness, fig 7 in  <https://www.hindawi.com/journals/wcmc/2018/3142496/> https://www.hindawi.com/journals/wcmc/2018/3142496/ shows how it works in a real test scenario over a LTE access. 

 

I mentioned non-QoS scenarios. In scenarios where an underlying network supports QoS (such as 4G/5G), then it can be beneficial to use two or more connections, which are then scheduled over different bearers.

 

/Ingemar

 

From: Tommy Pauly <[e-mail] <mailto:[e-mail]> > 
Sent: den 16 juli 2019 14:47
To: Roberto Peon <[e-mail] <mailto:[e-mail]> >
Cc: Mikkel Fahnøe Jørgensen <[e-mail] <mailto:[e-mail]> >; QUIC WG <[e-mail] <mailto:[e-mail]> >; Christian Huitema <[e-mail] <mailto:[e-mail]> >; Robin MARX <[e-mail] <mailto:[e-mail]> >
Subject: Re: Updated DATAGRAM -03 draft

 

I definitely agree that sharing one connection, where the frames are all subject to a shared congestion control, will provide the most control and the best results.

 

What it does bring up, however, is the need for text regarding prioritization in the document, similar to the “Stream Prioritization” section in the main transport document. The application should be able to indicate to the quic implementation the relative priority of a flow of datagrams with regards to other streams and other flows, thus indicating how to schedule frames when congestion control opens up. This is also a way in which having a flow identifier known at the transport can be useful (although this identifier could be used strictly locally to get a similar effect). 

 

Thanks,

Tommy

 

On Jul 15, 2019, at 6:23 PM, Roberto Peon <[e-mail] <mailto:[e-mail]> > wrote:

 

Using two connections would be unfortunate-- this will almost always guarantee worse results than even the most simple proportional prioritization or fair-share scheduling because you can cause self contention and dilute your measurement accuracy.

-=R

  _____  

From: QUIC <[e-mail] <mailto:[e-mail]> > on behalf of Mikkel Fahnøe Jørgensen <[e-mail] <mailto:[e-mail]> >
Sent: Monday, July 15, 2019 12:12:09 PM
To: QUIC WG; Christian Huitema; Robin MARX
Cc: Tommy Pauly
Subject: Re: Updated DATAGRAM -03 draft 

 

You could also carry two connections, one for video and one for game status updates.

 

I’m wondering if there is, or should be, a way to accomplish this on a single connection.

I asked something similar a long time ago and I don’t think there is any amition for managing bandwidth in this for on a single connection, at least for QUIC v1.

 

 

On 15 July 2019 at 21.04.58, Christian Huitema ([e-mail] <mailto:[e-mail]> ) wrote:


On 7/15/2019 3:03 AM, Robin MARX wrote: 
> Hello Tommy, 
> 
> Good to see the updated draft. 
> I do wonder about the decision to enforce congestion control for 
> DATAGRAM frames and the effect this will have on the gaming use case.  
> As also discussed in Prague, real-time gaming often requires a set 
> update rate frequency (e.g., 30-60 messages per second) for 
> responsiveness.  
> I wonder if congestion controlling the frames (e.g., delaying/dropping 
> them) will produce some weird edge cases that really mess with this 
> setup.  
> It's a bit difficult to assess because the messages are usually 
> relatively small (though they could be mixed with larger messages, 
> e.g., RPCs) and you could make the argument that, if there is actual 
> congestion, the packets will be dropped in the network either way.  
> You could also say that custom game-focused implementations will just 
> ignore the text and do their own logic as needed. 
> 
> So I'm not sure the text needs changes, I just wanted to mention that 
> it might not be optimal for the real-time gaming use case and that it 
> might be capable footgun with some weird edge cases if people do stick 
> to the text. 


Not really. If the network is congested and the video game still 
persists sending frequent messages the most likely outcome will be 
queuing and losses, and thus bad game play. The proper behavior in a 
congested network is to switch to a low bandwidth mode of some kind -- 
maybe a lower frame rate, or a lower resolution. This is pretty much the 
same issue as voice or video over IP: if the network is congested, it 
makes sense to use a higher compression rate. With congestion control, 
the application can detect the upset of congestion and adopt these 
strategies. That's generally much better than to just passively accept 
queues and losses. 

-- Christian Huitema