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

Ian Swett <> Fri, 15 July 2022 17:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 91E05C16ECB6 for <>; Fri, 15 Jul 2022 10:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.608
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T3yxt_RbInPB for <>; Fri, 15 Jul 2022 10:32:52 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 9E8B5C1A5D12 for <>; Fri, 15 Jul 2022 10:31:51 -0700 (PDT)
Received: by with SMTP id z12so7653996wrq.7 for <>; Fri, 15 Jul 2022 10:31:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <>
In-Reply-To: <>
From: Ian Swett <>
Date: Fri, 15 Jul 2022 13:31:38 -0400
Message-ID: <>
Subject: Re: Call for Adoption: Careful resumption of congestion control from retained state with QUIC
To: Mirja Kuehlewind <>
Cc: "" <>, Martin Thomson <>, Gorry Fairhurst <>
Content-Type: multipart/alternative; boundary="000000000000ae90d605e3db6444"
Archived-At: <>
X-Mailman-Version: 2.1.39
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: 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=> 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" <
> on behalf of> 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.