Re: Call for Adoption: Careful resumption of congestion control from retained state with QUIC

Ian Swett <ianswett@google.com> Fri, 15 July 2022 17:32 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 91E05C16ECB6 for <quic@ietfa.amsl.com>; Fri, 15 Jul 2022 10:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.608
X-Spam-Level:
X-Spam-Status: No, score=-17.608 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_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3yxt_RbInPB for <quic@ietfa.amsl.com>; Fri, 15 Jul 2022 10:32:52 -0700 (PDT)
Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8B5C1A5D12 for <quic@ietf.org>; Fri, 15 Jul 2022 10:31:51 -0700 (PDT)
Received: by mail-wr1-x433.google.com with SMTP id z12so7653996wrq.7 for <quic@ietf.org>; Fri, 15 Jul 2022 10:31:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7KRi0hrdwXJLCa97J+fZI0PgMK/4VG5Srb4YlNzr3j4=; b=SOjM6qjex3qgtQw833EV3qQlYH4u+Dz1KK0gaLsSmwAciX/pv6R9T3T/7qbaZ3p240 YR8USl/fsQh4UcJSCmdgyPvWGiqHFI7xvFjcX+bP7g4XeS0gGxmnYuZ0PIjFh0QxyvRw bgCC/Hm19Q8jEOqN3Fl8MSkR4cqQmOqVnVeu5Woqf01IMvV8kXoAWUOVjFN2ajec4T4W uE4F8ojlti3IpSWbFMtFuDVfcjw4UgXGwklMZUw6dnjA/ZluaPpSyDaBomnsBTf/OK4u SNRNB78VtjSjaemCBVgIONrYMXPR9TD6c9zlc/Qqt0jaMVJeg+jluruuGczUMgs1//U9 9lZA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7KRi0hrdwXJLCa97J+fZI0PgMK/4VG5Srb4YlNzr3j4=; b=sNLkU9yE67a+bjK3jXkc7Mr8nmUTY+rKc0WE6m/Ip+g5cYSM1lZjk/gWDhQ2K54yO9 Vbn5fB9M4Kvvdeu+Ovat/NiBE+hl4gImrBlEn2kYi6/dWr2EXQgZmebbDg//DmbO1Otl W6K5ee86nY9nsZ8eJ8oNH+MTITDtKTY8m6DVW7Zp7XR1ZUsC+JQBFuzdquLZOlUoGTaj WZCvcWlxdZnuVYasMGWGSavHQCnLlLJPy0kCYisVbf5gM40O0RAKoT7hz8P/nSPay2Yq +Jgscil11LEnXs+uy+G/HnKkKN1bYmZ6ru0xsuAK4xR/dxf6/8j8BPuBu8pNS8KKMd9d E1hA==
X-Gm-Message-State: AJIora+E94Qd8wVbdeQY1NXH6AZr6jzqeho9oKJr7xoiHDtouRW9B1MK zdW7T7zZBYtd2ME2STrGooqmt4N5PgoisF9HZ79EpAJ9p0s=
X-Google-Smtp-Source: AGRyM1uy0VqYwHx41Exi/1s3ve8TnG5Ojsk9PGi1iGyLRz/8cvuCLXdiGf8YaKNhlyZY20TBwvI0BZ5OILortHPUvVU=
X-Received: by 2002:a05:6000:1569:b0:21d:a6cb:b8d2 with SMTP id 9-20020a056000156900b0021da6cbb8d2mr13483396wrz.342.1657906310037; Fri, 15 Jul 2022 10:31:50 -0700 (PDT)
MIME-Version: 1.0
References: <CALGR9oaNqaE3Ry=Skg4c=KPwP6Cz2MA0P8zzZ8v2+amQSeSXjg@mail.gmail.com> <c3d65b5a-f18c-48e4-9403-a27ca5c4f24b@beta.fastmail.com> <5c820d25-fe7e-08b9-8392-eb3525c0a36d@erg.abdn.ac.uk> <0fcf5343-5097-431d-99ca-be12ec6fa8e6@beta.fastmail.com> <0670E2A6-EE4F-44BC-BD8C-598441FE7CE3@ericsson.com>
In-Reply-To: <0670E2A6-EE4F-44BC-BD8C-598441FE7CE3@ericsson.com>
From: Ian Swett <ianswett@google.com>
Date: Fri, 15 Jul 2022 13:31:38 -0400
Message-ID: <CAKcm_gMdqRYVuDfBEEbNDz7=SXJ+rbrno3Rk76bp6k-UpB9PyA@mail.gmail.com>
Subject: Re: Call for Adoption: Careful resumption of congestion control from retained state with QUIC
To: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>
Cc: "quic@ietf.org" <quic@ietf.org>, Martin Thomson <mt@lowentropy.net>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Content-Type: multipart/alternative; boundary="000000000000ae90d605e3db6444"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/MAQn0S4DIqIvozW6kyBvOk3CVy8>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.39
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: Fri, 15 Jul 2022 17:32:56 -0000

I believe this document is worth working on, but it seems better suited to
the proposed Congestion Control Working Group.

On Wed, Jul 13, 2022 at 1:24 PM Mirja Kuehlewind <mirja.kuehlewind=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi all,
>
> I took a quick re-read of the document and think is very well written and
> clear. However, I agree with Martin that this (part of the) document
> doesn’t seem to be QUIC-specific and therefore probably the QUIC group
> might not be the right place to advance this document.
>
> Just as an editorial note, while the text is clear and well written as II
> just said, I'm not sure if all this discussion needs to be part of a
> potential IETF RFC. I think the most important part might be in section 6.
>
> Also reading about the "unvalidated" phase, this trigger the association
> to RFC7661 to me. Given Gorry is an author of both documents, I assume
> there is a connection. So, couldn't/shouldn't we even re-use the algorithm
> specified in RFC7661?
>
> Mirja
>
>
>
> On 13.07.22, 14:50, "QUIC on behalf of Martin Thomson" <
> quic-bounces@ietf.org on behalf of mt@lowentropy.net> wrote:
>
>     On Wed, Jul 13, 2022, at 19:02, Gorry Fairhurst wrote:
>     > I'm unsure why you think the QUIC protocol is not the best place to
>     > consider such an extension. QUIC has various features that make it a
>     > much easier place to do this type of change - the design of the
>     > transport, the ability to update implementations, and a design which
>     > implies pacing, security, etc.
>
>     Simple test: if you took "QUIC" out and replaced it with DCCP, the
> draft would still work.  This is a congestion control document, not a QUIC
> one.
>
>     Sure, QUIC is a great testbed.  I expect that this will work there.
> It will also work very nicely with TCP.  Google was doing something very
> similar ~10 years ago in TCP, though maybe less measured and careful.
>
>