Re: [Last-Call] Last Call: <draft-ietf-quic-recovery-32.txt> (QUIC Loss Detection and Congestion Control) to Proposed Standard

Yoshifumi Nishida <nsd.ietf@gmail.com> Sun, 25 October 2020 12:42 UTC

Return-Path: <nsd.ietf@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 398883A02BD; Sun, 25 Oct 2020 05:42:20 -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=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 Th4stb4iGMXm; Sun, 25 Oct 2020 05:42:18 -0700 (PDT)
Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 62BD63A02C1; Sun, 25 Oct 2020 05:42:18 -0700 (PDT)
Received: by mail-qv1-xf32.google.com with SMTP id 63so1186008qva.7; Sun, 25 Oct 2020 05:42:18 -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=8wrqH8s90EB+g0AWPLDA6t4fRVdzyHPWumYihINquOc=; b=IxBqy/V80oMJluK9nlK19RTf1I4cnGui9sVF//n4HN2dajFB61lxzJuJ3OjluHWKeo FmYYFRgl+cE36Pl/M6gaAgr/cFN4gSb7PIBhDKHNpj+qNngJ99CxukLfE+OX2GV8jyP1 mvfizgGt/nMsLfIJZjcNn5wzhPI1UHQzPR9FRUKRnF+avNlucFRbMR1EnIBbir83+1AA Zts0UfYoA9vY7g4Lxr5GIzThcsjEAhwgzGCNS9BmqbjvrKjANsI/XkPZbiduyIw70Qbi JQM8MDP8HVC6bxWca/pHxbuFYm8kuHNHfE066FB4wQKcqoSRzj/fP9gVBpKnJA35tmCm SNrQ==
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=8wrqH8s90EB+g0AWPLDA6t4fRVdzyHPWumYihINquOc=; b=LSJgbm9AUClquptgV+0Z4RmRnTtoTpkI5t8Ho8W9PfxXyoAjAOjTDD/mlr0tcCcfoT M+BA3Y1SCTclPDcVomQf3e1zsAYfvi9rogO45HUbPgJsyH5tesHPsNvD5/i5x7EaSJZl xiXJZ8nlbfa5sMKuZsq9XxDjO8ASVtUWO/q3fiXalbSQDqQnaudxWxmImzxz+tNCHSj/ TYOaeGoAO//NYkP6rBK4ENTgcaycpivCn++UCSaYBxL8pqwP5ry8VF/l/yiVUiUgxmBQ bAPpP4ufkVVqWZaYHH6oF/FAo8RZ7Y277kl+ot1c1c+QAFZS1vsDGU78IYCJx45rf75M 0G+Q==
X-Gm-Message-State: AOAM530P1N4AjR614N/9/U9uYRZYeniz9OeT8lAQbl8ec7efl9FTD835 dm/taQyvlAi40ebbWujnAx9HFuLw0OqJmPDWuk5WC1Q9
X-Google-Smtp-Source: ABdhPJzXQu2bBt0k9kyTBoBT1j+MJZ3lg92BKCdlVViLWIKQfM70TzlVPUmF4T6fohgKy5AknFpL83kV8fZM4dw6+zQ=
X-Received: by 2002:a0c:f8cd:: with SMTP id h13mr8429679qvo.10.1603629737254; Sun, 25 Oct 2020 05:42:17 -0700 (PDT)
MIME-Version: 1.0
References: <160328681672.23859.2886286697959671083@ietfa.amsl.com> <fe6fd24f-94cf-2d98-db5e-0a848292ae4f@erg.abdn.ac.uk>
In-Reply-To: <fe6fd24f-94cf-2d98-db5e-0a848292ae4f@erg.abdn.ac.uk>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Sun, 25 Oct 2020 05:42:06 -0700
Message-ID: <CAAK044T250zWmn-5Ep3_0Gnd+PpAcX-skhCzQ7-ehJh3MTYJVw@mail.gmail.com>
Subject: Re: [Last-Call] Last Call: <draft-ietf-quic-recovery-32.txt> (QUIC Loss Detection and Congestion Control) to Proposed Standard
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Last Call <last-call@ietf.org>, IETF-Announce <ietf-announce@ietf.org>, draft-ietf-quic-recovery@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>, quic@ietf.org, quic-chairs@ietf.org, lars@eggert.org
Content-Type: multipart/alternative; boundary="000000000000d7213b05b27e24d6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/sIXH5eDChjI6j2loEbWxhsx73y0>
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: Sun, 25 Oct 2020 12:42:20 -0000

Hi Gorry,

On Sat, Oct 24, 2020 at 4:36 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk>
wrote:

>
> So I reviewed this ID several times in the WG. At the WGLC, I had no
> substantive issues, and I see quite a lot of change since WGLC (most
> really good!).
>
> However, I also something I hadn't expected and that since rev -30, this
> has introduced the option to use PRR:
>
> ..."Implementations MAY reduce the congestion window immediately upon
>          entering a recovery period or use other mechanisms, such as
>          Proportional Rate Reduction ([PRR]), to reduce the congestion
> window
>          more gradually."
>
> This did surprise me, but perhaps the working group thinks this is Reno
> behaviour?
>

This seems to be ok to me as QUIC's CC already deviates from Reno in
various points and the doc just says "similar to Reno".
Another point is this part is not mandatory.

Since PRR doesn't change the window size after recovery, the deviation
looks minor from my point of view.
As long as the algorithm reduces the congestion window properly (be close
to ssthresh at the end of recovery), I think it won't be aggressive.

Thanks,
--
Yoshi