Re: [multipathtcp] AD review is coming

Mirja Kuehlewind <> Tue, 16 April 2019 11:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C75191205D5; Tue, 16 Apr 2019 04:17:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wuqCB76nKL9A; Tue, 16 Apr 2019 04:17:27 -0700 (PDT)
Received: from ( [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 600CC1204AA; Tue, 16 Apr 2019 04:17:27 -0700 (PDT)
Received: from [] (helo=[]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hGM5b-0007Mk-Dc; Tue, 16 Apr 2019 13:17:23 +0200
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Mirja Kuehlewind <>
In-Reply-To: <>
Date: Tue, 16 Apr 2019 13:17:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Alan Ford <>
X-Mailer: Apple Mail (2.3445.104.8)
X-HE-SMSGID: 1hGM5b-0007Mk-Dc
Archived-At: <>
Subject: Re: [multipathtcp] AD review is coming
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: Tue, 16 Apr 2019 11:17:30 -0000

Hi Alan,

Yes, I was looking also for eventually a tiny update to the doc (while it would be most important to mention this in the write-up). I think the one thing that could be added below, is one more sentence or maybe even halve a sentence saying that this fallback to plain TCP (instead of v0) is okay, as general deployment is low and there is also an expectation that server get updated first or entities using MPTCP today actually have some control to update both client and server. Or whatever you think is right to say. So the question to answers is why is it okay that fallback is to plain TCP instead of v0…?


> On 15. Apr 2019, at 18:55, Alan Ford <> wrote:
> Hi Mirja,
> To be clear, you are looking for some rationale in the draft text as well? The technical discussion of the fallback process is given in Section 3.1:
>    The MP_CAPABLE exchange in this specification (v1) is different to
>    that specified in v0 [RFC6824].  If a host supports multiple versions
>    of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the
>    highest version number it supports.  In return, in its MP_CAPABLE
>    option, the receiver will signal the version number it wishes to use,
>    which MUST be equal to or lower than the version number indicated in
>    the initial MP_CAPABLE.  There is a caveat though with respect to
>    this version negotiation with old listeners that only support v0.  A
>    listener that supports v0 expects that the MP_CAPABLE option in the
>    SYN-segment includes the initiator's key.  If the initiator however
>    already upgraded to v1, it won't include the key in the SYN-segment.
>    Thus, the listener will ignore the MP_CAPABLE of this SYN-segment and
>    reply with a SYN/ACK that does not include an MP_CAPABLE, thus
>    leading to a fallback to regular TCP.  An initiator MAY cache this
>    information about a peer and for future connections, MAY choose to
>    attempt using MPTCP v0, if supported, before recording the host as
>    not supporting MPTCP.
> But you would like to see some discussion mentioning the migration from Experimental to Proposed Standard? And the benefits it brings? Would that cover it?
> Many thanks,
> Alan
>> On 12 Apr 2019, at 17:40, Mirja Kuehlewind <> wrote:
>> Hi authors, hi shepherd/Phil,
>> Just wanted to quickly let you know that I’ve started the IETF last call just now in order to hopefully get this document on the telechat in 3 weeks. 
>> I’ve not finished my AD review completely but I am nearly done and convinced that this doc is ready to start IETF last call. So far I have only some editorial or smallish comments and nits which I will send in detail beginning of next week and can be address during or after IETF last call.
>> Only one request for now (mostly with an eye on the IESG evaluation): The draft says that changes are made which are not backward compatible (see sec 3.1). That’s fine, however, it would be good to also explain a little bit in the draft as well as in the shepherd write up (!) why this is okay. My understanding is that in case of a v0 server the connection will “just" fall-back to non-MPTCP capable and that this is acceptable in current deployment situation. Please confirm and at least update the write-up accordingly as soon as possible!
>> Thanks!
>> Mirja