Subject: Consensus call for adding support for non-ack eliciting DATAGRAMs

From: Lucas Pardue <[email-masked]>
Date: Wed, 8 Sep 2021 12:31:50 +0100

Hello QUIC WG,

This is a consensus call for datagram issue #42 [1] - Allow a Sender to
Control Datagram ACKs. The proposed resolution is to close this issue with
no action.

If you object to the proposal, please do so on the issue or in response to
this message.

The call will run for one week, closing at end of day on September 15 2021,
anywhere on earth.

[1] https://github.com/quicwg/datagram/issues/42

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 08 Sep 2021 22:21:51 +1000

No change is good.  It's nothing we can't fix trivially later if we find that was the wrong outcome.  And getting this right, even if it were needed, would be tricky. It's also not all that useful when you consider that ack frequency exists as a way to manage the cost and overhead of acknowledgments.

On Wed, Sep 8, 2021, at 21:31, Lucas Pardue wrote:
> Control Datagram ACKs. The proposed resolution is to close this issue 
> with no action.
> 
> If you object to the proposal, please do so on the issue or in response 
> to this message. 
> 
> The call will run for one week, closing at end of day on September 15 
> 2021, anywhere on earth.
>

---

From: Ian Swett <[email-masked]>
Date: Wed, 8 Sep 2021 11:53:08 -0400

Agreed, if we're going to do this, I'd like to address it in the ack
frequency draft and not in datagram.  I also think there are valid use
cases to not ACK stream data as well, such as Media over QUIC, where frames
may not fit into a single QUIC packet.

On Wed, Sep 8, 2021 at 8:22 AM Martin Thomson <[email-masked]> wrote:

> No change is good.  It's nothing we can't fix trivially later if we find
> that was the wrong outcome.  And getting this right, even if it were
> needed, would be tricky. It's also not all that useful when you consider
> that ack frequency exists as a way to manage the cost and overhead of
> acknowledgments.
>

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 8 Sep 2021 09:40:23 -0700

Well said, Ian and Martin. I agree that no change is the right outcome here.

---

From: Rui Paulo <[email-masked]>
Date: Wed, 08 Sep 2021 09:53:06 -0700

I also agree we shouldn’t change it.

> On Sep 8, 2021, at 09:40, Ryan Hamilton <rch=[email-masked]> wrote:
> 
> On Wed, Sep 8, 2021 at 8:53 AM Ian Swett <ianswett=[email-masked] <mailto:[email-masked]>> wrote:
> Agreed, if we're going to do this, I'd like to address it in the ack frequency draft and not in datagram.  I also think there are valid use cases to not ACK stream data as well, such as Media over QUIC, where frames may not fit into a single QUIC packet.
> 
> On Wed, Sep 8, 2021 at 8:22 AM Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> > [1] https://github.com/quicwg/datagram/issues/42 <https://github.com/quicwg/datagram/issues/42>
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 8 Sep 2021 18:26:21 +0100

A small question to the editors, if this targets the general Internet - you probably have an answer, there are various possibilities -  how will this transport spec detect congestion, and what method will be used for congestion control?

Gorry

> On 8 Sep 2021, at 17:41, Ryan Hamilton <rch=[email-masked]> wrote:
> 
> 
>> On Wed, Sep 8, 2021 at 8:53 AM Ian Swett <ianswett=[email-masked]> wrote:

---

From: Vidhi Goel <[email-masked]>
Date: Wed, 08 Sep 2021 14:03:47 -0700

> A small question to the editors, if this targets the general Internet - you probably have an answer, there are various possibilities -  how will this transport spec detect congestion, and what meth…

Datagrams are ack-eliciting and would use the same (ACK-clocking) congestion control as other reliable frames in QUIC. In other words, the congestion control is a shared state for datagrams + other frames.

Thanks,
Vidhi

> On Sep 8, 2021, at 10:26 AM, Gorry Fairhurst <[email-masked]> wrote:
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 08 Sep 2021 14:58:17 -0700

> On Sep 8, 2021, at 2:03 PM, Vidhi Goel <vidhi_goel=[email-masked]> wrote:
> 

Is this question for the editors of the ack-frequency draft (as opposed to the datagram draft)? Vidhi’s right for datagram as it stands—it acts like any other frame. The impact of changing ack frequency seems to be more interesting here, and is one of the reasons I believe this particular work belongs in that document, and not the datagram extension.

Thanks,
Tommy
>> On Sep 8, 2021, at 10:26 AM, Gorry Fairhurst <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> On 8 Sep 2021, at 17:41, Ryan Hamilton <rch=[email-masked] <mailto:rch=[email-masked]>> wrote:
>>> 
>>>

---

From: Vidhi Goel <[email-masked]>
Date: Wed, 08 Sep 2021 15:09:22 -0700

> Is this question for the editors of the ack-frequency draft (as opposed to the datagram draft)? Vidhi’s right for datagram as it stands—it acts like any other frame. The impact of changing ack freq…

Thanks Tommy for the clarifying question. I interpreted “this transport spec” as datagram spec. ;-)
And I agree that reducing ACKs (discussion on this GitHub issue) can/should be discussed in ACK_FREQUENCY draft - whether we decide to use the same ACK_FREQUENCY for reliable vs unreliable data or not.

-
Vidhi

> On Sep 8, 2021, at 2:58 PM, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> 
> 
>> On Sep 8, 2021, at 2:03 PM, Vidhi Goel <vidhi_goel=[email-masked] <mailto:vidhi_goel=[email-masked]>> wrote:
>>

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 16 Sep 2021 21:03:51 +0100

Hearing no pushback, consensus is declared on the proposed resolution to
close this issue with no action.

Kind regards
Matt & Lucas
QUIC WG Chair

On Wed, Sep 8, 2021 at 11:10 PM Vidhi Goel <vidhi_goel=
[email-masked]> wrote:

> A small question to the editors, if this targets the general Internet -
> you probably have an answer, there are various possibilities -  how will
> this transport spec detect congestion, and what method will be used for
> congestion control?
>
>
> Is this question for the editors of the ack-frequency draft (as opposed to
> the datagram draft)? Vidhi’s right for datagram as it stands—it acts like
> any other frame. The impact of changing ack frequency seems to be more
> interesting here, and is one of the reasons I believe this particular work
> belongs in that document, and not the datagram extension.
>
>
> And I agree that reducing ACKs (discussion on this GitHub issue)
> can/should be discussed in ACK_FREQUENCY draft - whether we decide to use
> the same ACK_FREQUENCY for reliable vs unreliable data or not.
>
> -
> Vidhi
>
> On Sep 8, 2021, at 2:03 PM, Vidhi Goel <
> vidhi_goel=[email-masked]> wrote:
>
> A small question to the editors, if this targets the general Internet -
> you probably have an answer, there are various possibilities -  how will
> this transport spec detect congestion, and what method will be used for
> congestion control?
>
>
> Is this question for the editors of the ack-frequency draft (as opposed to
> the datagram draft)? Vidhi’s right for datagram as it stands—it acts like
> any other frame. The impact of changing ack frequency seems to be more
> interesting here, and is one of the reasons I believe this particular work
> belongs in that document, and not the datagram extension.
>
> Thanks,
> Tommy
>
>
> Datagrams are ack-eliciting and would use the same (ACK-clocking)
> congestion control as other reliable frames in QUIC. In other words, the
> congestion control is a shared state for datagrams + other frames.
>
> Thanks,
> Vidhi
>
> A small question to the editors, if this targets the general Internet -
> you probably have an answer, there are various possibilities -  how will
> this transport spec detect congestion, and what method will be used for
> congestion control?
>
> Gorry
>