Subject: Updated DATAGRAM -03 draft

From: Tommy Pauly <[email-masked]>
Date: Mon, 08 Jul 2019 08:20:09 -0700

Hello all,

We’ve updated the QUIC DATAGRAM draft to incorporate some of the feedback we received at the side meeting in Prague. Notably, it clarifies:

- Guidance around datagram acknowledgements
- Datagrams do not participate in any flow control
- Datagrams do participate in congestion control

The remaining area of open discussion is around the newly re-named optional “flow identifiers”. The primary argument for removing these is that applications can add identifiers onto datagrams themselves, and the transport should not transmit a field that it does not do anything with. We did add some text clarifying that these identifiers are essentially like UDP ports for demultiplexing, and pointed out some *minimal* things the transport can do to help batch transmission of datagrams in the same flow and promote fate-sharing within a flow. There’s been some discussion on Slack of other approaches that would make these flow IDs more first-class citizens—adding reliable signaling for opening and closing flows, as many applications would also generally need some similar sort of control channel—but these seem a bit heavy-weight. Either way, this is an area where discussion is welcome and I expect the document to change.

Best,
Tommy

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: New Version Notification for draft-pauly-quic-datagram-03.txt
> Date: July 6, 2019 at 6:30:01 PM PDT
> To: Eric Kinnear <[email-masked]>, David Schinazi <[email-masked]>, Tommy Pauly <[email-masked]>
> 
> 
> A new version of I-D, draft-pauly-quic-datagram-03.txt
> has been successfully submitted by Tommy Pauly and posted to the
> IETF repository.
> 
> Name:		draft-pauly-quic-datagram
> Revision:	03
> Title:		An Unreliable Datagram Extension to QUIC
> Document date:	2019-07-06
> Group:		Individual Submission
> Pages:		8
> URL:            https://www.ietf.org/internet-drafts/draft-pauly-quic-datagram-03.txt
> Status:         https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/
> Htmlized:       https://tools.ietf.org/html/draft-pauly-quic-datagram-03
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pauly-quic-datagram
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pauly-quic-datagram-03
> 
> Abstract:
>   This document defines an extension to the QUIC transport protocol to
>   add support for sending and receiving unreliable datagrams over a
>   QUIC connection.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Ian Swett <[email-masked]>
Date: Tue, 9 Jul 2019 21:22:23 -0400

Thanks Tommy.  As I've expressed before, I'm not a big fan of the ID
field(now flow identifiers) unless they have clear transport level
functionality.

Adding signaling for opening and closing these flows seems like a stronger
reason to add these IDs to the transport layer.  Have you considered
splitting this draft into two or the frame type into two and making the
version with a flow identifier more full-featured?

On Mon, Jul 8, 2019 at 11:20 AM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hello all,
>
> We’ve updated the QUIC DATAGRAM draft to incorporate some of the feedback
> we received at the side meeting in Prague. Notably, it clarifies:
>
> The remaining area of open discussion is around the newly re-named
> optional “flow identifiers”. The primary argument for removing these is
> that applications can add identifiers onto datagrams themselves, and the
> transport should not transmit a field that it does not do anything with. We
> did add some text clarifying that these identifiers are essentially like
> UDP ports for demultiplexing, and pointed out some *minimal* things the
> transport can do to help batch transmission of datagrams in the same flow
> and promote fate-sharing within a flow. There’s been some discussion on
> Slack of other approaches that would make these flow IDs more first-class
> citizens—adding reliable signaling for opening and closing flows, as many
> applications would also generally need some similar sort of control
> channel—but these seem a bit heavy-weight. Either way, this is an area
> where discussion is welcome and I expect the document to change.
>
> Best,
> Tommy
>
> Begin forwarded message:
>
> *From: [email-masked]
> *Subject: **New Version Notification for draft-pauly-quic-datagram-03.txt*
> *Date: *July 6, 2019 at 6:30:01 PM PDT
> *To: *Eric Kinnear <[email-masked]>, David Schinazi <
> [email-masked]>, Tommy Pauly <[email-masked]>
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-pauly-quic-datagram-03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-pauly-quic-datagram
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-pauly-quic-datagram-03
>
> Abstract:

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 10 Jul 2019 09:12:18 -0700

