Subject: Call for Adoption: draft-pauly-quic-datagram

From: Mark Nottingham <[email-masked]>
Date: Thu, 12 Dec 2019 08:36:38 +1100

This is a Call for Adoption of the following document:
  https://tools.ietf.org/html/draft-pauly-quic-datagram-05

The Working Group has discussed this document for some time, most recently in Singapore.

Please state whether you support adoption of the document by the Working Group, and any additional information that you feel may be helpful.

This call will end on 15 January 2020.

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 11 Dec 2019 13:48:56 -0800

I support adoption of this draft.  We already support a version of this in
gQUIC and I am willing to work on making sure it's interoperable with other
implementations.

On Wed, Dec 11, 2019, 13:36 Mark Nottingham <[email-masked]> wrote:

> Please state whether you support adoption of the document by the Working
> Group, and any additional information that you feel may be helpful.
>

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Wed, 11 Dec 2019 14:00:18 -0800

Yes, datagrams are important for custom protocols.

On 11 December 2019 at 22.49.23, Victor Vasiliev (
vasilvv=[email-masked]) wrote:

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 11 Dec 2019 15:03:23 -0800

I support adoption of this document.

This is a natural extension to QUIC and there are multiple implementations
and side-conversations happening already, and as I understand it, there is
some deployment experience.

One note however. Per my read, this is the first extension that extends the
functionality of QUIC beyond the charter's original conception of it for
HTTP. Many things are possible with QUIC, but the things we want to
standardize are the things that are likely to be used. There's no better
argument for useful extensions than a discussion of actual deployment where
it exists. It enables others to use it similarly, and importantly, it
informs why the mechanism is designed so. I would have hoped for more
active discussions around current uses of this extension where it exists,
including deployment experience where it exists. Perhaps the authors can
take this as feedback going forward.

- jana

---

From: "Christopher Wood" <[email-masked]>
Date: Wed, 11 Dec 2019 15:05:49 -0800

I support adoption. 

Best,
Chris

On Wed, Dec 11, 2019, at 3:03 PM, Jana Iyengar wrote:
> This is a natural extension to QUIC and there are multiple 
> implementations and side-conversations happening already, and as I 
> understand it, there is some deployment experience. 
> 
> One note however. Per my read, this is the first extension that extends 
> the functionality of QUIC beyond the charter's original conception of 
> it for HTTP. Many things are possible with QUIC, but the things we want 
> to standardize are the things that are likely to be used. There's no 
> better argument for useful extensions than a discussion of actual 
> deployment where it exists.. It enables others to use it similarly, and 
> importantly, it informs why the mechanism is designed so. I would have 
> hoped for more active discussions around current uses of this extension 
> where it exists, including deployment experience where it exists. 
> Perhaps the authors can take this as feedback going forward.
> 
> - jana
> 
> On Wed, Dec 11, 2019 at 2:00 PM Mikkel Fahnøe Jørgensen 
> <[email-masked]> wrote:
> > On 11 December 2019 at 22.49.23, Victor Vasiliev (vasilvv=[email-masked]) wrote:
> 
> >> I support adoption of this draft. We already support a version of this in gQUIC and I am willing to work on making sure it's interoperable with other implementations.
> >> 
> >> On Wed, Dec 11, 2019, 13:36 Mark Nottingham <mnot@mnot..net <mailto:[email-masked]>> wrote:

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 12 Dec 2019 00:48:05 +0000

A definitely useful and needed feature.  I support adoption.
- Igor

> From: Christopher Wood <[email-masked]>
> 
> I support adoption.
> 
> Best,
> Chris
> 
> > One note however. Per my read, this is the first extension that
> > extends the functionality of QUIC beyond the charter's original
> > conception of it for HTTP. Many things are possible with QUIC, but the
> > things we want to standardize are the things that are likely to be
> > used. There's no better argument for useful extensions than a
> > discussion of actual deployment where it exists.. It enables others to
> > use it similarly, and importantly, it informs why the mechanism is
> > designed so. I would have hoped for more active discussions around
> > current uses of this extension where it exists, including deployment
> experience where it exists.
> > > On 11 December 2019 at 22.49.23, Victor Vasiliev
> (vasilvv=[email-masked]) wrote:
> >
> > >>>  Please state whether you support adoption of the document by the
> Working Group, and any additional information that you feel may be
> helpful.
> > >>>

---

From: Ian Swett <[email-masked]>
Date: Wed, 11 Dec 2019 19:50:08 -0500

This is clearly a critical piece of functionality for QUIC, so we should
definitely adopt this draft.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 12 Dec 2019 12:01:32 +1100

>   https://tools.ietf.org/html/draft-pauly-quic-datagram-05

Yep, this is good and important work.

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 12 Dec 2019 01:07:23 +0000

