Re: Call For Adoption QUIC: delayed-ack

Matt Joras <matt.joras@gmail.com> Thu, 08 April 2021 14:02 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 CBDC43A18BA for <quic@ietfa.amsl.com>; Thu, 8 Apr 2021 07:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 2h1fTK0YhNPD for <quic@ietfa.amsl.com>; Thu, 8 Apr 2021 07:02:27 -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 616BF3A18B7 for <quic@ietf.org>; Thu, 8 Apr 2021 07:02:27 -0700 (PDT)
Received: by mail-lf1-x12f.google.com with SMTP id b4so4212587lfi.6 for <quic@ietf.org>; Thu, 08 Apr 2021 07:02:27 -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; bh=1oQFpbEM+FJGPkCiC0pQ99LWlFXnuEHiV6d6o15FOvI=; b=lLmFh6XF3CWyFkHyhrV1VCJNb4O5t+qjruJssnma/AyLICqGVkMmG/+nJLN4u12ycj 08joP72vfPLf+PQVRE73kXbi6fqBPxOOfgeJkNOOy5pEoYWlCSS7vkJcWABMIVfdqE3n jXrtQ802EiHfc4u42lK0xXhrgWxezwIHezuIGm+uM+fXgckyH+Nct2mDQYvRFfYxVz7K M2StVM+vjnUYc6ES356yL7CQZ08GZp7rm0TIa096VTf6IYXiR3QvdaAunxCIm/uaUXuv KhZzgg/xy2EvgaYMyblokbfAWSywqEWUsvKj/Z0wXc1YCISBwL216FEXvr+w5vDYXmje gfNg==
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=1oQFpbEM+FJGPkCiC0pQ99LWlFXnuEHiV6d6o15FOvI=; b=tGJUoz50Y62jGcPjIAVLhzi4ilryfkVztVYXUN6ytfA7GYtKt1vcLgvC78Q1jx4kqG zGFoozeJROD+RzV0CHypMxW+1uN+eyWyR/4SXKrvpjDChQKmUYnWwilofMuqRULQcAXp onnFygbj20vOkoF/Ip6C10Oi18lfSmjhDVxdHBeuNOWdXG52RdMJzNpoHNJ7tadGtKkQ PD8mH62EN7kg7A85oNMaiOgyELTZasnmu0RYFdp+N01WdhS5Y2E7q8IuXSi2BOvRj16U NsxG/3ErO0K87h/WQSlfVaOeSi/EeVii7+CX6uDASQ+cfHukT8UJSt+EfFhTihiRGXfy TBZw==
X-Gm-Message-State: AOAM533WvWRgTvkh3UwJvrHpfwUlzNjJtX9/UkF0f64Rhnf6lP/4LHdB 6w2NNdqV0ZxW6go1CrQkj+ISaJFzrPqzZfj6nmE=
X-Google-Smtp-Source: ABdhPJzRhzMU1sZ6VMt2HE0WNyVXIXwz/YRvc6ePgOmNq+N2SHHZJagyDyFJBliSK0OEUBNlniWULnbk4CQOFEotHdI=
X-Received: by 2002:a05:6512:3d1c:: with SMTP id d28mr6211088lfv.41.1617890543311; Thu, 08 Apr 2021 07:02:23 -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> <CADdTf+jDSXbLPnnJREhWjcOBKgH4ySHi5tyJ-pm0_4nD=fXNog@mail.gmail.com> <8D2D26F4-6159-46B5-B7F9-7DCCE72E9F94@ericsson.com>
In-Reply-To: <8D2D26F4-6159-46B5-B7F9-7DCCE72E9F94@ericsson.com>
From: Matt Joras <matt.joras@gmail.com>
Date: Thu, 08 Apr 2021 07:02:12 -0700
Message-ID: <CADdTf+jko5aPCuJFxP-u3SuR2RH_A6msTo0RPoT2n2zRzoVwUw@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: multipart/alternative; boundary="0000000000001e9d8f05bf767f08"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/0D64pj0b3jqqOfiElOb93ywTENE>
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, 08 Apr 2021 14:02:33 -0000

Hi Mirja,

Sorry I must have misinterpreted your reply. I interpreted the
min_ack_delay to be nothing more than the lower bound a receiver is willing
to set its max_ack_delay to be. I.e. it's telling its peer to not send
ACK_FREQUENCY frames with an update max ACK delay value lower than it
specifies. In a sense it's a "min update max ACK delay", which is rather
wordy but more precise. Perhaps we should try to clarify the name or the
text describing it.

Thanks,
Matt

On Thu, Apr 8, 2021, 1:44 AM Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>
wrote:

> Hi Matt,
>
> your description below does not mention min_ack_delay and that's the part
> I was wondering about. The implementation as you explained below is also
> what I would expect but it less clear to me what to do with the values
> provided by min_ack_delay.
>
> Mirja
>
>
> On 07.04.21, 21:00, "Matt Joras" <matt.joras@gmail.com> wrote:
>
>     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://protect2.fireeye.com/v1/url?k=826ab963-ddf18063-826af9f8-86fc6812c361-c26453d8be9cda19&q=1&e=28123d83-0cab-4534-b339-c4c176ece256&u=https%3A%2F%2Fgithub.com%2Fjanaiyengar%2Fack-frequency%2Fissues%2F48
> 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
>
>