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

Vidhi Goel <vidhi_goel@apple.com> Tue, 20 September 2022 18:54 UTC

Return-Path: <vidhi_goel@apple.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 D9A61C14F74E for <tcpm@ietfa.amsl.com>; Tue, 20 Sep 2022 11:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.681
X-Spam-Level:
X-Spam-Status: No, score=-2.681 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 x7O8fbyb0k03 for <tcpm@ietfa.amsl.com>; Tue, 20 Sep 2022 11:54:44 -0700 (PDT)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E2A2C14F738 for <tcpm@ietf.org>; Tue, 20 Sep 2022 11:49:26 -0700 (PDT)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.42/8.16.0.42) with SMTP id 28KIi385017757; Tue, 20 Sep 2022 11:49:18 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=DCvI3NhrvBUmfKmjtmir3NrySZMkfompIzz3qf83ciw=; b=CoNzjFjWaTVPpjBubwYNisDzAcOM4w3pwe4Vu+qDllSRQfukQm0ETjQV2LLYut0lFdM6 SbBUqknESHyitW3Y4x1Pd7yk0E6KeBZNMO8QGJaEpdJGrMhPBGrQYVhNvYDFvE3jQkuS RiuYT3Q89JFwCkgUyoOKKHjON4n7WE/1KKFelk9bofcUnhodcHU4MDEw/8+7ZZzpIHVv 5UPtZYxQHvJWyFzkAT6r2aKNOuKMz4wvW1ULe7BkWsFHwnwEPsYjYdH5OAwOQevnID82 DLb+o7pTzYj5xFWlpcjnnyS+TWMu4S6Gdlagu7mnR9bvjIyKkY42AEk0F0s+owwcBGWo Fg==
Received: from rn-mailsvcp-mta-lapp04.rno.apple.com (rn-mailsvcp-mta-lapp04.rno.apple.com [10.225.203.152]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 3jnd7wb57e-5 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 20 Sep 2022 11:49:18 -0700
Received: from rn-mailsvcp-policy-lapp01.rno.apple.com (rn-mailsvcp-policy-lapp01.rno.apple.com [17.179.253.18]) by rn-mailsvcp-mta-lapp04.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) with ESMTPS id <0RII00NHVUY5GC50@rn-mailsvcp-mta-lapp04.rno.apple.com>; Tue, 20 Sep 2022 11:49:17 -0700 (PDT)
Received: from process_milters-daemon.rn-mailsvcp-policy-lapp01.rno.apple.com by rn-mailsvcp-policy-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) id <0RII00Q00UTPSA00@rn-mailsvcp-policy-lapp01.rno.apple.com>; Tue, 20 Sep 2022 11:49:17 -0700 (PDT)
X-Va-A:
X-Va-T-CD: 9da32e1d4d62bbc5b549aff1ee920799
X-Va-E-CD: 7d64ad10afa0d4a1415df3723edf5c17
X-Va-R-CD: e47ab79853208fdb4fa1490d42dc9d7c
X-Va-CD: 0
X-Va-ID: 3ee30062-aab6-4b6a-a654-114583805c71
X-V-A:
X-V-T-CD: 9da32e1d4d62bbc5b549aff1ee920799
X-V-E-CD: 7d64ad10afa0d4a1415df3723edf5c17
X-V-R-CD: e47ab79853208fdb4fa1490d42dc9d7c
X-V-CD: 0
X-V-ID: 9a7407ba-85d5-4bf8-9f59-94fb15821bc9
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.528, 18.0.895 definitions=2022-09-20_08:2022-09-20, 2022-09-20 signatures=0
Received: from smtpclient.apple (unknown [17.11.145.158]) by rn-mailsvcp-policy-lapp01.rno.apple.com (Oracle Communications Messaging Server 8.1.0.19.20220711 64bit (built Jul 11 2022)) with ESMTPSA id <0RII00R53UY51T00@rn-mailsvcp-policy-lapp01.rno.apple.com>; Tue, 20 Sep 2022 11:49:17 -0700 (PDT)
From: Vidhi Goel <vidhi_goel@apple.com>
Message-id: <10BE0012-DB95-44CF-9E30-232E7043901B@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_D6EB0ECB-5B07-4529-B96A-CEEDB811A857"
MIME-version: 1.0 (Mac OS X Mail 16.0 \(3728.0.5\))
Date: Tue, 20 Sep 2022 11:49:06 -0700
In-reply-to: <A02EDDBB-B7BB-4DCD-8D7A-C41F89EA72EA@ericsson.com>
Cc: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, "tcpm@ietf.org Extensions" <tcpm@ietf.org>, Christian Huitema <huitema@huitema.net>
To: Zaheduzzaman Sarker <zaheduzzaman.sarker=40ericsson.com@dmarc.ietf.org>
References: <8886433A-25A4-428D-94F1-E2CFFF02E712@ericsson.com> <E47FA00A-699E-4BAD-A18A-8F6792F1565B@apple.com> <A02EDDBB-B7BB-4DCD-8D7A-C41F89EA72EA@ericsson.com>
X-Mailer: Apple Mail (2.3728.0.5)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.528, 18.0.895 definitions=2022-09-20_08:2022-09-20, 2022-09-20 signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/Qb7EFpKAWyP0cQpSaIPqEC20Ytw>
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: Tue, 20 Sep 2022 18:54:45 -0000

> 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 <mailto: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
>  
>