IETF Logo Mail Archive

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

Christoph Paasch <cpaasch@apple.com> Thu, 04 August 2016 03:53 UTC

Return-Path: <cpaasch@apple.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 AB59A12D0A4 for <multipathtcp@ietfa.amsl.com>; Wed, 3 Aug 2016 20:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.589
X-Spam-Level:
X-Spam-Status: No, score=-5.589 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, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
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 LydNGy62CQHW for <multipathtcp@ietfa.amsl.com>; Wed, 3 Aug 2016 20:53:46 -0700 (PDT)
Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E9F12B03D for <multipathtcp@ietf.org>; Wed, 3 Aug 2016 20:53:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1470282825; x=2334196425; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BKXu03lBZP21Z+7NhkzPoR3SfqV582XhcmtUZGgFq7Y=; b=Mk96kN4jUprxZbDKuzwLBpl364Y9AYRRJCJeGKlNF8Rm1UeX+ag/JB5W7ajID+ZN JY8eaqwUX/MQv/4Y7bMgOTkIQLpvnT/y+1qbRFGf1c/l/ricx0Z+/aWR651hdIhE z1dYA5mgh/P9aoHUpoVGe2BqQz7IzDqiv354r7/RdAVFmWHVMWqe6NnWB7bdD0vf WTgL/34iKSCnY+2sh9jLbfffgpfA1Td9z4u0bW8Ylx1hSWUCpGmALGUJ8zDobJsc tOtQJwNT4WY3NTzGNymN5lY3IogUJ3HJPm8Joavdta3fPtM7fvFME/JtB6PS32yb a39PZdanjrEnJ+ocW9w6cQ==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 7B.F8.07433.94CB2A75; Wed, 3 Aug 2016 20:53:45 -0700 (PDT)
X-AuditID: 11973e12-f79b16d000001d09-a6-57a2bc491cc4
Received: from chive.apple.com (chive.apple.com [17.128.115.15]) by relay6.apple.com (Apple SCV relay) with SMTP id BD.51.31551.94CB2A75; Wed, 3 Aug 2016 20:53:45 -0700 (PDT)
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from [17.150.214.105] (unknown [17.150.214.105]) by chive.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built May 17 2016)) with ESMTPSA id <0OBD00INO9HLPY10@chive.apple.com>; Wed, 03 Aug 2016 20:53:45 -0700 (PDT)
Sender: cpaasch@apple.com
From: Christoph Paasch <cpaasch@apple.com>
In-reply-to: <5799F82E.2080306@uclouvain.be>
Date: Wed, 03 Aug 2016 20:53:45 -0700
Content-transfer-encoding: quoted-printable
Message-id: <D892FC5E-CE07-4B7A-A918-759AFD6A0BC5@apple.com>
References: <5799F82E.2080306@uclouvain.be>
To: =?utf-8?Q?Fabien_Duch=C3=AAne?= <fabien.duchene@uclouvain.be>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUi2FAYpeu5Z1G4waHfZhb3PkxjtPi8+jqb A5PHkiU/mTxeHfvOEsAUxWWTkpqTWZZapG+XwJXxbtF19oIW3orGdUENjIe4uhg5OSQETCQ+ zjnIBmGLSVy4tx7I5uIQEtjLKHH37no2mKIrkyYyQSQ2Mkrc6ZsOluAVEJT4MfkeSxcjBwez gLrElCm5EDW/GCXenXnLDlIjLCAp0X3nDjOEHSaxd/JRVhCbTUBL4u3tdjCbU0BH4sPCPSwg NouAqsTieVMYIWYaS0yZaQQSZhbQlnjy7gIrxFobiVmTH4LZQkDx9bM3soKUiwg4SmyYFA9x sqzEk5OLWCDsDWwSx/dJTGAUmYXk6FkIR89CsmABI/MqRqHcxMwc3cw8E73EgoKcVL3k/NxN jKBQn24ntIPx1CqrQ4wCHIxKPLwbJBeFC7EmlhVX5h5ilOZgURLn9T61IFxIID2xJDU7NbUg tSi+qDQntfgQIxMHp1QDY+lrf1ehwxx+Rs/vTTbxXrTsweFFr7a62XgVcO3LbojZYyI3K2qK vGfSK6H2Hs4VR7/uE3Nscj+6Zo5e1v6UV0F+IgKzZ2x5cEo+e2WNeGfvQ/eOJr+FmZsayyZ/ O39V6MDE3TnN/sqWTBVzcp+fk+fon2EQ2KIyT/SQeMtJ74bwt7V37s1TVmIpzkg01GIuKk4E ALzxF3lWAgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUi2FDMr+u5Z1G4wdqVJhb3PkxjtPi8+jqb A5PHkiU/mTxeHfvOEsAUxWWTkpqTWZZapG+XwJXxbtF19oIW3orGdUENjIe4uhg5OSQETCSu TJrIBGGLSVy4t56ti5GLQ0hgI6PEnb7pbCAJXgFBiR+T77F0MXJwMAuoS0yZkgtR84tR4t2Z t+wgNcICkhLdd+4wQ9hhEnsnH2UFsdkEtCTe3m4HszkFdCQ+LNzDAmKzCKhKLJ43hRFiprHE lJlGIGFmAW2JJ+8usEKstZGYNfkhmC0EFF8/eyMrSLmIgKPEhknxECfLSjw5uYhlAqPgLCSH zkI4dBaSoQsYmVcxChSl5iRWmuklFhTkpOol5+duYgQHZ2HUDsaG5VaHGAU4GJV4eDdILgoX Yk0sK67MPcQowcGsJMI7dydQiDclsbIqtSg/vqg0J7X4EGMy0CcTmaVEk/OBkZNXEm9oYmJg YmxsZmxsbmJOmrCSOG/C8fnhQgLpiSWp2ampBalFMFuYODilGhjLzm5f2cJ/xiOh5PjrsK0N KlsfsVrbB0tYuwt5BbaxTJ1jdCeiMj21ray2/fWhU46f/dvYHrzYEZT0vm4r58YjLOs2nJg7 3+mW751t6U9O6Ho0ffppIfuG4ajA12PaJ30rpGYv6Q8KuHQgZ2/V7dcKTEke+Sz7IpWWfeB9 tybrVELwoUvP8y2VWIozEg21mIuKEwEYALaskgIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/k8cEjz2aLorqMdETc0kH2gzA_BE>
Cc: MultiPath TCP - IETF WG <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: Thu, 04 Aug 2016 03:53:48 -0000

> On Jul 28, 2016, at 5:18 AM, 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.

I also support the addition of the B-flag.


Christoph


> 
> Thanks!
> 
> Fabien
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp

v2.1.17 | Report a Bug | By Email