I support adoption of this draft but will note that in the abstract sense
it is hard to reason about the design of DATAGRAM and hard to interop
without an application of it. Since the round of call for adoption does not
incorporate an application, I have concern about the scope. I wrote up
SiDUCK [1] as means to an end, there are probably better ways to make us
comfortable as a WG.

[1] - https://tools.ietf.org/html/draft-pardue-quic-siduck-0

On Wed, Dec 11, 2019 at 11:03 PM Jana Iyengar <[email-masked]> wrote:

> the functionality of QUIC beyond the charter's original conception of it
> for HTTP. Many things are possible with QUIC, but the things we want to
> it exists.. It enables others to use it similarly, and importantly, it
> On Wed, Dec 11, 2019 at 2:00 PM Mikkel Fahnøe Jørgensen <
> [email-masked]> wrote:
>
>> I support adoption of this draft.  We already support a version of this
>> in gQUIC and I am willing to work on making sure it's interoperable with
>> other implementations.
>>
>> On Wed, Dec 11, 2019, 13:36 Mark Nottingham <mnot@mnot..net
>> <[email-masked]>> wrote:
>>

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 12 Dec 2019 10:23:42 +0900

+1 for adoption.

I agree that there's concern that the DATAGRAM draft is too generic, but
the flip side of that is that it is good for running experiments / private
protocols that only require datagrams. And we can rely on ALPN for what is
being transmitted using the DATAGRAM frames.

To paraphrase, I consider DATAGRAM to be as useful as generic UDP is.

2019年12月12日(木) 10:07 Lucas Pardue <[email-masked]>:

> incorporate an application, I have concern about the scope.. I wrote up
>> it exists... It enables others to use it similarly, and importantly, it
>>> On Wed, Dec 11, 2019, 13:36 Mark Nottingham <mnot@mnot...net
>>> <[email-masked]>> wrote:
>>>
>>>> Working Group, and any additional information that you feel may be helpful.
>>>>

-- 
Kazuho Oku

---

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 12 Dec 2019 07:17:15 +0000

I support the adoption of this work, it will be helpful for other usages of QUIC
Roni

> -----Original Message-----
> From: QUIC [mailto:[email-masked]] On Behalf Of Mark Nottingham
> Sent: Wednesday, December 11, 2019 11:37 PM
> To: IETF QUIC WG
> Cc: Lars Eggert
> Subject: Call for Adoption: draft-pauly-quic-datagram
>

---

From: Jiuhai Zhang <[email-masked]>
Date: Thu, 12 Dec 2019 15:59:28 +0800

I support adoption of this draft.
We are optimizing video streaming applications. It is useful for us.

---

From: Christian Huitema <[email-masked]>
Date: Wed, 11 Dec 2019 22:21:06 -1000

I support adoption of this work, and in fact I have implemented the drsft already

-- Christian Huitema 

> On Dec 11, 2019, at 11:36 AM, Mark Nottingham <[email-masked]> wrote:
>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 12 Dec 2019 11:34:58 +0000

+1 -> I support adoption. 

I actually think in this case it has to be quite generic as we already have multiple use cases that need datagram support and I really hope we can cover all of them with the one extension (and not different ones).

But I agree that in other cases it probably important to also have a concrete use case (and implementation) for an extension before adoption.

Mirja

> Am 12.12.2019 um 02:24 schrieb Kazuho Oku <[email-masked]>:
> 
> 
> +1 for adoption.
> 
> I agree that there's concern that the DATAGRAM draft is too generic, but the flip side of that is that it is good for running experiments / private protocols that only require datagrams. And we can rely on ALPN for what is being transmitted using the DATAGRAM frames.
> 
>> I support adoption of this draft but will note that in the abstract sense it is hard to reason about the design of DATAGRAM and hard to interop without an application of it. Since the round of call for adoption does not incorporate an application, I have concern about the scope.. I wrote up SiDUCK [1] as means to an end, there are probably better ways to make us comfortable as a WG.
>> 
>>> This is a natural extension to QUIC and there are multiple implementations and side-conversations happening already, and as I understand it, there is some deployment experience. 
>>> 
>>> One note however. Per my read, this is the first extension that extends the functionality of QUIC beyond the charter's original conception of it for HTTP. Many things are possible with QUIC, but the things we want to standardize are the things that are likely to be used. There's no better argument for useful extensions than a discussion of actual deployment where it exists... It enables others to use it similarly, and importantly, it informs why the mechanism is designed so. I would have hoped for more active discussions around current uses of this extension where it exists, including deployment experience where it exists. Perhaps the authors can take this as feedback going forward.
>>> 
>>> - jana
>>> 
>>>> On Wed, Dec 11, 2019 at 2:00 PM Mikkel Fahnøe Jørgensen <[email-masked]> wrote:
>>>>> On Wed, Dec 11, 2019, 13:36 Mark Nottingham <mnot@mnot....net> wrote:

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 12 Dec 2019 14:54:34 +0100