> On Jul 9, 2019, at 6:22 PM, Ian Swett <ianswett=[email-masked]> wrote:
> 
> Thanks Tommy.  As I've expressed before, I'm not a big fan of the ID field(now flow identifiers) unless they have clear transport level functionality.

Understood! 
> 
> Adding signaling for opening and closing these flows seems like a stronger reason to add these IDs to the transport layer.  Have you considered splitting this draft into two or the frame type into two and making the version with a flow identifier more full-featured?
> 

That's certainly an option. As it stands, the frame type with a Flow ID is already a different type value. I think if people decide that the datagrams are mainly useful with the extra signaling being part of the transport layer, then I'd prefer to just do that in this document, but if not, then it can be separate.

Overall, I see a few different options for handling flow IDs:

- Remove them from the DATAGRAM transport altogether
- Support flow IDs in the DATAGRAM draft with more explicit tie-ins to the transport, like flow lifetime management
- Have a separate draft specifying how the next layer above the QUIC transport should manage multiplexing of datagram flows, by putting identifiers at the start of datagram payloads, and using reliable control stream(s) to negotiate lifetimes of flows

Thanks,
Tommy

> On Mon, Jul 8, 2019 at 11:20 AM Tommy Pauly <tpauly=[email-masked] <mailto:[email-masked]>> wrote:
> Hello all,
> 
>> From: [email-masked] <mailto:[email-masked]>
>> To: Eric Kinnear <[email-masked] <mailto:[email-masked]>>, David Schinazi <[email-masked] <mailto:[email-masked]>>, Tommy Pauly <[email-masked] <mailto:[email-masked]>>
>> 
>> 
>> URL:            https://www.ietf.org/internet-drafts/draft-pauly-quic-datagram-03.txt <https://www.ietf.org/internet-drafts/draft-pauly-quic-datagram-03.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/ <https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/>
>> Htmlized:       https://tools.ietf.org/html/draft-pauly-quic-datagram-03 <https://tools.ietf.org/html/draft-pauly-quic-datagram-03>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-pauly-quic-datagram <https://datatracker.ietf.org/doc/html/draft-pauly-quic-datagram>
>> Diff:           https://www.ietf..org/rfcdiff?url2=draft-pauly-quic-datagram-03 <https://www.ietf.org/rfcdiff?url2=draft-pauly-quic-datagram-03>
>> 
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
>

---

From: Nick Banks <[email-masked]>
Date: Wed, 10 Jul 2019 16:30:15 +0000

My preference would also be to support flow control for the IDs. Though, I still think that the IDs by themselves have merit. As Tommy has said, you can think of a datagram ID on a given connection as pretty much the same thing as a UDP port for an IP address. If both sides know before hand what port to use, everything is fine.

- Nick

From: QUIC <[email-masked]> On Behalf Of Tommy Pauly
Sent: Wednesday, July 10, 2019 9:12 AM
To: Ian Swett <ianswett=[email-masked]>
Cc: QUIC WG <[email-masked]>
Subject: Re: Updated DATAGRAM -03 draft

On Jul 9, 2019, at 6:22 PM, Ian Swett <ianswett=[email-masked]<mailto:ianswett=[email-masked]>> wrote:

Understood!

Thanks,
Tommy

On Mon, Jul 8, 2019 at 11:20 AM Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>> wrote:
Hello all,

Best,
Tommy

Begin forwarded message:

From: [email-masked]<mailto:[email-masked]>
Subject: New Version Notification for draft-pauly-quic-datagram-03.txt
Date: July 6, 2019 at 6:30:01 PM PDT
To: Eric Kinnear <[email-masked]<mailto:[email-masked]>>, David Schinazi <[email-masked]<mailto:[email-masked]>>, Tommy Pauly <[email-masked]<mailto:[email-masked]>>

Name: draft-pauly-quic-datagram
Revision: 03
Title: An Unreliable Datagram Extension to QUIC
Document date: 2019-07-06
Group: Individual Submission
Pages: 8
URL:            https://www.ietf.org/internet-drafts/draft-pauly-quic-datagram-03.txt<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-pauly-quic-datagram-03.txt&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793956874&sdata=Vi6tqg74ZTl5s%2BG5aU1v4R4dHbSbweBuz2vSBYn6sIU%3D&reserved=0>
Status:         https://datatracker.ietf.org/doc/draft-pauly-quic-datagram/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-pauly-quic-datagram%2F&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793961863&sdata=hDx9XfQUXu5YgfkzStkR47J5dYYjSeoEJH4hhj9RFsk%3D&reserved=0>
Htmlized:       https://tools.ietf.org/html/draft-pauly-quic-datagram-03<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-pauly-quic-datagram-03&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793966856&sdata=fPeG461Z1OEpy2z5vgyptHWZTghaDfLLqtlByAfQN%2FA%3D&reserved=0>
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pauly-quic-datagram<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-pauly-quic-datagram&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793971846&sdata=%2F5BpNnlBfTjXJKcIXPw0AtSI4ZnR5ANBy0dI8uKkhFw%3D&reserved=0>
Diff:           https://www.ietf..org/rfcdiff?url2=draft-pauly-quic-datagram-03<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-pauly-quic-datagram-03&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793976837&sdata=gEChkKf0lX7YYGBeMKiZPOKsN8LNerq3HURRpmzNfDc%3D&reserved=0>

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793981824&sdata=voffvGDVz3PluwcN5wuAZqtflBE9zgk%2FD6wt2rfNU0M%3D&reserved=0>.

The IETF Secretariat

---

From: Robin MARX <[email-masked]>
Date: Mon, 15 Jul 2019 12:03:05 +0200

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.

With best regards,
Robin

On Wed, 10 Jul 2019 at 18:30, Nick Banks <nibanks=
[email-masked]> wrote:

> My preference would also be to support flow control for the IDs. Though, I
> still think that the IDs by themselves have merit. As Tommy has said, you
> can think of a datagram ID on a given connection as pretty much the same
> thing as a UDP port for an IP address. If both sides know before hand what
> port to use, everything is fine.
>
>
>
> - Nick
>
>
>
> *From:* QUIC <[email-masked]> *On Behalf Of * Tommy Pauly
> *Sent:* Wednesday, July 10, 2019 9:12 AM
> *To:* Ian Swett <ianswett=[email-masked]>
> *Cc:* QUIC WG <[email-masked]>
> *Subject:* Re: Updated DATAGRAM -03 draft
>
>
>
>
>
>
>
> On Jul 9, 2019, at 6:22 PM, Ian Swett <
> ianswett=[email-masked]> wrote:
>
>
>
> That's certainly an option. As it stands, the frame type with a Flow ID is
> already a different type value. I think if people decide that the datagrams
> are mainly useful with the extra signaling being part of the transport
> layer, then I'd prefer to just do that in this document, but if not, then
> it can be separate.
>
>
>
> - Have a separate draft specifying how the next layer above the QUIC
> transport should manage multiplexing of datagram flows, by putting
> identifiers at the start of datagram payloads, and using reliable control
> stream(s) to negotiate lifetimes of flows
>
>
>
> Thanks,
>
> Tommy
>
>
>
> *Subject: New Version Notification for draft-pauly-quic-datagram-03.txt*
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Finternet-drafts%2Fdraft-pauly-quic-datagram-03.txt&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793956874&sdata=Vi6tqg74ZTl5s%2BG5aU1v4R4dHbSbweBuz2vSBYn6sIU%3D&reserved=0>
> Status:
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-pauly-quic-datagram%2F&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793961863&sdata=hDx9XfQUXu5YgfkzStkR47J5dYYjSeoEJH4hhj9RFsk%3D&reserved=0>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-pauly-quic-datagram-03&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793966856&sdata=fPeG461Z1OEpy2z5vgyptHWZTghaDfLLqtlByAfQN%2FA%3D&reserved=0>
> Htmlized:
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-pauly-quic-datagram&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793971846&sdata=%2F5BpNnlBfTjXJKcIXPw0AtSI4ZnR5ANBy0dI8uKkhFw%3D&reserved=0>
> Diff:
> https://www.ietf..org/rfcdiff?url2=draft-pauly-quic-datagram-03
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-pauly-quic-datagram-03&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793976837&sdata=gEChkKf0lX7YYGBeMKiZPOKsN8LNerq3HURRpmzNfDc%3D&reserved=0>
>
> Abstract:
> until the htmlized version and diff are available at tools.ietf.org
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2F&data=02%7C01%7Cnibanks%40microsoft.com%7Cc6d3ea0c350e4fe3c06408d705517895%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636983719793981824&sdata=voffvGDVz3PluwcN5wuAZqtflBE9zgk%2FD6wt2rfNU0M%3D&reserved=0>
> .
>
> The IETF Secretariat
>
>
>
>
>

