Re: Call For Adoption QUIC: delayed-ack

Ian Swett <ianswett@google.com> Wed, 07 April 2021 16:59 UTC

Return-Path: <ianswett@google.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 217FC3A2125 for <quic@ietfa.amsl.com>; 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 <quic@ietfa.amsl.com>; 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 <quic@ietf.org>; Wed, 7 Apr 2021 09:59:00 -0700 (PDT)
Received: by mail-wm1-x32a.google.com with SMTP id j4-20020a05600c4104b029010c62bc1e20so1562375wmi.3 for <quic@ietf.org>; 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: <CADdTf+gUYjUL=Z0zbhS-Hn7TURxXJtzcL8Nou0v0rvzwOSf5Wg@mail.gmail.com> <CBBCC238-8456-403B-9670-3C75CE184392@ericsson.com>
In-Reply-To: <CBBCC238-8456-403B-9670-3C75CE184392@ericsson.com>
From: Ian Swett <ianswett@google.com>
Date: Wed, 07 Apr 2021 12:58:45 -0400
Message-ID: <CAKcm_gPBL86LgCff0XBw0hnfgMyBqsT3CMt0u_vEg4Tn4P6+cw@mail.gmail.com>
Subject: Re: Call For Adoption QUIC: delayed-ack
To: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>
Cc: Matt Joras <matt.joras@gmail.com>, IETF QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c8b11005bf64d81f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/oRAtwlTSTMSgAPaDhVenzctOQKI>
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 16:59:06 -0000

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 <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/
>
>
>