Re: [multipathtcp] 6824bis -11 review

Rahul Arvind Jadhav <> Tue, 31 July 2018 00:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5BAA6130EFC for <>; Mon, 30 Jul 2018 17:21:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JeGaxqkHKhfR for <>; Mon, 30 Jul 2018 17:21:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B6D51130E11 for <>; Mon, 30 Jul 2018 17:21:31 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 0F65E7B30575F for <>; Tue, 31 Jul 2018 01:21:27 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 31 Jul 2018 01:21:27 +0100
Received: from ([]) by ([]) with mapi id 14.03.0399.000; Tue, 31 Jul 2018 05:51:15 +0530
From: Rahul Arvind Jadhav <>
To: Alan Ford <>
CC: multipathtcp <>
Thread-Topic: [multipathtcp] 6824bis -11 review
Thread-Index: AdQmJDYhfu15UAaeTxKUY+EC058bGgARMycAAAG8pgAAHRK/4ABC3E6AAByWRxA=
Date: Tue, 31 Jul 2018 00:21:14 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-IN, zh-CN, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DC6884DBLREML503MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [multipathtcp] 6824bis -11 review
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Jul 2018 00:21:33 -0000

c) sending a new ADD_ADDR with same ID + address and different port is fine
[RJ] again this is what the text already says, but I’m not still clear about this. Why ID + address has to match? Only ID should be enough.


a) ADD_ADDR comes in saying ID=2, addr= (private)
b) MP_JOIN comes in saying ID=2, addr= (public)
c) ADD_ADDR comes in saying ID=2, addr=

What does this mean? Is (c) an implicit REMOVE+ADD? And thus does this mean the subflow created in (b) is now no longer valid?

By keeping the address / ID mapping, if an address is lost, then so is the subflow.

[RJ2] Rather than viewing ( c) as an implicit REMOVE+ADD, can we see it as an UPDATE? Because ID remains same. Subflow created in (b) remains valid (not sure if I’m missing anything here, I see no reason to lose this subflow).
In step ( c), the receiver can override Address field in context to ID=2 to the new addr ( …… is kept separately as the learnt actual rcvd IP (from MP_JOIN) in the same context ID=2. We have to agree that an implementation needs to maintain this IP separately in context to ID=2 anyways.
So if we do an explicit REMOVE+ADD, the end result is the same as this UPDATE (but with much less overhead & impl ease).