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

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Jan 2020 16:03:52 -0800

I support adoption

On Mon, Dec 30, 2019 at 2:11 AM Thomas Fossati <[email-masked]>
wrote:

> On 11/12/2019, 21:36, Mark Nottingham <[email-masked]> wrote:
> > 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.
>
> I support adoption of this document.
>
> 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.
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 4 Jan 2020 11:22:54 -0500

I support adoption.

Since Google  GSUITE I believe has recently switched to using IETF standard
protocol QUIC versus the original proprietary developed by google GQUIC ; I
believe for firewalls, load balancer and other network appliances to get on
board with support WG adoption of QUIC is critical for any google customers
using GSUITE.

Kind Regards,

Gyan
Verizon Communications (VZ)
Cell  301 502-1347

On Wed, Jan 1, 2020 at 7:04 PM Eric Rescorla <[email-masked]> wrote:

> I support adoption
>
> On Mon, Dec 30, 2019 at 2:11 AM Thomas Fossati <Thomas.Fossati@arm..com
> <[email-masked]>> wrote:
>
> --

Gyan S. Mishra

IT Network Engineering & Technology

Verizon Communications Inc. (VZ)

13101 Columbia Pike FDC1 3rd Floor

Silver Spring, MD 20904

United States

Phone: 301 502-1347

Email: [email-masked]

www.linkedin.com/in/networking-technologies-consultant

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 4 Jan 2020 12:07:16 -0500

I support adoption.

I am currently looking at a secure monitoring application which provides a
low resolution live feed and a higher resolution complete feed.

The idea being that the operator screens should always show the most up to
date information in real time. The 4K video can lag if there is congestion.

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

> 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: Sean Turner <[email-masked]>
Date: Tue, 7 Jan 2020 21:49:50 -0500

Piling on late to the game: I support adoption.

spt

> On Dec 11, 2019, at 16:36, Mark Nottingham <[email-masked]> wrote:
> 
> 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.
>

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 14 Jan 2020 09:56:46 +0200

I support the adoption of this draft.

One comment regarding Section 5.3 "Congestion Control": it looks like the
data sent over DATAGRAM frames is (by definition) not sensitive to
occasional packet loss, while the congestion control mechanism may be
sensitive to occasional packet loss (depending on what we mean by
"occasional"). It may be a good idea to add some discussion about this to
Section 5.3. Specifically, I believe that when DATAGRAM frames are used, it
may be desirable for an implementation to use a congestion control
mechanism that can tolerate occasional packet loss without significantly
reducing the rate.

Cheers,
Tal.

---

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 15 Jan 2020 08:03:03 +0000

Hi

I too believe that this is a good idea and therefore support it.

I am however not convinced that that transmission of DATAGRAM frames should 
mandate a different congestion control. While the scenario you outline below 
can hold in networks with small buffers, you will likely not achieve the 
desired goal in cellular networks which still can have a large delay threshold 
for packet discards.

/Ingemar

From: Tal Mizrahi <[email-masked]>
Sent: den 14 januari 2020 08:57
To: Mark Nottingham <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>; Lars Eggert <[email-masked]>
Subject: Re: Call for Adoption: draft-pauly-quic-datagram

One comment regarding Section 5.3 "Congestion Control": it looks like the data 
sent over DATAGRAM frames is (by definition) not sensitive to occasional 
packet loss, while the congestion control mechanism may be sensitive to 
occasional packet loss (depending on what we mean by "occasional"). It may be 
a good idea to add some discussion about this to Section 5.3. Specifically, I 
believe that when DATAGRAM frames are used, it may be desirable for an 
implementation to use a congestion control mechanism that can tolerate 
occasional packet loss without significantly reducing the rate.

Cheers,

Tal.

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

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

Regards,