From nobody Wed Sep 8 10:27:18 2021 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C639F3A2FF3 for ; Wed, 8 Sep 2021 10:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX3uNxbY8dhI for ; Wed, 8 Sep 2021 10:27:12 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id E9F163A2FF0 for ; Wed, 8 Sep 2021 10:27:11 -0700 (PDT) Received: from [192.168.1.70] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 04D871B00193; Wed, 8 Sep 2021 18:26:22 +0100 (BST) Content-Type: multipart/alternative; boundary=Apple-Mail-594BA66B-49E7-48FC-A97B-81ED5A56BF92 Content-Transfer-Encoding: 7bit From: Gorry Fairhurst Mime-Version: 1.0 (1.0) Subject: Re: Consensus call for adding support for non-ack eliciting DATAGRAMs Date: Wed, 8 Sep 2021 18:26:21 +0100 Message-Id: <6D0139E9-C9C7-4CF8-ACF8-A44ACBA8DBBA@erg.abdn.ac.uk> References: Cc: Ian Swett , Ryan Hamilton , Martin Thomson In-Reply-To: To: quic@ietf.org X-Mailer: iPad Mail (17E262) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2021 17:27:17 -0000 --Apple-Mail-594BA66B-49E7-48FC-A97B-81ED5A56BF92 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable A small question to the editors, if this targets the general Internet - you p= robably have an answer, there are various possibilities - how will this tra= nsport spec detect congestion, and what method will be used for congestion c= ontrol? Gorry > On 8 Sep 2021, at 17:41, Ryan Hamilton = wrote: >=20 > =EF=BB=BF > Well said, Ian and Martin. I agree that no change is the right outcome her= e. >=20 >> On Wed, Sep 8, 2021 at 8:53 AM Ian Swett wrote: >> Agreed, if we're going to do this, I'd like to address it in the ack freq= uency draft and not in datagram. I also think there are valid use cases to n= ot ACK stream data as well, such as Media over QUIC, where frames may not fi= t into a single QUIC packet. >>=20 >>> On Wed, Sep 8, 2021 at 8:22 AM Martin Thomson 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 f= requency exists as a way to manage the cost and overhead of acknowledgments.= >>>=20 >>> On Wed, Sep 8, 2021, at 21:31, Lucas Pardue wrote: >>> > Hello QUIC WG, >>> >=20 >>> > This is a consensus call for datagram issue #42 [1] - Allow a Sender t= o=20 >>> > Control Datagram ACKs. The proposed resolution is to close this issue=20= >>> > with no action. >>> >=20 >>> > If you object to the proposal, please do so on the issue or in respons= e=20 >>> > to this message.=20 >>> >=20 >>> > The call will run for one week, closing at end of day on September 15=20= >>> > 2021, anywhere on earth. >>> >=20 >>> > [1] https://github.com/quicwg/datagram/issues/42 >>>=20 --Apple-Mail-594BA66B-49E7-48FC-A97B-81ED5A56BF92 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
A small question to the ed= itors, if this targets the general Internet - you probably have an answer, t= here are various possibilities -  how will this transport spec detect c= ongestion, and what method will be used for congestion control?

Gorry

On 8 Sep 2021, at 17:41, Ryan Hamilton <rch=3D40google= .com@dmarc.ietf.org> wrote:

=EF=BB=BF
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=3D40google.com@dmarc.ietf.org> wrote:
Agreed, if we're going to do th= is, I'd like to address it in the ack frequency draft and not in datagram.&n= bsp; I also think there are valid use cases to not ACK stream data as well, s= uch as Media over QUIC, where frames may not fit into a single QUIC packet.<= /div>
On= Wed, Sep 8, 2021 at 8:22 AM Martin Thomson <mt@lowentropy.net> wrote:
No change is good.  It's noth= ing 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 <= br> > 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 <= br> > 2021, anywhere on earth.
>
> [1] https://github.com/quicwg/datagram/issues/42<= br>
= --Apple-Mail-594BA66B-49E7-48FC-A97B-81ED5A56BF92--