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

Vidhi Goel <vidhi_goel@apple.com> Wed, 08 September 2021 22:09 UTC

Return-Path: <vidhi_goel@apple.com>
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 C33173A0A6F for <quic@ietfa.amsl.com>; Wed, 8 Sep 2021 15:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 F3yGaYgwfw1T for <quic@ietfa.amsl.com>; Wed, 8 Sep 2021 15:09:39 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp44.apple.com (rn-mailsvcp-ppex-lapp44.rno.apple.com [17.179.253.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393843A0A68 for <quic@ietf.org>; Wed, 8 Sep 2021 15:09:39 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp44.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp44.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 188M8Fiq003595; Wed, 8 Sep 2021 15:09:23 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=TNpoQItLh/Mg+n8junPZkw7U3hM6PvWGy0qEEbRbqXk=; b=kC9uHb68AfsFzxPU6pGCJeLWGK+lwld5mh7GylAUGw6kM3dzzU6M7p2D2EaSHZW4RzIe V5mctBOiFk/NgyuWPFmVSKpDcdfR8hpqcwwhVYFdoXxjHussmsea/z8rwfu0I7fiWo63 H0n/bJt11jIgB5x0mHK7xq2MWEaS4r4b4ih2XkYWcRMvH42s1GE1lTGyShs4n3gW6SYe DrPjlNuKQKeDCMQC/p9DEgZ7Vhvw+wMF4TxrHlSdDgZDd2fcU7fsu0hjCORfsl5jyB68 gLTKfQlWqSy0aJ5uWq2e+sXc4WayqcR7egfsURbk6SreQUGv+y0YH2ck0prGV8bwnPeG TA==
Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by rn-mailsvcp-ppex-lapp44.rno.apple.com with ESMTP id 3axcntnt2x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 08 Sep 2021 15:09:23 -0700
Received: from rn-mailsvcp-mmp-lapp04.rno.apple.com (rn-mailsvcp-mmp-lapp04.rno.apple.com [17.179.253.17]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QZ4001A2YVN2OJ0@rn-mailsvcp-mta-lapp03.rno.apple.com>; Wed, 08 Sep 2021 15:09:23 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-mmp-lapp04.rno.apple.com by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) id <0QZ400A00YMNC700@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 08 Sep 2021 15:09:23 -0700 (PDT)
X-Va-A:
X-Va-T-CD: dfc86da510652575580ff00346bca277
X-Va-E-CD: e16dc71c8fbc5cfc487b9fb93e5fbdf9
X-Va-R-CD: 5cc56b32c80ece1d22bba99f3d490b1e
X-Va-CD: 0
X-Va-ID: 5c903d7d-2a54-4bd3-a94f-9524c3f0ca15
X-V-A:
X-V-T-CD: dfc86da510652575580ff00346bca277
X-V-E-CD: e16dc71c8fbc5cfc487b9fb93e5fbdf9
X-V-R-CD: 5cc56b32c80ece1d22bba99f3d490b1e
X-V-CD: 0
X-V-ID: eb1418b2-8f31-4b49-9ab7-357b8d3f1de3
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-08_09:2021-09-07, 2021-09-08 signatures=0
Received: from smtpclient.apple (unknown [17.11.188.106]) by rn-mailsvcp-mmp-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPSA id <0QZ4009A5YVMT900@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 08 Sep 2021 15:09:23 -0700 (PDT)
From: Vidhi Goel <vidhi_goel@apple.com>
Message-id: <E860B1DA-2A6E-477D-AA2E-A643B34566CD@apple.com>
Content-type: multipart/signed; boundary="Apple-Mail=_5B930A69-1B3B-41A5-886A-39551E84471D"; protocol="application/pkcs7-signature"; micalg=sha-256
MIME-version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.11\))
Subject: Re: Consensus call for adding support for non-ack eliciting DATAGRAMs
Date: Wed, 08 Sep 2021 15:09:22 -0700
In-reply-to: <DBE7D01D-EB89-4CF1-9DC9-587F0A7CC699@apple.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, IETF QUIC WG <quic@ietf.org>, Ryan Hamilton <rch@google.com>, Martin Thomson <mt@lowentropy.net>, Ian Swett <ianswett@google.com>
To: Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
References: <CAJ_4DfQQLWSJO_0AEeYorDBBb4CmEccJNQDbHD9U7X3s0wUuPQ@mail.gmail.com> <6D0139E9-C9C7-4CF8-ACF8-A44ACBA8DBBA@erg.abdn.ac.uk> <983FFB12-E483-44D2-AB59-120A0531014A@apple.com> <DBE7D01D-EB89-4CF1-9DC9-587F0A7CC699@apple.com>
X-Mailer: Apple Mail (2.3654.100.0.2.11)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-08_09:2021-09-07, 2021-09-08 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/J8tNTDoG6FtXx-8mNGSOJ8O-YnQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Sep 2021 22:09:44 -0000

>>> 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=40apple.com@dmarc.ietf.org> wrote:
> 
> 
> 
>> On Sep 8, 2021, at 2:03 PM, Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org <mailto:vidhi_goel=40apple.com@dmarc.ietf.org>> 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 <gorry@erg.abdn.ac.uk <mailto:gorry@erg.abdn.ac.uk>> 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=40google.com@dmarc.ietf.org <mailto:rch=40google.com@dmarc.ietf.org>> 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=40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>> 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 <mt@lowentropy.net <mailto:mt@lowentropy.net>> 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>
>>>> 
>> 
>