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

Fabien Duchêne <fabien.duchene@uclouvain.be> Thu, 28 July 2016 12:13 UTC

Return-Path: <fabien.duchene@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 004D212DF5B for <multipathtcp@ietfa.amsl.com>; Thu, 28 Jul 2016 05:13:35 -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 QNjpcx28qjRo for <multipathtcp@ietfa.amsl.com>; Thu, 28 Jul 2016 05:13:32 -0700 (PDT)
Received: from smtp2.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 A6EC112D180 for <multipathtcp@ietf.org>; Thu, 28 Jul 2016 05:13:32 -0700 (PDT)
Received: from [130.104.228.52] (unknown [130.104.228.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: duchenef@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id CBBE467DB94 for <multipathtcp@ietf.org>; Thu, 28 Jul 2016 14:13:20 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be CBBE467DB94
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1469708001; bh=hD7AlEwnoBpQwFUXG+77XZLoXqx0LHnJ/5Pch5IOMWg=; h=To:From:Subject:Date; b=mjNuMlHfAZXuYOk55ugCvS2hZ43aN4DhDNaE7plz5zrC8usw1I8xG5i9ZBHpwEGdD 6leqouxLlViBT8rq5XhCn9tbMYnhi4PZAuqw5vblf2qndyD/DEfaesDz/sWj8v3kwI tAH8JsC+sz4HZamuJRL1HDvKC56cNBfbl9fW8v+k=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-2
To: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
From: =?UTF-8?Q?Fabien_Duch=c3=aane?= <fabien.duchene@uclouvain.be>
X-Enigmail-Draft-Status: N1110
Message-ID: <5799F82E.2080306@uclouvain.be>
Date: Thu, 28 Jul 2016 14:18:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: CBBE467DB94.AE9A0
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: fabien.duchene@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/L_KV9f8rx_b8hPpss9rGEeGy6eY>
Subject: [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: Thu, 28 Jul 2016 12:13:35 -0000

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