From nobody Wed Apr 7 09:59:07 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 217FC3A2125 for ; Wed, 7 Apr 2021 09:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.599 X-Spam-Level: X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 VSZuQ7c-xKqA for ; Wed, 7 Apr 2021 09:59:01 -0700 (PDT) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 DE7D53A2122 for ; Wed, 7 Apr 2021 09:59:00 -0700 (PDT) Received: by mail-wm1-x32a.google.com with SMTP id j4-20020a05600c4104b029010c62bc1e20so1562375wmi.3 for ; Wed, 07 Apr 2021 09:59:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2VDkBFoTIMPML0ElKAfF01m5F74YXhJufXexKv+ImfE=; b=eRdqatijjILgyZ1Xo0XM5hGE7oZnGAAmr0QqLo7peZFUOVV0rV0D8IMq3Dxte/Igw0 P3thFJjB8mI1zAi9FNyuHrm6Tz6cK+0Kp42PItXjee2gs9aM5Fh2/gmQ0/riXmm1h0Mb uAQleUM+1lDUh06QFiTIG54MgQ+26CdSdywFJFrJKHy6BTAlcUoZDditG6MErNkzykG+ v3ALdctsAUeaxFueLLELLGSK7NiA7kdSb7wASqGWfBWWrp51ywQLEC7TWLYvGADXyXDQ hgcOD38CcABEuOzKlFWI8pTNPy+S8hEvi8V5WurKOw/BEMIiD6ERCblCEHtb/Wt9lCBe SKtQ== 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; bh=2VDkBFoTIMPML0ElKAfF01m5F74YXhJufXexKv+ImfE=; b=gbEHL8ByYimw3UnhJndso878EwaBcrL/zqjrc3CCJrMtHAuyGQv0e+PgEuyQ3XUBpI NudpnbjBxdy/2WdIGWWmDTVyJ30pb3iaP8sD5vxvHqXO0aSdajEti6vcyvF+jnKFrp26 H3/cW7DKR/6xkvnF0bWfdWqD/XVX9COA3+tiWyRZF9kmgqSHIS5Bh3hO+aCmQc91PlFs DuzLFl0y0DbgHtLqzp/7XR30OGuK/Ha+i7H6UDymaYDoWOEDF+vaan6Lk65uzpcek+eY IX/sips7tyvG7SFT+gh6eT0+zPD2vhY0+LBdleAahEPTNTESFa8R8GsYmBt2x5lTJJVr +k6A== X-Gm-Message-State: AOAM530m+Wooc2t7DIFcKEGg8ntTpneZSMgcgAfD/aOqom5MnulHuSur Ix25AD3yjiEhTjQshk06AK0SVEJWy1yf24bjcR9yJ8A66NOmAg== X-Google-Smtp-Source: ABdhPJzU2+CJ1VgZotipaHepPOMLcyAmy6smAjOVg2oK7xG1JbGAEkAX4yGp7MP/M1iHB7ZBtH+QkDB/apLTDnpDKDY= X-Received: by 2002:a05:600c:4108:: with SMTP id j8mr3877287wmi.183.1617814738191; Wed, 07 Apr 2021 09:58:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ian Swett Date: Wed, 7 Apr 2021 12:58:45 -0400 Message-ID: Subject: Re: Call For Adoption QUIC: delayed-ack To: Mirja Kuehlewind Cc: Matt Joras , IETF QUIC WG Content-Type: multipart/alternative; boundary="000000000000c8b11005bf64d81f" 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, 07 Apr 2021 16:59:06 -0000 --000000000000c8b11005bf64d81f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mirja, 1) 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? 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 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 eith= er > 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. Immediat= e > 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. S= ee > 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 an= y > changes are only relevant for specifics of TCP) > > Mirja > > > > =EF=BB=BFOn 30.03.21, 21:39, "QUIC on behalf of Matt Joras" 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 Apri= l > 6th. > > Thanks, > QUIC Chairs > > [1] https://datatracker.ietf.org/doc/draft-iyengar-quic-delayed-ack/ > > > --000000000000c8b11005bf64d81f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mirja,

1) min_ack_delay is used to l= imit the minimum ack delay you can request in the ACK_FREQUENCY frame: &quo= t;Any value smaller than the "min_ack_delay" advertised by this e= ndpoint is invalid."=C2=A0 https://tools.ietf.org/html/draft-= iyengar-quic-delayed-ack-02#section-4. After re-reading, possibly "= ;this endpoint" is not specific enough?


Thanks for reading, Ian

On Wed, Apr 7, 2021 at 9:56 A= M Mirja Kuehlewind <mirja.kuehlewind=3D40ericsson.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 comm= ent:

1) It seems like min_ack_delay is "only" used for negotiation bec= ause 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 yo= u 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. Immedi= ate 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. Se= e also https://tools.ie= tf.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



=EF=BB=BFOn 30.03.21, 21:39, "QUIC on behalf of Matt Joras" <<= a href=3D"mailto:quic-bounces@ietf.org" target=3D"_blank">quic-bounces@ietf= .org on behalf of matt.joras@gmail.com> wrote:

=C2=A0 =C2=A0 Hello all,

=C2=A0 =C2=A0 Now that we have been rechartered we can move forward with ad= opting
=C2=A0 =C2=A0 new items. It is the opinion of the chairs that the delayed-a= ck
=C2=A0 =C2=A0 draft[1] has sufficient interest from and relevance to the WG= to be
=C2=A0 =C2=A0 formally adopted. This email is the call to do so. There are = already
=C2=A0 =C2=A0 several interoperating implementations of the current draft. = Please
=C2=A0 =C2=A0 reply to this email with any comments, the call will run thro= ugh April
=C2=A0 =C2=A0 6th.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 QUIC Chairs

=C2=A0 =C2=A0 [1] https://datatracke= r.ietf.org/doc/draft-iyengar-quic-delayed-ack/


--000000000000c8b11005bf64d81f--