Re: Call For Adoption QUIC: delayed-ack
Matt Joras <matt.joras@gmail.com> Wed, 07 April 2021 19:01 UTC
Return-Path: <matt.joras@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 0B9123A2688 for <quic@ietfa.amsl.com>; Wed, 7 Apr 2021 12:01:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 KQ-csNwMyTie for <quic@ietfa.amsl.com>; Wed, 7 Apr 2021 12:01:23 -0700 (PDT)
Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 A8A443A26C8 for <quic@ietf.org>; Wed, 7 Apr 2021 12:00:54 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id w28so30166739lfn.2 for <quic@ietf.org>; Wed, 07 Apr 2021 12:00:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ToFU0yh/EEjY0mpscnAjbHSWO4JBQhKu+uEEsQNBaEo=; b=NOGSkBgPXOLUKfTbDxQKkPxs3w95EOerpjJ/fjKDxbeD+ZUwMvUQydrF9wCzK8VTnv Vgz/YxM2mQz+bpu1UjN9dojaENXxVkYTKlV1nGh2qQwEY6TWqWiXRtjwbsKyMg3w+Lxy IwteWpN0ICc7uKY3oixEl+S2f0FkpjRET6EPVEhts/tvmqNz/dbERPOUjpfVDkkIC/yL 6wmP2PeCrB25NLzbPEVfj9ArWjfYuLQtoIFJmo96dV3MABGDmtyZ72HpMXVKJdBy0hNO zbyD83s6eUxnSGcmlfHMzcEiylY1erD+dTah0dTxPBia95ITTokC1wW5Phl6aEbRo1PC AEXQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ToFU0yh/EEjY0mpscnAjbHSWO4JBQhKu+uEEsQNBaEo=; b=tAMj4DQwzUI7UT9Qi2ZI4bJJOOT5z4gXAmVmxTt9BrjltdW3n3LOCs2BYJxlimY0HO wMj7DGDEY2ZvUEk2C63p2kqSEn1GR92PxVsGtX1loQdJPHu+vuddLsUdLBakh1AUZWMF 5R/cIMuQF8VsQA+3Uzviwpj1cQqzlScOyNGmNhvfeZJLXZ06Loa3JVgNf28kjFdYEpmp bckRkob2CAKBH2jYZTJ9OTgTs30ayJ0HLm3OlKuoP/QJNOtaPSAi8EdTtRDU2iT0aCdF 6I/Z5KpYweyBGzVOoSQBY+0rc3af2Lxz4xQQsxJEMR+rBbEbbVqFDbcfg4MKOkM0/2yt KgoQ==
X-Gm-Message-State: AOAM533PGCLkfhVruxrV092p9Ba00etC/pmLOlLLRVqVUldR32KrSfyT lIsj4EJysYLIFq9U41r898XkeXJQHW8ICrvfSLg=
X-Google-Smtp-Source: ABdhPJyB/+wa9yp1vM+sqVQDJ+9yDHC8fHC96z74z5hnmpuHHrHduN8S8TA1a4EoBt+q6v5v0PjjadmDMk7atD4/EM8=
X-Received: by 2002:a19:86c3:: with SMTP id i186mr3282380lfd.434.1617822051286; Wed, 07 Apr 2021 12:00:51 -0700 (PDT)
MIME-Version: 1.0
References: <CADdTf+gUYjUL=Z0zbhS-Hn7TURxXJtzcL8Nou0v0rvzwOSf5Wg@mail.gmail.com> <CBBCC238-8456-403B-9670-3C75CE184392@ericsson.com> <CAKcm_gPBL86LgCff0XBw0hnfgMyBqsT3CMt0u_vEg4Tn4P6+cw@mail.gmail.com> <FEDE1091-6E1E-4370-9352-DFB49D8B3624@ericsson.com>
In-Reply-To: <FEDE1091-6E1E-4370-9352-DFB49D8B3624@ericsson.com>
From: Matt Joras <matt.joras@gmail.com>
Date: Wed, 07 Apr 2021 12:00:40 -0700
Message-ID: <CADdTf+jDSXbLPnnJREhWjcOBKgH4ySHi5tyJ-pm0_4nD=fXNog@mail.gmail.com>
Subject: Re: Call For Adoption QUIC: delayed-ack
To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ZEe59EU9-aQKEcK6-nR3hH9GFc4>
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, 07 Apr 2021 19:01:34 -0000
Hi Mirja, Below is my interpretation though since we are having this discussion perhaps this needs to be made clearer in the text. On Wed, Apr 7, 2021 at 10:06 AM Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> wrote: > > Hi Ian, > > > > see blow. > > > > From: Ian Swett <ianswett=40google.com@dmarc.ietf.org> > Date: Wednesday, 7. April 2021 at 18:59 > To: Mirja Kuehlewind <mirja.kuehlewind@ericsson.com> > Cc: Matt Joras <matt.joras@gmail.com>, IETF QUIC WG <quic@ietf.org> > Subject: Re: Call For Adoption QUIC: delayed-ack > > > > Hi Mirja, > > > > min_ack_delay is used to limit the minimum ack delay you can request in the ACK_FREQUENCY frame: "Any value smaller than the "min_ack_delay" advertised by this endpoint is invalid." https://tools.ietf.org/html/draft-iyengar-quic-delayed-ack-02#section-4. After re-reading, possibly "this endpoint" is not specific enough? > > > > I was missing further guidance on how to implement that. Usually if I have a packet tolerance of e.g. 2, I would just ack every other packet. Am I supposed to delay my ack if the last was ACK was send to close by? Would I need to use the delayed ACK timer for that or a separate timer? Didn’t think that through but thought it would be good to have more guidance in the draft. > The ACK_FREQUENCY frame essentially just gives a sender a mechanism to alter the otherwise hard coded behavior of the receiver and otherwise does nothing to change the logic. In QUIC we have 3 things which can affect ACK frequency : 1. "packet tolerance" (I really wish we could come up with a better term for this), which is defaulted to two, or every other packet. 2. Max ack delay, settable with a default of 25ms. 3. Out of order packets, via a threshold An ACK is supposed to be sent when any of the above conditions are met. The same is true when using the ACK_FREQUENCY frame, except that the conditions can change during a connection. The packet tolerance and max ACK delay are dynamic instead of static, so the logic should be identical except for allowing these values to change. The out of order packets behavior is also controllable in a binary fashion, effectively removing the condition entirely. > > Mirja > > > > > > > > > > 2) I filed https://github.com/janaiyengar/ack-frequency/issues/48 for this. > > > > Thanks for reading, Ian > > > > On Wed, Apr 7, 2021 at 9:56 AM Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org> wrote: > > Hi, > > I know I'm too late but I also support adoption. > > But now that I found the time to read the draft again, I also have two comment: > > 1) It seems like min_ack_delay is "only" used for negotiation because the draft does not specify any further what to do with this value. Isn't either min_ack_delay or Packet Tolerance sufficient, e.g. what if you have a packet tolerance of 1 but a min_ack_delay of > 0? > > 2) For ECN, you don't need to send an immediate ACK for each CE. Immediate ACKs are most important when the codepoint switches to CE, but then, if multiple CEs in a row are received, you can bundle the ACK information. See also https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.2.5.1 > (Note that we are still working on that section for AccECN but I think any changes are only relevant for specifics of TCP) > > Mirja > > > > On 30.03.21, 21:39, "QUIC on behalf of Matt Joras" <quic-bounces@ietf.org on behalf of matt.joras@gmail.com> wrote: > > Hello all, > > Now that we have been rechartered we can move forward with adopting > new items. It is the opinion of the chairs that the delayed-ack > draft[1] has sufficient interest from and relevance to the WG to be > formally adopted. This email is the call to do so. There are already > several interoperating implementations of the current draft. Please > reply to this email with any comments, the call will run through April > 6th. > > Thanks, > QUIC Chairs > > [1] https://datatracker.ietf.org/doc/draft-iyengar-quic-delayed-ack/ > Matt Joras
- Call For Adoption QUIC: delayed-ack Matt Joras
- Re: Call For Adoption QUIC: delayed-ack Dmitri Tikhonov
- Re: Call For Adoption QUIC: delayed-ack Nick Banks
- Re: Call For Adoption QUIC: delayed-ack Christian Huitema
- Re: Call For Adoption QUIC: delayed-ack Rui Paulo
- Re: Call For Adoption QUIC: delayed-ack Martin Thomson
- Re: Call For Adoption QUIC: delayed-ack Marten Seemann
- Re: Call For Adoption QUIC: delayed-ack Sean Turner
- Re: Call For Adoption QUIC: delayed-ack David Schinazi
- Re: Call For Adoption QUIC: delayed-ack Tommy Pauly
- Re: Call For Adoption QUIC: delayed-ack Ian Swett
- Re: Call For Adoption QUIC: delayed-ack Vidhi Goel
- Re: Call For Adoption QUIC: delayed-ack Gorry Fairhurst
- RE: Call For Adoption QUIC: delayed-ack Ingemar Johansson S
- Re: Call For Adoption QUIC: delayed-ack Matt Joras
- Re: Call For Adoption QUIC: delayed-ack Mirja Kuehlewind
- Re: Call For Adoption QUIC: delayed-ack Ian Swett
- Re: Call For Adoption QUIC: delayed-ack Mirja Kuehlewind
- Re: Call For Adoption QUIC: delayed-ack Matt Joras
- Re: Call For Adoption QUIC: delayed-ack Mirja Kuehlewind
- Re: Call For Adoption QUIC: delayed-ack Matt Joras