Re: [multipathtcp] [tcpm] TCPM rechartering to add MPTCP maintenance

Gorry Fairhurst <> Wed, 26 February 2020 09:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58E0E3A1192; Wed, 26 Feb 2020 01:39:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hVtG5pzqWWXT; Wed, 26 Feb 2020 01:38:58 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7DA9F3A1193; Wed, 26 Feb 2020 01:38:57 -0800 (PST)
Received: from GF-MacBook-Pro.local ( []) by (Postfix) with ESMTPSA id 5D34C1B00193; Wed, 26 Feb 2020 09:38:51 +0000 (GMT)
To: "Scharf, Michael" <>, tcpm IETF list <>
Cc: "" <>, "" <>
References: <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Wed, 26 Feb 2020 09:38:50 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <>
Subject: Re: [multipathtcp] [tcpm] TCPM rechartering to add MPTCP maintenance
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Feb 2020 09:39:00 -0000

See below:

On 26/02/2020 08:25, Scharf, Michael wrote:
> Hi all,
> As TCPM shall in future maintain MPTCP, we propose a small addition to the TCPM charter.
> The chairs and the responsible ADs believe that MPTCP maintenance and minor MPTCP enhancements would formally be possible with the current TCPM charter text, as MPTCP is a TCP extension. Yet, our preference is to state explicitly that MPTCP maintenance is in scope of TCPM, in particular also to make this transparent to people outside the IETF.
> Therefore, we propose the following small addition to the current TCPM charter (the addition is flagged by <new></new> and the current TCPM charter is fully copied as reference):
> <charter>
> TCP is currently the Internet's predominant transport protocol. TCPM
> is the working group within the IETF that handles small TCP changes,
> i.e., minor extensions to TCP algorithms and protocol mechanisms.
> The TCPM WG serves several purposes:
> * The WG mostly focuses on maintenance issues (e.g., bug fixes) and
> modest changes to the protocol, algorithms, and interfaces that
> maintain TCP's utility.
> * The WG is a venue for moving current TCP specifications along the
> standards track (as community energy is available for such efforts).
> <new>
> * The WG maintains Multipath TCP (MPTCP) and is a home for minor
> MPTCP enhancements including updates to the existing multipath
> congestion control.
> </new>
I think this seems appropriate. (Deciding on new work will require the 
same judgement as other protocol work for non-TCP transports and so the 
new Charter text works for me.)
> * The focus of the working group is TCP. In cases where small
> changes are directly applicable to other transports (e.g., SCTP or
> DCCP), the mappings to other transports may be specified alongside
> that for TCP, but other significant additions and changes to other
> transports are not in scope.
> TCPM also provides a venue for standardization of incremental
> enhancements of TCP's standard congestion control. In addition,
> TCPM may document alternative TCP congestion control algorithms
> that are known to be widely deployed, and that are considered
> safe for large-scale deployment in the Internet. Changes of algorithms
> may require additional review by the IRTF Congestion Control
> Research Group (ICCRG). Fundamental changes to TCP or its congestion
> control algorithms (e.g., departure from loss-based congestion
> control) will be handled by other working groups or will require
> rechartering.
> TCP's congestion control algorithms are the model followed by
> alternate

[GF] can we change /alternate/ to /other IETF/ ... I always though that 
word was a slightly odd choice to me.

> transports (e.g., SCTP or DCCP), which are standardized in
> other working groups, such as the Transport Area WG (tsvwg). In the
> past, the IETF has worked on several documents about algorithms that
> are specified for multiple protocols (e.g., TCP and SCTP) in the
> same document. Which WG shepherds such documents will be determined
> on a case-by-case basis. In any case, the TCPM WG will remain in
> close contact with other relevant WGs working on these protocols to
> ensure openness and stringent review from all angles.
> New TCPM milestones that fall within the scope specified within the
> charter can be added after consensus on acceptance in the working
> group and approval by the responsible Area Director.
> </charter>
> We do not plan any other changes to the TCPM charter, i.e., any MPTCP-related work would follow the process explained in the last sentence of the charter.
> Even if this is only one additional sentence, any re-chartering requires IESG approval. The current plan is to get IESG approval for the new TCPM charter prior to IETF 107. Obviously, the first step is to reach consensus inside TCPM.
> I add the MPTCP WG list in CC. Yet, any discussion of the TCPM charter should take place at
> Please review the charter proposal, and please let us know any comments ASAP.
> Best regards
> Michael
> _______________________________________________
> tcpm mailing list