Re: [multipathtcp] Multipath TCP Address advertisement 1/5 - Load Balancing

Yoshifumi Nishida <> Sun, 21 August 2016 08:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E5E2B12D5CE for <>; Sun, 21 Aug 2016 01:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.252
X-Spam-Status: No, score=0.252 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kNeFyx-NEa5j for <>; Sun, 21 Aug 2016 01:43:37 -0700 (PDT)
Received: from ( [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A615412D5CA for <>; Sun, 21 Aug 2016 01:43:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 4A27D2782B0 for <>; Sun, 21 Aug 2016 17:43:35 +0900 (JST)
Received: by with SMTP id 74so144356325uau.0 for <>; Sun, 21 Aug 2016 01:43:35 -0700 (PDT)
X-Gm-Message-State: AEkoousWcWuOY1hlUbtIW7Co2Q8UCPzUUUoSkx60UyDK8YjsBYSgaAuDGIGa9bCY8/oSl9zmQu5tV1e0eDQelw==
X-Received: by with SMTP id 2mr8265434uam.74.1471769013781; Sun, 21 Aug 2016 01:43:33 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 21 Aug 2016 01:43:33 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
From: Yoshifumi Nishida <>
Date: Sun, 21 Aug 2016 01:43:33 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Olivier Bonaventure <>
Content-Type: multipart/alternative; boundary=94eb2c04c796420bb5053a90eda8
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] Multipath TCP Address advertisement 1/5 - Load Balancing
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 21 Aug 2016 08:43:40 -0000

Hi Olivier,

On Thu, Aug 18, 2016 at 1:18 AM, Olivier Bonaventure <Olivier.Bonaventure@> wrote:

> Yoshifumi,
>>     There are two use cases for this flag :
>>     - servers behind a load balancer can use this flag in the SYN+ACK to
>>     indicate that the IP address of the load balancer should not be used
>> to
>>     establish subflows. Those servers will typically announce one or more
>>     other addresses with the ADD_ADDR option.
>>     - clients behind firewalls or NAT can use this flag in the SYN. If set
>>     in the SYN, the flag MUST also be set in the third ACK to support
>>     stateless servers.
>> I basically agree with "don't try to establish subflows with this"
>> feature.
>> But, I am wondering if we can use MP_PRIO for this. (I also think it's
>> fine to use MP_CAPABLE as well if needed)
> I think MP_CAPABLE is required for the addresses of the initial subflow.
> You cannot wait for an additional message (MP_PRIO or whatever) to
> determine whether you can use this address or not for subsequence subflows.
> This would delay the establishment of subflows.

Right. If we care about the delay rather than conserving a flag, I think we
should use MP_CAPABLE.
But it seems that opening a subflow immediately is a bit orthogonal to
what's written in 3.10.2.
This might not be a major issue, though.

> If we use this feature in MP_CAPBLE, we can only use this feature in the
>> first subflow.
>> If we use MP_PRIO, we can apply this feature to any subflows.
>> In addition, if the node want to change the status for some reasons, it
>> can send another MP_PRIO to update it.
> If you used the bit in the MP_CAPABLE option to indicate that the address
> of the initial subflow should not be used and you later change your mind,
> you can simply send an ADD_ADDR option that advertises the same address as
> the initial subflow.

I agree sending ADD_ADDR is another way for this. But, in my view,
 ADD_ADDR seems to be meant for notifying new addr and MP_PRIO is meant for
changing the attribute of the addr. Although this might be just my personal

> But this raises another question concerning the utilisation of addresses
> to create subflows. Consider two dual-homed hosts.
> C ----- S
> +-------+
> C has two addresses, C1 and C2. S also has addresses S1 and S2. C does not
> accept subflows on C1 and C2.
> The initial subflow is C1->S1. Neither C1 nor S1 should be used to
> establish subflows. S advertises S2 through an ADD_ADDR option.
> At this point, C creates a new subflow C2->S2. S learns that address C2 is
> also available. What should S do with the address C2 that it has learned ?
> Can this address be used to establish additional subflows ?
> Should we add the same bit in the MP_JOIN option as in the MP_CAPABLE
> option to indicate that C2 should not be used to create subflows or should
> we simply say that only addresses advertised with ADD_ADDR can be used to
> create subflows ?

I personally think the spec doesn't need to limit the candidate addresses
for subflows. I think a peer should be able to try any possible addresses
as long as its local policy allows.
So, I agree using a bit in MP_JOIN as long as we care about the delay
rather than conserving a flag.