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
- Re: [multipathtcp] Multipath TCP Address advertis… Olivier Bonaventure
- Re: [multipathtcp] Multipath TCP Address advertis… Yoshifumi Nishida
- Re: [multipathtcp] Multipath TCP Address advertis… Christoph Paasch
- Re: [multipathtcp] Multipath TCP Address advertis… philip.eardley
- Re: [multipathtcp] Multipath TCP Address advertis… Alan Ford
- [multipathtcp] Multipath TCP Address advertisemen… Fabien Duchêne
- Re: [multipathtcp] Multipath TCP Address advertis… Yoshifumi Nishida