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

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Thu, 18 August 2016 08:18 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
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 5036112B018 for <multipathtcp@ietfa.amsl.com>; Thu, 18 Aug 2016 01:18:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
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 Ln_v2t34G7_k for <multipathtcp@ietfa.amsl.com>; Thu, 18 Aug 2016 01:18:27 -0700 (PDT)
Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDCB127077 for <multipathtcp@ietf.org>; Thu, 18 Aug 2016 01:18:26 -0700 (PDT)
Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id A674A67DAA1; Thu, 18 Aug 2016 10:18:18 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp5.sgsi.ucl.ac.be A674A67DAA1
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1471508298; bh=M4Qo4AZF1PYbJhNfovprIsVs6APOX3kkLbA3RSUiLGY=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=QFNS9uL8QAr2rFQ3BwQLj+aOW/4i5WqKVdt3MZb5vXCE4ijdlLIRExdJHnEKPbvp5 ITE0DUav25CjbSdXJ6VkfAyOlW9Mi1AFU9vm/uzgKBkwl077BANOpQpq2OZLTHmHcV /IrYyDBcmB2TQbIUf5fR47OcRNum66WJGjLA724o=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-5
References: <5799F82E.2080306@uclouvain.be> <CAO249ycXZzXgJm-WMW5_xV-L1o9csu-rDrp8x1n0iiSxEmF3cA@mail.gmail.com>
To: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, =?UTF-8?Q?Fabien_Duch=c3=aane?= <fabien.duchene@uclouvain.be>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <29a5965f-4244-22b4-42d3-e334361026af@uclouvain.be>
Date: Thu, 18 Aug 2016 10:18:19 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <CAO249ycXZzXgJm-WMW5_xV-L1o9csu-rDrp8x1n0iiSxEmF3cA@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: A674A67DAA1.A5BDB
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/jUKr4vimFEcONZr-JIL_d2ruMYg>
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
Reply-To: Olivier.Bonaventure@uclouvain.be
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: Thu, 18 Aug 2016 08:18:29 -0000

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.

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

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 ?


Olivier