From nobody Fri Sep 9 15:46:46 2022 Return-Path: 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 E935BC152714 for ; Fri, 9 Sep 2022 15:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2AZgxA36QUZ for ; Fri, 9 Sep 2022 15:46:45 -0700 (PDT) Received: from mail-qv1-xf30.google.com (mail-qv1-xf30.google.com [IPv6:2607:f8b0:4864:20::f30]) (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 63EB5C14F72B for ; Fri, 9 Sep 2022 15:46:45 -0700 (PDT) Received: by mail-qv1-xf30.google.com with SMTP id ml1so2375831qvb.1 for ; Fri, 09 Sep 2022 15:46:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=HVqZ6uC5PEtHyAijBA7/rUzhSZGCO692ths83wVqpLM=; b=mI/ScSdG3j4STYXKC12NqjOytjLpjXTtvyE0q2pd7e/FkRNlpvyigmxFnj6ISdjyr5 HRs5CN0xg6khgVjdZKTePdXJODxwRi8Oik0bO94iDvEEETCSADOJjDuTcfc1tahwBNkg jdzsJl33HTr1EfApPzoMmaguaAstXRps8ZRZmIlfji4YkRg9zNzcoBIZ4q9tbbguSmu6 0bFPJVn+6mIpQWZNYrhJxko3V5ffw1cfPkX0VHCjzKbiYoWRDbLzNDkze/k/WonS8vX4 Cr0F5CzoMAqoQUjYSvLmtpAfW0BONwNlPWEVRQ7rgoNulSIhMvLpb019cUYij/kw/5Bp 9BLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=HVqZ6uC5PEtHyAijBA7/rUzhSZGCO692ths83wVqpLM=; b=hXep/V4yHc3xV16ibeM/J0yRST1/46fWVbSQKM6GYHzX1CPIAjPHFH6aSz/3AkHgSh MtR8Rukw4J73GX42vHy0Mali3SdIMWTgh+tcCYxgvZpqk6wUAEtXqlAzMnPqjhbttP+D hicccrx+3PIBgJlQcONEUNus6sXlVs9btfEHW4ix42r7ZvPJZV7dxOe8XiaDdzbFvvtX U9sikUASSNBOdOKyqKLuosyYJwoqxWVxmOD0wYh+0xo/RkR3FQTFsnYjPbb9KzieW9Cw H2tjsAYfd55XaEvzbDhTWEeMOYQxtJocR0/5ctfIL/G60JE8RkSr4K7IQNZx1OFvpblv t6fA== X-Gm-Message-State: ACgBeo0ag6KNtFJv8Uf6MuUfiiYXo0X66MLRmFJ6DQMUKBtWvF5I9D2o d6LggNHDQgzVLklz29vjb77kY0s82jPJmngLSYRaikt1 X-Google-Smtp-Source: AA6agR4A3OczpEqtQkT3YJfWkr5iaLNLAhu59rKyHmTKEZp95bYojetCbnnhjJC6oboPm1+KJcMQLZ0O6+6nFtVLX/Y= X-Received: by 2002:a05:6214:5187:b0:4aa:b424:54a5 with SMTP id kl7-20020a056214518700b004aab42454a5mr13654507qvb.120.1662763603725; Fri, 09 Sep 2022 15:46:43 -0700 (PDT) MIME-Version: 1.0 References: <5c820d25-fe7e-08b9-8392-eb3525c0a36d@erg.abdn.ac.uk> <0fcf5343-5097-431d-99ca-be12ec6fa8e6@beta.fastmail.com> <0670E2A6-EE4F-44BC-BD8C-598441FE7CE3@ericsson.com> <601DD1C1-C199-48C5-8E58-ED1B201B1F15@bbc.co.uk> In-Reply-To: From: Martin Duke Date: Fri, 9 Sep 2022 15:46:31 -0700 Message-ID: Subject: Re: Call for Adoption: Careful resumption of congestion control from retained state with QUIC To: Matt Joras Cc: "Piers O'Hanlon" , Lucas Pardue , "quic@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f212cf05e8465127" Archived-At: X-BeenThere: quic@ietf.org 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, 09 Sep 2022 22:46:46 -0000 --000000000000f212cf05e8465127 Content-Type: text/plain; charset="UTF-8" (AD hat on) I agree that a congestion control WG would be a fine venue for this; as it's not even chartered, we could incorporate. However, as that process is going slower than I'd like, the authors are welcome to try tsvwg if they don't want to wait. On Fri, Sep 9, 2022 at 10:50 AM Matt Joras wrote: > Hello all, > > To close the loop here, we'd like to thank all respondents to the call for > adoption. The chairs' sense of the feedback is that while this is useful > work that people support at the IETF, it is work in a problem space is more > broadly to do with congestion control and not entirely QUIC specific. As > such, this work is most likely suited to another working group. > Coincidentally, parallel to the adoption call for careful resume, the > Transport Area ADs launched a proposal for a new congestion control focused > WG. This was discussed on the TSVAREA list and during the IETF 114 session, > with next steps posted to the list [1]. A few respondents identified that > this new group, should it form, would be a suitable venue for such a > document. > Based on the feedback we have received, together with other activity in > the IETF, the chairs have judged there is not currently consensus for > adopting careful resume to the QUIC WG. > > Matt & Lucas > [1] - > https://mailarchive.ietf.org/arch/msg/tsv-area/r_4jPmT55sKl0iumvIPklITb9gc/ > > On Tue, Jul 26, 2022 at 4:59 AM Piers O'Hanlon > wrote: > >> I agree it would something useful to work on (given the Linux Kernel has >> provided something similar for tcp with its `ip tcp_metrics` for some time) >> but it seems more general so other working groups could benefit from. >> >> >> >> > On 25 Jul 2022, at 17:16, Lucas Pardue >> wrote: >> > >> > Reminder: the adoption call ends in several hours. >> > >> > If you have yet to comment, please do so soon. >> > >> > >> >> --000000000000f212cf05e8465127 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(AD hat on)

I agree that a congestion c= ontrol WG would be a fine venue for this; as it's not even chartered, w= e could=C2=A0incorporate. However, as that process is going slower than I&#= 39;d like, the authors are welcome to try tsvwg if they don't want to w= ait.

On Fri, Sep 9, 2022 at 10:50 AM Matt Joras <matt.joras@gmail.com> wrote:
Hello all,
To close the loop here, we'd like to thank all respondents to the cal= l for adoption. The chairs' sense of the feedback is that while this is= useful work that people support at the IETF, it is work in a problem space= is more broadly to do with congestion control and not entirely QUIC specif= ic. As such, this work is most likely suited to another working group. Coin= cidentally, parallel to the adoption call for careful resume, the Transport= Area ADs launched a proposal for a new congestion control focused WG. This= was discussed on the TSVAREA list and during the IETF 114 session, with ne= xt steps posted to the list [1]. A few respondents identified that this new= group, should it form, would be a suitable venue for such a document.
B= ased on the feedback we have received, together with other activity in the = IETF, the chairs have judged there is not currently consensus for adopting = careful resume to the QUIC WG.

Matt & Lucas
[1] - https://mailarchive.ietf.org/arch/msg/tsv-area/r_4jPmT5= 5sKl0iumvIPklITb9gc/

On Tue, Jul 26, 2022 at 4:59 AM Piers O'Hanlon = <piers.ohan= lon@bbc.co.uk> wrote:
I agree it would something useful to work on (given the Linux = Kernel has provided something similar for tcp with its `ip tcp_metrics` for= some time) but it seems more general so other working groups could benefit= from.



> On 25 Jul 2022, at 17:16, Lucas Pardue <lucaspardue.24.7@gmail.com> wro= te:
>
> Reminder: the adoption call ends in several hours.
>
> If you have yet to comment, please do so soon.
>
>

--000000000000f212cf05e8465127--