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 protected]> 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 <[email protected]> > wrote: > > > > On Sep 8, 2021, at 2:03 PM, Vidhi Goel < > [email protected]> 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 <[email protected]> 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 <[email protected]> > 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= > [email protected]> 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 protected]> 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 >>> >>> > > >
