Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-12.txt

Alan Ford <> Mon, 08 October 2018 20:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2EC5130EE9 for <>; Mon, 8 Oct 2018 13:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qhnlCRbbnlDu for <>; Mon, 8 Oct 2018 13:58:33 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BE706130E96 for <>; Mon, 8 Oct 2018 13:58:32 -0700 (PDT)
Received: by with SMTP id y71-v6so19111858lje.9 for <>; Mon, 08 Oct 2018 13:58:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=00miwJ1dEnmdAbFNHc9Rnp62Zm3pZZpfExo++q+Z9pY=; b=DE+DAWbs7+GS1pam0n77XyAwn+2FZT/ztuwusEzsfh2GnRPcQD24w8J9fegCW9TBdN DD9gUS201JPHNLe9j+KE/us6fxAEMG2GetRLZA4fjzS/pLnwbJKVvPN+JONPXWpVijFL 7OC5uvcpbdrAmiykJTISxFGNMtMHZp+ruz+WY7fu+jkkKHlcAVpHpUsVkpaPiDqBavsu VZ/erhV6SN0M81TnlC5Y15OqvnJwKvqSpS0j6qa88OUsxYhul5Rs2HNOW5ZBPfmFl5V1 9wpfi4El6TqWO9VABlnNXw4U/WiNZvXSFDloo2tGRCxwSFcy1ewxldl2yw1JUNtXthZk GRcQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=00miwJ1dEnmdAbFNHc9Rnp62Zm3pZZpfExo++q+Z9pY=; b=GVJ4kOgZIcvwv2xl/3kVA58cVqEeCFSXnd02u/vIjyBToi3NJy74MOF6P90gTGiDO6 SNFHz1Az4Xm9y1vIAAEQShZ0Vh40aWBuEQq1BRiibqLK64x3VjFK1qS8BkrA+hMVBsbj hf56NEV10nmbPTip/KU7gaCMOeTGYOMD8gH5TvmggVK3umhd8goEkUUgKbnnSzMS0QeL 6/pYR+mS0BZYho5ErqIerQglCY58sxnI19sr+0e6k0J2wIUiwX/C8xAextSpOQK8Q/27 6YLKXkoRtOtglhx3yQSiUMQw+uK9EHp9m0/V7DnOUZNbxlRLXHDgr0ibXe5Q3MCI9XKP lfYg==
X-Gm-Message-State: ABuFfoiByW+D5ssV8DUhS7ecXOp/lS1xkOGp9nKh4lHHX5o/Q7q61ilv n72bi/tA9LjBhWp18qRND1JQFSfm
X-Google-Smtp-Source: ACcGV63bopt/VYyOUlu6qwBr8t02pqv33DErXcRtdLj2HFfDzA+me5FoxQJVNzIDXMbv31TGT9uAoA==
X-Received: by 2002:a2e:1b9c:: with SMTP id c28-v6mr15455950ljf.73.1539032310857; Mon, 08 Oct 2018 13:58:30 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id g14-v6sm4204083lja.96.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Oct 2018 13:58:30 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alan Ford <>
In-Reply-To: <>
Date: Mon, 08 Oct 2018 21:58:28 +0100
Cc: multipathtcp <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <>
To: Rahul Arvind Jadhav <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-12.txt
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: Mon, 08 Oct 2018 20:58:37 -0000

Hi Rahul,

Thank you for double-checking, it is much appreciated!

1. Fixing text on Address ID, I hope the following is acceptable:

        The MP_JOIN option includes an "Address ID".  This is an identifier
        generated by the sender of the option, used to identify the source address 
        of this packet, even if the IP header has been changed in transit by a middlebox.
        The numeric value of this field is generated by the sender and must map uniquely 
        to a source IP address for the sending host.

3. It was left for further comment, and no further comment was forthcoming. I personally am not sure of any need to add a MP_TCPRST here since both ends should know why the subflow is being torn down - one sent the REMOVE_ADDR, and the other acted on it. If the REMOVE_ADDR was spoofed, the safety nets should mean the subflow is not torn down. So I see no benefit in signalling the reason here.

4. At the first appearance of “make-before-break", we can add:

	, where new subflows are added before the previously used ones are closed


> On 8 Oct 2018, at 14:49, Rahul Arvind Jadhav <> wrote:
> Hello Alan,
> Most of my comments from [1] are handled. Thank you.
> Some comments based on the updated text:
> 1. Accepted comment#8 in [1] does not seem to be handled. I think it is important to be clarified that the value of "Address ID" has significance not only within a single connection but also only on the peer who generates the ID. Thus it is possible for peers to generate the same Address ID within a connection as well.
> 2. Thank you for removing the term "passive opener" throughout the document. The new text is much easier to understand.
> 3. Looks like comment#2 for explicitly mentioning the Reason Code for MP_TCPRST was not accepted. I understand we haven’t really got any feedback from the WG on this point but then I feel it is necessary to do this.
> 4. "make-before-break session" term is introduced after rewording ... I feel this term should be explained in terminology section.
> Best,
> Rahul
> [1]
>> -----Original Message-----
>> From: multipathtcp [] On Behalf Of
>> Alan Ford
>> Sent: 03 October 2018 19:56
>> To: multipathtcp <>
>> Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-rfc6824bis-12.txt
>> Hi all,
>> I believe this new version addresses all last call/review comments we
>> received for rfc6824bis, with the exception of adding a possible “changes
>> since RFC6824” section.
>> Could all reviewers please check this new version and ensure we have
>> handled your review comments appropriately?
>> Many thanks,
>> Alan
>>> On 3 Oct 2018, at 15:23, wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>> This draft is a work item of the Multipath TCP WG of the IETF.
>>>       Title           : TCP Extensions for Multipath Operation with Multiple
>> Addresses
>>>       Authors         : Alan Ford
>>>                         Costin Raiciu
>>>                         Mark Handley
>>>                         Olivier Bonaventure
>>>                         Christoph Paasch
>>> 	Filename        : draft-ietf-mptcp-rfc6824bis-12.txt
>>> 	Pages           : 80
>>> 	Date            : 2018-10-03
>>> Abstract:
>>>  TCP/IP communication is currently restricted to a single path per
>>>  connection, yet multiple paths often exist between peers.  The
>>>  simultaneous use of these multiple paths for a TCP/IP session would
>>>  improve resource usage within the network and, thus, improve user
>>>  experience through higher throughput and improved resilience to
>>>  network failure.
>>>  Multipath TCP provides the ability to simultaneously use multiple
>>>  paths between peers.  This document presents a set of extensions to
>>>  traditional TCP to support multipath operation.  The protocol offers
>>>  the same type of service to applications as TCP (i.e., reliable
>>>  bytestream), and it provides the components necessary to establish
>>>  and use multiple TCP flows across potentially disjoint paths.
>>>  This document specifies v1 of Multipath TCP, obsoleting v0 as
>>>  specified in RFC6824 [RFC6824] through clarifications and
>>>  modifications primarily driven by deployment experience.
>>> The IETF datatracker status page for this draft is:
>>> There are also htmlized versions available at:
>>> A diff from the previous version is available at:
>>> Please note that it may take a couple of minutes from the time of
>>> submission until the htmlized version and diff are available at
>>> Internet-Drafts are also available by anonymous FTP at:
>>> _______________________________________________
>>> multipathtcp mailing list
>> _______________________________________________
>> multipathtcp mailing list