Re: Updated DATAGRAM -03 draft

[Tommy Pauly <[e-mail]>]

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]> 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]> on behalf of Mikkel Fahnøe Jørgensen <[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]) 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 
>> 
>>