+1 to the chorus here; do it.

> On 11 Dec 2019, at 22:36, Mark Nottingham <[email-masked]> wrote:
>

---

From: Roberto Peon <[email-masked]>
Date: Thu, 12 Dec 2019 19:26:25 +0000

Do we have to recharter for this, given that it is a form of partial reliability?
-=R

On 12/12/19, 5:54 AM, "QUIC on behalf of Brian Trammell (IETF)" <[email-masked] on behalf of [email-masked]> wrote:

    >  https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dpauly-2Dquic-2Ddatagram-2D05&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=daGEgfK0zG5ttrBFDe1pWFDD4w683Q5o0eOsHPnuJfs&s=0xOuloaS5bPIxpiob5sf9KDHjdgjU9_7ttyGI7fRlX0&e= 
    > 
    > Mark Nottingham   https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=daGEgfK0zG5ttrBFDe1pWFDD4w683Q5o0eOsHPnuJfs&s=brtfSmEoJHbYF_MKvHBTsMX8n6zC4Z0_iFP_j23Qjio&e= 
    > 
    >

---

From: Christian Huitema <[email-masked]>
Date: Thu, 12 Dec 2019 10:12:59 -1000

> Do we have to recharter for this, given that it is a form of partial reliability?

I don't think so. We could play with words, but I understand "partial
reliability" as creating streams that may have some kinds of
"reliability holes", such as a stream carrying video frames and allowing
some of them to be dropped. Supporting *that* requires significant
changes in the protocol machinery, and I understand why it would be
off-charter. Datagrams are much more constrained.

-- Christian Huitema

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 12 Dec 2019 12:15:49 -0800

There is nothing partial about datagrams, they are completely unreliable.

On 12 December 2019 at 21.13.14, Christian Huitema ([email-masked])
wrote:

-- Christian Huitema

---

From: Mike Coleman <[email-masked]>
Date: Thu, 12 Dec 2019 17:19:28 -0800

I support adoption of this draft by the Working Group.

While very generic, it enables important applications such as streaming media.

-mc

---

From: Rui Paulo <[email-masked]>
Date: Fri, 13 Dec 2019 16:30:57 -0800

I support adoption!

> On Dec 11, 2019, at 13:36, Mark Nottingham <[email-masked]> wrote:
> 

—
Rui Paulo

---

From: Marten Seemann <[email-masked]>
Date: Sat, 14 Dec 2019 08:02:08 +0400

I support adoption. In fact, I’ve implemented the current draft.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 16 Dec 2019 12:42:32 -0500

please adopt pauly-quic-datagram; the ability to have unified congestion
control across streams and datagrams (within the same connection) will be
particularly useful.

---

From: Vidhi Goel <[email-masked]>
Date: Mon, 16 Dec 2019 13:13:42 -0800

+1 for adoption of datagram draft.

> On Dec 16, 2019, at 9:42 AM, Patrick McManus <[email-masked]> wrote:
> 
> please adopt pauly-quic-datagram; the ability to have unified congestion control across streams and datagrams (within the same connection) will be particularly useful.
> 
> On Wed, Dec 11, 2019 at 4:36 PM Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
>   https://tools.ietf.org/html/draft-pauly-quic-datagram-05 <https://tools.ietf.org/html/draft-pauly-quic-datagram-05>
> 
> Mark Nottingham   https://www.mnot.net/ <https://www.mnot.net/>
>

---

From: Mike Bishop <[email-masked]>
Date: Tue, 17 Dec 2019 16:44:21 +0000

I suspect we do -- not because it's partial reliability per se, but because our charter doesn't currently authorize us to work on extensions other than multipath, even though only partial reliability is explicitly forbidden.

I support both adoption of this document and adoption of a new charter which allows us to work on extensions to QUIC v1.

---

From: Florin Baboescu <[email-masked]>
Date: Wed, 18 Dec 2019 09:10:40 -0800

I also support adoption of draft-pauly-quic-datagram .

Thank you.

-Florin

*From:* QUIC [mailto:[email-masked]] *On Behalf Of *Vidhi Goel
*Sent:* Monday, December 16, 2019 1:14 PM
*To:* Patrick McManus <[email-masked]>
*Cc:* Lars Eggert <[email-masked]>; Mark Nottingham <[email-masked]>; IETF
QUIC WG <[email-masked]>
*Subject:* Re: Call for Adoption: draft-pauly-quic-datagram

The Working Group has discussed this document for some time, most recently
in Singapore.

Regards,

---

From: Thomas Fossati <[email-masked]>
Date: Mon, 30 Dec 2019 10:11:24 +0000

Cheers,

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.