Re: [tcpm] draft-ietf-tcpm-hystartplusplus and QUIC

Praveen Balasubramanian <pravb.ietf@gmail.com> Mon, 26 September 2022 03:18 UTC

Return-Path: <pravb.ietf@gmail.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39F6C14F692 for <tcpm@ietfa.amsl.com>; Sun, 25 Sep 2022 20:18:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.106
X-Spam-Level:
X-Spam-Status: No, score=-2.106 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBv8PA21okjZ for <tcpm@ietfa.amsl.com>; Sun, 25 Sep 2022 20:18:26 -0700 (PDT)
Received: from mail-vk1-xa44.google.com (mail-vk1-xa44.google.com [IPv6:2607:f8b0:4864:20::a44]) (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 DC0DDC14F727 for <tcpm@ietf.org>; Sun, 25 Sep 2022 20:18:26 -0700 (PDT)
Received: by mail-vk1-xa44.google.com with SMTP id bi53so2785854vkb.12 for <tcpm@ietf.org>; Sun, 25 Sep 2022 20:18:26 -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=Ms2pXpHeX8D8KZDhluenavEHfAP/kghKVde8809EiYI=; b=iNspGTbiidWYKESUbkNlZAtMDP0HvYiYPSM4DIBy9W/4pcZl8tnWHn/IMEZF7dEUVF wfWltE5agRYQbanyvFu3GyfTkv6QKwl1voLqdnpI9DXIHvOjE6/G92W1vPIy0NiAnrI6 9ckudHKaGxrnf6KtTy1x97HVRFOy0b35vWmqpZc/0/LrkWE1SWDdz+k6afK8q9U3+48D ItEAvsl+qGilLWJtfbsjs3RwoADlxGg97mAb24L4Bueov6cBm1xG/R1EWbH6Gr0jDQr4 Fl+jsW2K+N2qeVWfUdImiXEu3+3ET9NO8mktWynBvCoTiVRmmkEqm+PlWRC3XPeL+BNZ 8yEA==
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=Ms2pXpHeX8D8KZDhluenavEHfAP/kghKVde8809EiYI=; b=3o7hFXLg/wRcDlR/RahV3Tm394YUjW8gdSyP7SDCD3oZwRWzBlP7lBCYziL3JV59RM VCNbpVRn9hLE4z+uOKL48mmNIwX2U3r8e+n0aL3JsgHNNEgfLx/MFp5qEBF8lHbwvVUR bDv21uhVCMzdVrPzOoYlqD00J4Y3IpINeFuGLe81dn6KZ9wikje2bY+pQ7J3jI5I702u Z2CswAWRz2UdzxCHCYjaQ4r866+e9lrSr7Z11bCc1Nrnuf0HaOmyN/Mz+g7rYyqXr15L S6BCAL6Tflnuqsf/11MJNbrJS8H+r2e13phtEBZ1i0pxL6LJcn7rrTkoZhh7kdDDz4bf JtGw==
X-Gm-Message-State: ACrzQf2iur+dwqPV1ihG6eUoi2bCIiSApquRBNPw8iRDPRyjbRLa4QNQ tOlJbJErnl5n1/HC/65/XTvH01S5E9OQ4G154hMWpJCNspo=
X-Google-Smtp-Source: AMsMyM7ddnmn0xNgBLgR4JKb4uKDXeVFfeEQyx1CnxJFW39Iu2ziMnCs8sagcWuYHXhpjPdh3De7xLBnEVU7F5KFPz4=
X-Received: by 2002:a1f:918d:0:b0:3a1:e376:7463 with SMTP id t135-20020a1f918d000000b003a1e3767463mr7406894vkd.38.1664162305385; Sun, 25 Sep 2022 20:18:25 -0700 (PDT)
MIME-Version: 1.0
References: <8886433A-25A4-428D-94F1-E2CFFF02E712@ericsson.com> <E47FA00A-699E-4BAD-A18A-8F6792F1565B@apple.com> <A02EDDBB-B7BB-4DCD-8D7A-C41F89EA72EA@ericsson.com> <10BE0012-DB95-44CF-9E30-232E7043901B@apple.com>
In-Reply-To: <10BE0012-DB95-44CF-9E30-232E7043901B@apple.com>
From: Praveen Balasubramanian <pravb.ietf@gmail.com>
Date: Sun, 25 Sep 2022 20:18:14 -0700
Message-ID: <CAL=F3yJkbaARrONH=Yhq3=_FDNS1hkXYovOepjw7gPi5ngtVjA@mail.gmail.com>
To: Vidhi Goel <vidhi_goel=40apple.com@dmarc.ietf.org>
Cc: Zaheduzzaman Sarker <zaheduzzaman.sarker=40ericsson.com@dmarc.ietf.org>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, Christian Huitema <huitema@huitema.net>
Content-Type: multipart/alternative; boundary="0000000000000fa7f105e98bfb3d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/0RLDgAuE30LqLiCIUPcdlk_xKLE>
Subject: Re: [tcpm] draft-ietf-tcpm-hystartplusplus and QUIC
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2022 03:18:31 -0000

Junho already implemented a QUIC version of Hystart++ using this draft
https://blog.cloudflare.com/cubic-and-hystart-support-in-quiche/ and the
feedback received was already incorporated in early revisions. So I don't
think we need any additional changes to the draft since there is running
deployed QUIC code based on the draft. Adding more text for each transport
will just make the document longer. For future I agree that it would be
nice to have a congestion control working group that can publish one
transport-independent document or several per-transport documents for each
algorithm.

On Tue, Sep 20, 2022 at 11:55 AM Vidhi Goel <vidhi_goel=
40apple.com@dmarc.ietf.org> wrote:

>
> I am not sure what you meant by “fair”. "not fair" to whom? in QUIC
> working group the chairs have run a consensus call and that resulted in a
> particular view.
>
> I meant "not fair" to authors who proposed Careful resumption of
> congestion control.. to QUIC WG but I get your point about it being a
> decision of WG chairs. Maybe I got too carried away by the inconsistent
> treatment of different drafts.
>
> Now, there are valid views that some works would be better  done in a
> transport agnostic way. That kind of speaks in favour of creating  for
> example - a congestion control working group.
>
>
> I can’t agree more.
>
>
> The way I see it, we have following todos -
>
> - there are some issues in the github those need to be addressed (
> https://github.com/martinduke/congestion-control-charter/issues )
> - drive the community discussions so that the ADs can see the interest in
> creating the working group. We can create a new mailing-list for that kind
> of drive and discussions.
> - based on the discussions and interests, give the charter a shape for
> creating the working group and work with the AD to complete the process.
>
> So, basically we need someone who can take over the pen for the proposed
> charter and work with the ADs to finish the process.
>
> Thanks for the detailed info.
>
> Vidhi
>
> On Sep 20, 2022, at 1:47 AM, Zaheduzzaman Sarker <zaheduzzaman.sarker=
> 40ericsson.com@dmarc.ietf.org> wrote:
>
>
>
> On 19 Sep 2022, at 23:38, Vidhi Goel <
> vidhi_goel=40apple.com@dmarc.ietf.org> wrote:
>
> Quite a bit of the TCPM charter text would probably have to be rephrased
> if a new congestion control WG was established. In that case, probably not
> a lot would be left for TCPM as remaining work, as many TCP specs at least
> partly deal with congestion control.
>
>
> Michael, I have the same read and similar thoughts about this.
>
>
> What would be left for TCPM charter if congestion control is moved out -
> shouldn’t be a concern in deciding the best path forward. It is not fair
> that a congestion control related proposal was rejected in QUIC WG citing
> reasons that the work applies to other protocols as well and should be in a
> common WG while TCPM continues to work in this area.
>
>
> I am not sure what you meant by “fair”. "not fair" to whom? in QUIC
> working group the chairs have run a consensus call and that resulted in a
> particular view. At the end the WG decided what to work on and spend their
> time on, given that is possible by the current charter of that WG.
>
> Now, there are valid views that some works would be better  done in a
> transport agnostic way. That kind of speaks in favour of creating  for
> example - a congestion control working group.
>
>
> Martin, Zahed,
> I am not entirely sure who and in what capacity needs to step in to get
> consensus for the new CC WG. If we need to take a vote, we can do that. If
> we need to revise the charter, that can be done via PRs. Can you describe
> what exactly needs to be done to make progress on the new proposed working
> group?
>
>
> The way I see it, we have following todos -
>
> - there are some issues in the github those need to be addressed (
> https://github.com/martinduke/congestion-control-charter/issues )
> - drive the community discussions so that the ADs can see the interest in
> creating the working group. We can create a new mailing-list for that kind
> of drive and discussions.
> - based on the discussions and interests, give the charter a shape for
> creating the working group and work with the AD to complete the process.
>
> So, basically we need someone who can take over the pen for the proposed
> charter and work with the ADs to finish the process.
>
> //Zahed
>
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>