Re: Consensus call for adding support for non-ack eliciting DATAGRAMs
Lucas Pardue <lucaspardue.24.7@gmail.com> Thu, 16 September 2021 20:04 UTC
Return-Path: <lucaspardue.24.7@gmail.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 324BF3A0EEB for <quic@ietfa.amsl.com>; Thu, 16 Sep 2021 13:04:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=gmail.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 qk0Mt7JAu6nR for <quic@ietfa.amsl.com>; Thu, 16 Sep 2021 13:04:08 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDC4E3A0F61 for <quic@ietf.org>; Thu, 16 Sep 2021 13:04:05 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id j13so21135882edv.13 for <quic@ietf.org>; Thu, 16 Sep 2021 13:04:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=npJrkkjQ0/0T2IDNI/ZIYXL5qyoOl5zyQolBWd7vHBg=; b=AcPyl2d5X/2ItXSLxLaxpOn0yctsUT5GIoLUl1192u0qMguBloaQC8sSr/MYsd85az WSB1DwAUlu0OKMaqLuget7q/GmiATst+EmL34uioECe3TeeR0XpdsufjOoowX56Nu/z5 bGkOi77nfKvy44OKXkoz19hSR6vYIHLkzGyOd1l9+VmS97MViA1GBDns67S2Ah4TRnWs dBurCyt8jqckUSH3sX8oHDEVR9Rh4iFVyhl8vRgyRz7gVG4LZz6rCEFIFvpp+vhUT6fm 8SxLuqu6xkQyeJE3HoMacSi7Qa+WnCrFVTUQUhtVnshQhHKLiB3+S2943qDgDnN6YGhX eg7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=npJrkkjQ0/0T2IDNI/ZIYXL5qyoOl5zyQolBWd7vHBg=; b=OU+a9VRTv8U1AFyTzt5iVkzOotpUJISifX8P0EJJ6h5UTPKVnIyc43AwoVHEjAD5+o ICSS/q4AGNgOwhUswnublnuosaOf+Phdoj3Fmf6YlzZP4rQg+GIVU2ny8LBAXf3rnATG WNpBlIyDGwxOgDZYW9oklCYNgST/mTi7gEzhXTdMCEoMzw4vguM2tJLY8FhlNzr/CjM1 9rf9VX7bZ2awzhlrV0VEOunOCqyX1Rflh6A+Kk14Fn0qEYtgM7r5jgaI/xRXVcEJjs/7 Kqfd7pz0D5RL8kn+xEvDbw+kOtgYy827Z4uKrawf1GUzKMKNeh1YXCsp4wv+Bk0LsLcJ d+GQ==
X-Gm-Message-State: AOAM53398VkX2O0GAA5tNcT0ocytOXk1H2P38EzbRHXFozqp+KvNKEI0 2G7egaXnSzij776ajxzJlF9u3aq988oDFCpaMVULcqgv
X-Google-Smtp-Source: ABdhPJzbjewk9SCSGCVpTA3qPWuzj91ZtnBMvgXm+hYUMTroLl6A30WHRpps7O+HUoq1R9ouki3xSoXgMEpxR2vVni4=
X-Received: by 2002:a17:906:7147:: with SMTP id z7mr8136706ejj.94.1631822642945; Thu, 16 Sep 2021 13:04:02 -0700 (PDT)
MIME-Version: 1.0
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> <E860B1DA-2A6E-477D-AA2E-A643B34566CD@apple.com>
In-Reply-To: <E860B1DA-2A6E-477D-AA2E-A643B34566CD@apple.com>
From: Lucas Pardue <lucaspardue.24.7@gmail.com>
Date: Thu, 16 Sep 2021 21:03:51 +0100
Message-ID: <CALGR9oZ-SrwfWYY_9xP6zreNbyrvLAkU3Bsd3w4gnh=eJjz5cg@mail.gmail.com>
Subject: Re: Consensus call for adding support for non-ack eliciting DATAGRAMs
To: IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f8228205cc225031"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/fJIunRNkKCd2skGUOtyI90jbgNg>
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: Thu, 16 Sep 2021 20:04:22 -0000
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= 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 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> 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> 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> > 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> 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> 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 >>> >>> > > >
- Consensus call for adding support for non-ack eli… Lucas Pardue
- Re: Consensus call for adding support for non-ack… Martin Thomson
- Re: Consensus call for adding support for non-ack… Ian Swett
- Re: Consensus call for adding support for non-ack… Ryan Hamilton
- Re: Consensus call for adding support for non-ack… Rui Paulo
- Re: Consensus call for adding support for non-ack… Gorry Fairhurst
- Re: Consensus call for adding support for non-ack… Vidhi Goel
- Re: Consensus call for adding support for non-ack… Tommy Pauly
- Re: Consensus call for adding support for non-ack… Vidhi Goel
- Re: Consensus call for adding support for non-ack… Lucas Pardue