>>> 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] >> <mailto:[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] >>> <mailto:[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] >>>> <mailto:[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 >>>> <[email protected] >>>> <mailto:[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] >>>> <mailto:[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 >>>> > <https://github.com/quicwg/datagram/issues/42> >>>> >> >
smime.p7s
Description: S/MIME cryptographic signature
