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

[Lucas Pardue <[e-mail]>]

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=
[e-mail]> 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 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=[e-mail]>
> wrote:
>
>
>
> On Sep 8, 2021, at 2:03 PM, Vidhi Goel <
> vidhi_goel=[e-mail]> 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
>
> On Sep 8, 2021, at 10:26 AM, Gorry Fairhurst <[e-mail]> 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?
>
> Gorry
>
> On 8 Sep 2021, at 17:41, Ryan Hamilton <rch=[e-mail]>
> wrote:
>
> 
> Well said, Ian and Martin. I agree that no change is the right outcome
> here.
>
> On Wed, Sep 8, 2021 at 8:53 AM Ian Swett <ianswett=
> [e-mail]> 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 <[e-mail]> 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.
>>>
>>> On Wed, Sep 8, 2021, at 21:31, Lucas Pardue wrote:
>>> > 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
>>>
>>>
>
>
>