Re: [multipathtcp] 6824bis -11 review

Rahul Arvind Jadhav <rahul.jadhav@huawei.com> Tue, 31 July 2018 00:21 UTC

Return-Path: <rahul.jadhav@huawei.com>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAA6130EFC for <multipathtcp@ietfa.amsl.com>; Mon, 30 Jul 2018 17:21:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JeGaxqkHKhfR for <multipathtcp@ietfa.amsl.com>; Mon, 30 Jul 2018 17:21:32 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 B6D51130E11 for <multipathtcp@ietf.org>; Mon, 30 Jul 2018 17:21:31 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0F65E7B30575F for <multipathtcp@ietf.org>; Tue, 31 Jul 2018 01:21:27 +0100 (IST)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 31 Jul 2018 01:21:27 +0100
Received: from BLREML503-MBS.china.huawei.com ([169.254.12.219]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0399.000; Tue, 31 Jul 2018 05:51:15 +0530
From: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>
To: Alan Ford <alan.ford@gmail.com>
CC: multipathtcp <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] 6824bis -11 review
Thread-Index: AdQmJDYhfu15UAaeTxKUY+EC058bGgARMycAAAG8pgAAHRK/4ABC3E6AAByWRxA=
Date: Tue, 31 Jul 2018 00:21:14 +0000
Message-ID: <982B626E107E334DBE601D979F31785C5DC6884D@BLREML503-MBS.china.huawei.com>
References: <982B626E107E334DBE601D979F31785C5DC5A15C@BLREML503-MBX.china.huawei.com> <92A53501-4728-4E02-816A-92CEE703AA49@gmail.com> <20754FD9-627F-4AAC-A1B5-6EF2BD09B2AD@gmail.com> <982B626E107E334DBE601D979F31785C5DC5D84B@BLREML503-MBS.china.huawei.com> <AEC8384E-87BB-48F4-9C42-58D2A6FCF251@gmail.com>
In-Reply-To: <AEC8384E-87BB-48F4-9C42-58D2A6FCF251@gmail.com>
Accept-Language: en-IN, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.157.44]
Content-Type: multipart/alternative; boundary="_000_982B626E107E334DBE601D979F31785C5DC6884DBLREML503MBSchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/o2UV67uton-czO--s9OQf4VHnok>
Subject: Re: [multipathtcp] 6824bis -11 review
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=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.

Consider:

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

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 (192.168.0.1) ……   8.9.10.11 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).