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

<philip.eardley@bt.com> Tue, 02 August 2016 14:36 UTC

Return-Path: <philip.eardley@bt.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 57DD912D77F for <multipathtcp@ietfa.amsl.com>; Tue, 2 Aug 2016 07:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.888
X-Spam-Level:
X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.287, 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 fm4rHA7070jY for <multipathtcp@ietfa.amsl.com>; Tue, 2 Aug 2016 07:36:23 -0700 (PDT)
Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7832C12D77B for <multipathtcp@ietf.org>; Tue, 2 Aug 2016 07:36:23 -0700 (PDT)
Received: from E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 2 Aug 2016 15:36:21 +0100
Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 2 Aug 2016 15:36:21 +0100
Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 2 Aug 2016 15:36:20 +0100
Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1178.000; Tue, 2 Aug 2016 15:36:20 +0100
From: <philip.eardley@bt.com>
To: <alan.ford@gmail.com>, <fabien.duchene@uclouvain.be>
Thread-Topic: [multipathtcp] Multipath TCP Address advertisement 1/5 - Load Balancing
Thread-Index: AQHR7MXD8pfASVsNlEyl+kyMfcwdmKA1vNmw
Date: Tue, 2 Aug 2016 14:36:20 +0000
Message-ID: <91956a8b978442f39763bc4dde4afc00@rew09926dag03b.domain1.systemhost.net>
References: <5799F82E.2080306@uclouvain.be> <D1D81B29-141B-46E8-ADE0-E2FF67BFAAD8@gmail.com>
In-Reply-To: <D1D81B29-141B-46E8-ADE0-E2FF67BFAAD8@gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.216.161.25]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/zW4TwdGQaSq9IGxwCgGopy1B_qc>
Cc: 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: Tue, 02 Aug 2016 14:36:28 -0000

Makes sense to me
phil


-----Original Message-----
From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Alan Ford
Sent: 02 August 2016 14:57
To: Fabien Duchêne <fabien.duchene@uclouvain.be>
Cc: multipathtcp@ietf.org
Subject: Re: [multipathtcp] Multipath TCP Address advertisement 1/5 - Load Balancing

Hi Fabien, all,

I support the addition of this flag - it seems useful for the two use cases you have identified below, could be added at little implementation and spec cost, and could potentially find new useful purposes in the future.

I look forward to mails 2-5 of this series ;-)

Regards,
Alan

> On 28 Jul 2016, at 13:18, Fabien Duchêne <fabien.duchene@uclouvain.be> wrote:
> 
> Hello,
> 
> As agreed in Berlin during IETF96, I'm sending a series of emails to 
> discuss the different contributions proposed 
> inhttps://datatracker.ietf.org/doc/draft-duchene-mptcp-add-addr/
> 
> To allow Multipath TCP to operate for servers residing behind 
> unmodified layer 4 load balancers we propose to define the "B" flag in 
> the MP_CAPABLE option.
> 
> This flag can only be used during the three-way handshake. When this 
> flag is set, it indicates that the source IP address of the segment 
> containing this flag does not accept the establishment of additional 
> subflows for this connection. Otherwise, the source IP address of this 
> segment can be used as destination address to create additional subflows.
> 
> 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.
> 
> We would appreciate your feedback on this proposition.
> 
> Thanks!
> 
> Fabien
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp

_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp