Subject: Side meeting @ IETF 104 for QUIC Datagrams

From: Tommy Pauly <[email-masked]>
Date: Tue, 19 Mar 2019 10:18:09 -0700

I've reserved a room for a side meeting on Wednesday to discuss progressing work on unreliable QUIC Datagrams, and other non-HTTP use cases related to QUIC. If you're working on using QUIC for WebRTC, VPN tunneling, unreliable streaming for voice/video, or games, please come along and join the discussion!

What: QUIC Datagram Side Meeting
When: Wednesday, March 27, 15:00-16:00
Where: Congress Hall 3

Best,
Tommy

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 25 Mar 2019 23:42:38 +0100

Hello QUIC,

I wanted to share our informal agenda for our side meeting. Please feel free to bring any thoughts that relate to these topics in the forms of a slide or two, or just comments you can share with the group!

Best,
Tommy

======

QUIC DATAGRAM protocol details, 20 minutes - Tommy Pauly moderating
- Datagrams + connection flow control
- Datagrams + congestion control
- Datagram flow IDs
- Negotiating support for datagrams

Voice/Video use cases and requirements, 15 minutes - Colin Perkins moderating

Tunneling use cases and requirements, 15 minutes - David Schinazi moderating

Next steps, 10 minutes - Tommy Pauly moderating

> On Mar 19, 2019, at 6:18 PM, Tommy Pauly <tpauly=[email-masked]> wrote:
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 27 Mar 2019 17:35:13 +0100

Thanks to everyone who joined our side meeting! It was a productive time—both for bashing the document and for all of us learning more about the use cases we have.

I've posted the minutes and slides to GitHub:

Minutes (thanks to Tom Jones for taking notes!):
https://github.com/tfpauly/draft-pauly-quic-datagram/blob/master/Side%20Meetings/IETF%20104/minutes.txt

Slides:
https://github.com/tfpauly/draft-pauly-quic-datagram/tree/master/Side%20Meetings/IETF%20104

If you'd like to make any edits to the minutes, please send me a PR.

Best,
Tommy

> On Mar 25, 2019, at 11:42 PM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Hello QUIC,
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 27 Mar 2019 10:30:11 -0700

I’d just like to add a comment I also med on the slack datagram channel:

A use case for reliable datagrams:

A consensus protocol like PAXOS for use with databases or block chain could
would care about timely delivery, but not about strict ordering. The
application endpoint would introduce a total ordering from multiple
sources. Here it is important to not loose an event and that it happens
ASAP, but the relative order is less important.

The game slide also touches upon this because if two plays pick up the same
item, it can be random which event arrives first, but both events are
important. And application endpoint makes the call on total ordering.

I think unreliable datagrams are at least as important as reliable
datagrams, but both are important.

Mikkel

On 27 March 2019 at 17.35.49, Tommy Pauly (tpauly=[email-masked])
wrote:

Thanks to everyone who joined our side meeting! It was a productive
time—both for bashing the document and for all of us learning more about
the use cases we have.

Slides:

Best,
Tommy

> I wanted to share our informal agenda for our side meeting. Please feel
free to bring any thoughts that relate to these topics in the forms of a
slide or two, or just comments you can share with the group!
>> I've reserved a room for a side meeting on Wednesday to discuss
progressing work on unreliable QUIC Datagrams, and other non-HTTP use cases
related to QUIC. If you're working on using QUIC for WebRTC, VPN tunneling,
unreliable streaming for voice/video, or games, please come along and join
the discussion!

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 27 Mar 2019 18:36:43 +0100

Interesting Mikkel. I think also that certain pub/sub models would like
reliable datagram. For example, in the past I used DDS (Data Distribution
Service) where the user defined topics definition expressed the form of
delivery as a requirement, including reliability.

On Wed, 27 Mar 2019, 18:30 Mikkel Fahnøe Jørgensen, <[email-masked]>
wrote:

> A consensus protocol like PAXOS for use with databases or block chain
> could would care about timely delivery, but not about strict ordering. The
> The game slide also touches upon this because if two plays pick up the
> same item, it can be random which event arrives first, but both events are
> On 27 March 2019 at 17.35.49, Tommy Pauly (
> tpauly=[email-masked]) wrote:
>
> If you'd like to make any edits to the minutes, please send me a PR..
>
> Best,
> Tommy
>

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Mar 2019 17:40:59 +0000

I remain super un-enthused about datagrams. I think they’re a major step backwards.
Message-streams, or some other partially reliable thing, sure, but datagrams?

-=R

From: QUIC <[email-masked]> on behalf of Lucas Pardue <[email-masked]>
Date: Wednesday, March 27, 2019 at 10:37 AM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Eric Kinnear <[email-masked]>, David Schinazi <[email-masked]>, Tommy Pauly <tpauly=[email-masked]>, QUIC WG <[email-masked]>, Colin Perkins <[email-masked]>, Mirja Kuehlewind <[email-masked]>
Subject: Re: Side meeting @ IETF 104 for QUIC Datagrams

Interesting Mikkel. I think also that certain pub/sub models would like reliable datagram. For example, in the past I used DDS (Data Distribution Service) where the user defined topics definition expressed the form of delivery as a requirement, including reliability.

On Wed, 27 Mar 2019, 18:30 Mikkel Fahnøe Jørgensen, <[email-masked]<mailto:[email-masked]>> wrote:
I’d just like to add a comment I also med on the slack datagram channel:

A consensus protocol like PAXOS for use with databases or block chain could would care about timely delivery, but not about strict ordering. The application endpoint would introduce a total ordering from multiple sources. Here it is important to not loose an event and that it happens ASAP, but the relative order is less important.

The game slide also touches upon this because if two plays pick up the same item, it can be random which event arrives first, but both events are important. And application endpoint makes the call on total ordering.

I think unreliable datagrams are at least as important as reliable datagrams, but both are important.

Mikkel

On 27 March 2019 at 17.35.49, Tommy Pauly (tpauly=[email-masked]<mailto:tpauly=[email-masked]>) wrote:
Thanks to everyone who joined our side meeting! It was a productive time—both for bashing the document and for all of us learning more about the use cases we have.

Slides:

If you'd like to make any edits to the minutes, please send me a PR...

Best,
Tommy

> On Mar 25, 2019, at 11:42 PM, Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>> wrote:
>
> Hello QUIC,
>
>> On Mar 19, 2019, at 6:18 PM, Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>> wrote:
>>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 27 Mar 2019 17:45:07 +0000

How are these different from using a STREAM for this reliable datagram?  The extra, presumably unneeded, streamID?

From: Lucas Pardue <[email-masked]>
Sent: Wednesday, March 27, 2019 1:37 PM
To: Mikkel Fahnøe Jørgensen <[email-masked]>
Cc: Eric Kinnear <[email-masked]>; David Schinazi <[email-masked]>; Tommy Pauly <tpauly=[email-masked]>; QUIC WG <[email-masked]>; Colin Perkins <[email-masked]>; Mirja Kuehlewind <[email-masked]>
Subject: Re: Side meeting @ IETF 104 for QUIC Datagrams

Mikkel

Minutes (thanks to Tom Jones for taking notes!):
https://github.com/tfpauly/draft-pauly-quic-datagram/blob/master/Side%20Meetings/IETF%20104/minutes.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tfpauly_draft-2Dpauly-2Dquic-2Ddatagram_blob_master_Side-2520Meetings_IETF-2520104_minutes.txt&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=efPm6w5pCdLO7htFNoUW4AWAg9xOEMJ3c68Gjs5PwP4&s=uXnX1ZAVa-XtDKDkMUNCGukKLj77wj_qngY_LROXghA&e=>

Slides:
https://github.com/tfpauly/draft-pauly-quic-datagram/tree/master/Side%20Meetings/IETF%20104<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tfpauly_draft-2Dpauly-2Dquic-2Ddatagram_tree_master_Side-2520Meetings_IETF-2520104&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=efPm6w5pCdLO7htFNoUW4AWAg9xOEMJ3c68Gjs5PwP4&s=AgWNCSvlqrBu4Fzk0Yk3t_2VF4mps-h5m49KaScSdGE&e=>

Best,
Tommy

---

From: Ian Swett <[email-masked]>
Date: Wed, 27 Mar 2019 13:45:35 -0400

I agree that reliable datagrams are useful.  I believe this is a matter of
providing an API that guarantees delivery, so I don't believe any extra
spec work needs to be done to enable reliable datagrams.

---

From: Ian Swett <[email-masked]>
Date: Wed, 27 Mar 2019 13:49:23 -0400

Good question.  You save the Stream ID, which is very nice if you use a
large number of datagrams(ie: RTP).  You also save the need to cancel the
stream in case it is lost.

On Wed, Mar 27, 2019 at 1:48 PM David Schinazi <[email-masked]> wrote:

> What's the difference between a reliable datagram and a STREAM frame with
> offset 0 and the FIN bit set?
>
> David
>
> On Wed, Mar 27, 2019 at 6:45 PM Ian Swett <[email-masked]> wrote:
>
>> I agree that reliable datagrams are useful.  I believe this is a matter
>> of providing an API that guarantees delivery, so I don't believe any extra
>>>> > I wanted to share our informal agenda for our side meeting. Please
>>>> feel free to bring any thoughts that relate to these topics in the forms of
>>>> a slide or two, or just comments you can share with the group!
>>>> >
>>>> > Best,
>>>> > Tommy
>>>> >
>>>> > ======
>>>> >

---

From: "Lubashev, Igor" <[email-masked]>
Date: Wed, 27 Mar 2019 18:03:44 +0000

You do not cancel a stream in case it is lost – these are RELIABLE datagrams. :)

The advantage of a STREAM is that the reliable datagram is no longer restricted to fit into a single packet.  But if it does fit into a single packet, maybe an optimization could be an “anonymous” stream w/o a stream id (and not using up MAX_STREAMS – though some thought is needed to prevent abuse with 0-len or 1-len anonymous streams).

There is a big difference between anything “reliable” (STREAM-ish) and “unreliable” (DATAGRAM-ish).  When protocol guarantees reliability, it must count against MAX_SIZE.  When there is no guarantee, it should not count against MAX_SIZE (endpoint is free to drop any time before delivery).

  *   Igor

From: Ian Swett <ianswett=[email-masked]>
Subject: Re: Side meeting @ IETF 104 for QUIC Datagrams

Good question.  You save the Stream ID, which is very nice if you use a large number of datagrams(ie: RTP).  You also save the need to cancel the stream in case it is lost.

On Wed, Mar 27, 2019 at 1:48 PM David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
What's the difference between a reliable datagram and a STREAM frame with offset 0 and the FIN bit set?

David

On Wed, Mar 27, 2019 at 6:45 PM Ian Swett <[email-masked]<mailto:[email-masked]>> wrote:
I agree that reliable datagrams are useful.  I believe this is a matter of providing an API that guarantees delivery, so I don't believe any extra spec work needs to be done to enable reliable datagrams.

On Wed, Mar 27, 2019 at 1:37 PM Lucas Pardue <[email-masked]<mailto:[email-masked]>> wrote:
Interesting Mikkel. I think also that certain pub/sub models would like reliable datagram. For example, in the past I used DDS (Data Distribution Service) where the user defined topics definition expressed the form of delivery as a requirement, including reliability.

Mikkel

Minutes (thanks to Tom Jones for taking notes!):
https://github.com/tfpauly/draft-pauly-quic-datagram/blob/master/Side%20Meetings/IETF%20104/minutes.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tfpauly_draft-2Dpauly-2Dquic-2Ddatagram_blob_master_Side-2520Meetings_IETF-2520104_minutes.txt&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=8EJwJskcWEH_9AzyeR0KbPiASKL75IuKgRZuUaPn3Xs&s=YdewNCxikzu6_e58i5Z-UHmjsproyTjcxqUekOUR2HA&e=>

Slides:
https://github.com/tfpauly/draft-pauly-quic-datagram/tree/master/Side%20Meetings/IETF%20104<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tfpauly_draft-2Dpauly-2Dquic-2Ddatagram_tree_master_Side-2520Meetings_IETF-2520104&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=8EJwJskcWEH_9AzyeR0KbPiASKL75IuKgRZuUaPn3Xs&s=LWw13Kg4tOnA73INdcI3tkwVxvnDR_igWJebMxcMi-E&e=>

If you'd like to make any edits to the minutes, please send me a PR....

Best,
Tommy

---

From: Roberto Peon <[email-masked]>
Date: Wed, 27 Mar 2019 18:04:03 +0000

Wouldn’t you just save one stream-id per packet, though?

-=R

From: QUIC <[email-masked]> on behalf of Ian Swett <ianswett=[email-masked]>
Date: Wednesday, March 27, 2019 at 11:00 AM
To: David Schinazi <[email-masked]>
Cc: Eric Kinnear <[email-masked]>, Tommy Pauly <tpauly=[email-masked]>, Lucas Pardue <[email-masked]>, Mikkel Fahnøe Jørgensen <[email-masked]>, QUIC WG <[email-masked]>, Colin Perkins <[email-masked]>, Mirja Kuehlewind <[email-masked]>
Subject: Re: Side meeting @ IETF 104 for QUIC Datagrams

David

Mikkel

Slides:

Best,
Tommy