-- 

Robin Marx
PhD researcher - web performance
Expertise centre for Digital Media

T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94

www.uhasselt.be
Universiteit Hasselt - Campus Diepenbeek
Agoralaan Gebouw D - B-3590 Diepenbeek
Kantoor EDM-2.05

---

From: Christian Huitema <[email-masked]>
Date: Mon, 15 Jul 2019 12:03:57 -0700

On 7/15/2019 3:03 AM, Robin MARX wrote:
> 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. 
> 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. 
> 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

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Mon, 15 Jul 2019 21:12:09 +0200

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 ([email-masked]) wrote:

-- Christian Huitema

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 16 Jul 2019 06:56:40 +1000

On Tue, Jul 16, 2019, at 05:12, Mikkel Fahnøe Jørgensen wrote:
> You could also carry two connections, one for video and one for game 
> status updates.
> 

The effective use of priority is difficult, but it should allow for mixed use of the one connection.  The two-connection case is just this, except that it relies on the congestion controller of each connection to manage contention.  If you have decent prioritization, two connections is strictly worse than one.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 15 Jul 2019 22:23:31 +0000

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 <[email-masked]> on behalf of Mikkel Fahnøe Jørgensen <[email-masked]>
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 ([email-masked]<mailto:[email-masked]>) wrote:

-- Christian Huitema

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 16 Jul 2019 08:47:17 -0400

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 <[email-masked]> wrote:
> 
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 17 Jul 2019 06:31:03 +0000

+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://github.com/EricssonResearch/scream> 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 <[email-masked]> 
Sent: den 16 juli 2019 14:47
To: Roberto Peon <[email-masked]>
Cc: Mikkel Fahnøe Jørgensen <[email-masked]>; QUIC WG <[email-masked]>; Christian Huitema <[email-masked]>; Robin MARX <[email-masked]>
Subject: Re: Updated DATAGRAM -03 draft

Thanks,

Tommy

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

-=R

  _____  

From: QUIC <[email-masked] <mailto:[email-masked]> > on behalf of Mikkel Fahnøe Jørgensen <[email-masked] <mailto:[email-masked]> >
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 

 

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

-- Christian Huitema

---

From: Bjorn Mellem <[email-masked]>
Date: Wed, 17 Jul 2019 12:51:32 -0700

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://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 <
[email-masked]> 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://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/ 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 <[email-masked]>
> *Sent:* den 16 juli 2019 14:47
> *To:* Roberto Peon <[email-masked]>
> *Cc:* Mikkel Fahnøe Jørgensen <[email-masked]>; QUIC WG <[email-masked]>;
> Christian Huitema <[email-masked]>; Robin MARX <
> [email-masked]>
> 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
>
>
>
> 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 <[email-masked]> on behalf of Mikkel Fahnøe Jørgensen
> <[email-masked]>
> *Sent:* Monday, July 15, 2019 12:12:09 PM
> *To:* QUIC WG; Christian Huitema; Robin MARX
> *Cc:* Tommy Pauly

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 24 Jul 2019 18:09:46 -0400

We had a productive lunch meeting for Datagram today after the QUIC session (with Lars, ekr, Martin Thomson, Lucas Pardue, David Schinazi, Eric Kinnear, Nick Banks, and Tommy Pauly in attendance).

The group agreed that the relevant open issue was the use of flow IDs in the transport. The decision we came to collectively was to:

- Remove Flow Identifiers from the QUIC DATAGRAM (transport) draft. Specify that each application is responsible for defining its datagram flow management scheme.
- David will be creating a new document to define how HTTP/3 marks and uses DATAGRAM frames.

I have opened a Pull Request to remove flow IDs from the draft here: https://github.com/tfpauly/draft-pauly-quic-datagram/pull/11

While this may get merged, we don't plan to submit a new version of the draft until the new HTTP/3 draft has been written.

Best,
Tommy

> On Jul 8, 2019, at 11:20 AM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Hello all,
> 
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-pauly-quic-datagram-03 <https://www.ietf.org/rfcdiff?url2=draft-pauly-quic-datagram-03>
>> 
>> Abstract: