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

Yoshifumi Nishida <nishida@sfc.wide.ad.jp> Sun, 21 August 2016 08:43 UTC

Return-Path: <nishida@sfc.wide.ad.jp>
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 E5E2B12D5CE for <multipathtcp@ietfa.amsl.com>; Sun, 21 Aug 2016 01:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.252
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNeFyx-NEa5j for <multipathtcp@ietfa.amsl.com>; Sun, 21 Aug 2016 01:43:37 -0700 (PDT)
Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A615412D5CA for <multipathtcp@ietf.org>; Sun, 21 Aug 2016 01:43:37 -0700 (PDT)
Received: from mail-ua0-f170.google.com (mail-ua0-f170.google.com [209.85.217.170]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4A27D2782B0 for <multipathtcp@ietf.org>; Sun, 21 Aug 2016 17:43:35 +0900 (JST)
Received: by mail-ua0-f170.google.com with SMTP id 74so144356325uau.0 for <multipathtcp@ietf.org>; Sun, 21 Aug 2016 01:43:35 -0700 (PDT)
X-Gm-Message-State: AEkoousWcWuOY1hlUbtIW7Co2Q8UCPzUUUoSkx60UyDK8YjsBYSgaAuDGIGa9bCY8/oSl9zmQu5tV1e0eDQelw==
X-Received: by 10.159.32.2 with SMTP id 2mr8265434uam.74.1471769013781; Sun, 21 Aug 2016 01:43:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.37.1 with HTTP; Sun, 21 Aug 2016 01:43:33 -0700 (PDT)
In-Reply-To: <29a5965f-4244-22b4-42d3-e334361026af@uclouvain.be>
References: <5799F82E.2080306@uclouvain.be> <CAO249ycXZzXgJm-WMW5_xV-L1o9csu-rDrp8x1n0iiSxEmF3cA@mail.gmail.com> <29a5965f-4244-22b4-42d3-e334361026af@uclouvain.be>
From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Sun, 21 Aug 2016 01:43:33 -0700
X-Gmail-Original-Message-ID: <CAO249yf-K4pTRzDTHA7KGSjQNvpyf4z1hLLvu-POoSvrjwe+1w@mail.gmail.com>
Message-ID: <CAO249yf-K4pTRzDTHA7KGSjQNvpyf4z1hLLvu-POoSvrjwe+1w@mail.gmail.com>
To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Content-Type: multipart/alternative; boundary=94eb2c04c796420bb5053a90eda8
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/o4bbj3FW2_gEoMO6DzHIDs3igAc>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Multipath TCP Address advertisement 1/5 - Load Balancing
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 21 Aug 2016 08:43:40 -0000

Hi Olivier,

On Thu, Aug 18, 2016 at 1:18 AM, Olivier Bonaventure <Olivier.Bonaventure@
uclouvain.be> 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
preference.


> 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.

--
Yoshi