IETF Logo Mail Archive

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

Rui Paulo <rpaulo@apple.com> Wed, 08 September 2021 16:53 UTC

Return-Path: <rpaulo@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 888DD3A2EEB; Wed, 8 Sep 2021 09:53:13 -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=ham 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 IgWsJilUduJp; Wed, 8 Sep 2021 09:53:08 -0700 (PDT)
Received: from rn-mailsvcp-ppex-lapp15.apple.com (rn-mailsvcp-ppex-lapp15.rno.apple.com [17.179.253.34]) (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 36CDD3A2EE5; Wed, 8 Sep 2021 09:53:08 -0700 (PDT)
Received: from pps.filterd (rn-mailsvcp-ppex-lapp15.rno.apple.com [127.0.0.1]) by rn-mailsvcp-ppex-lapp15.rno.apple.com (8.16.1.2/8.16.1.2) with SMTP id 188GmG0s006940; Wed, 8 Sep 2021 09:53:07 -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=BhPMf2NnNJ4o83dC1GY2KThRNJEsZrUeEFMuVIgJ/l8=; b=CsjgFFBCMWUyr7rXnAstM3KKWNnKaZJALZF8O88Yej1x08KVPuaZkZKjYfoppxWGDbnS /MOC2j/fM5UbZKDGkW6FUQsa7TyT8PAUUkfv9zIeGSTZ2WPRXi3Joq/q9j1kHSL+2HdE H8lhOleRVpgqFAIufoFCKIaVGULgrPgci4v1yIxSObVTFal47KcrUOl2nIMe7XT18AQQ 98zOdwkZRs2f5UJoN/2U+ACwLaDDHaFl2kn9Cr3pKXqV/yRpQmIKl6fI0umhlRjZFPdX IKqdPL0Gv3N8UYu7gxe7NNkogUM4aqlKBILKnaCPviNMhMDPNnCF+0STCj7LD9Q+zUR9 cQ==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by rn-mailsvcp-ppex-lapp15.rno.apple.com with ESMTP id 3axcnu1d6y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 08 Sep 2021 09:53:07 -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-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.9.20210415 64bit (built Apr 15 2021)) with ESMTPS id <0QZ400A7TK8JBG70@rn-mailsvcp-mta-lapp04.rno.apple.com>; Wed, 08 Sep 2021 09:53:07 -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 <0QZ400200JTC3600@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 08 Sep 2021 09:53:07 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 3e36c8ee2ded4997433f91a522c3e30a
X-Va-E-CD: 53f9ef6544522ac38c30b3b813fd1841
X-Va-R-CD: 1b4c959bc96b69f38728d94fa6f0e285
X-Va-CD: 0
X-Va-ID: 09e1b1be-1f4d-45f9-b909-0b20448f1fef
X-V-A:
X-V-T-CD: 3e36c8ee2ded4997433f91a522c3e30a
X-V-E-CD: 53f9ef6544522ac38c30b3b813fd1841
X-V-R-CD: 1b4c959bc96b69f38728d94fa6f0e285
X-V-CD: 0
X-V-ID: c2c524e9-19f1-47fc-9139-14946edb9f64
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-08_06:2021-09-07, 2021-09-08 signatures=0
Received: from smtpclient.apple (unknown [17.11.156.149]) 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 <0QZ400XGQK8IWD00@rn-mailsvcp-mmp-lapp04.rno.apple.com>; Wed, 08 Sep 2021 09:53:06 -0700 (PDT)
From: Rui Paulo <rpaulo@apple.com>
Message-id: <02379C91-764C-4A5B-893D-FC490905778D@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_6A4A34B4-E75E-40AA-A3FA-82F53D00EE37"
MIME-version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.2\))
Subject: Re: Consensus call for adding support for non-ack eliciting DATAGRAMs
Date: Wed, 08 Sep 2021 09:53:06 -0700
In-reply-to: <CAJ_4DfQQLWSJO_0AEeYorDBBb4CmEccJNQDbHD9U7X3s0wUuPQ@mail.gmail.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, quic@ietf.org, Martin Thomson <mt@lowentropy.net>
To: Ryan Hamilton <rch=40google.com@dmarc.ietf.org>
References: <CALGR9obraBc=LHs6625SnXPZZ=jy170a4dYACwLxaARkoY0_YA@mail.gmail.com> <16d22e18-a169-418c-89af-0355a241fbf0@www.fastmail.com> <CAKcm_gOioEecFhEyptBaYmjvLkAteG33nJVpNspHEXM=iTd7Eg@mail.gmail.com> <CAJ_4DfQQLWSJO_0AEeYorDBBb4CmEccJNQDbHD9U7X3s0wUuPQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3693.20.0.1.2)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.790 definitions=2021-09-08_06:2021-09-07, 2021-09-08 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/KdoKi_QAD2MMkEEzqBswTx46y7w>
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 16:53:14 -0000

I also agree we shouldn’t change it.

> On Sep 8, 2021, at 09:40, Ryan Hamilton <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>
>

v2.23.0 | Report a Bug | By Email