Re: [multipathtcp] Multipath TCP Address advertisement 2/5 - Reliability
Christoph Paasch <cpaasch@apple.com> Thu, 04 August 2016 03:52 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 B51EF12D1B2
for <multipathtcp@ietfa.amsl.com>; Wed, 3 Aug 2016 20:52:42 -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 G4O1r-QRoUf9 for <multipathtcp@ietfa.amsl.com>;
Wed, 3 Aug 2016 20:52:41 -0700 (PDT)
Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 3E45312D16F
for <multipathtcp@ietf.org>; Wed, 3 Aug 2016 20:52:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s;
c=relaxed/simple;
q=dns/txt; i=@apple.com; t=1470282761; x=2334196361;
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=ddFDZwtrG1Dgwokm9NUAxz+bW9jfVD92ktPke76j6bA=;
b=4IMuPuUYZ2CxEIi5ES9kfXEJ+RRkP5qbmj9Bhy6+qOrYKoUYgaE2oaWF/lUVYoTt
A2N39VNFZMHZkynalorPJ8N+zBj2XaZeWQGDTLzTt2JzO/UyMBeVSyd6va/v8SbD
aepnLgubUW/kM+FykrQxGTKrfSyJ6wbjPc9RH+RL6iQG1rvwTc+cu0qVnlFjAjTS
otIqcN/YW9yNp2CLWS4dBoffGRdA7+5r+5YM1jNkTJdMZZ4QZmbAL5Utfi/T07ww
tw19oyekwPxs8kd9FifWKCoaeUW/MtlmrvrVlIVcQftbmFISuhWZA6MYBfuL6lfr
5dMQuKRElUTR/piZ3K/WyA==;
Received: from relay6.apple.com (relay6.apple.com [17.128.113.90])
by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id
66.19.17422.80CB2A75; Wed, 3 Aug 2016 20:52:41 -0700 (PDT)
X-AuditID: 11973e16-f793f6d00000440e-af-57a2bc08a5c6
Received: from chive.apple.com (chive.apple.com [17.128.115.15])
by relay6.apple.com (Apple SCV relay) with SMTP id 85.80.31551.80CB2A75;
Wed, 3 Aug 2016 20:52:40 -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 <0OBD00ILY9FSPY10@chive.apple.com>; Wed,
03 Aug 2016 20:52:40 -0700 (PDT)
Sender: cpaasch@apple.com
From: Christoph Paasch <cpaasch@apple.com>
In-reply-to: <57A211F9.1020809@uclouvain.be>
Date: Wed, 03 Aug 2016 20:52:40 -0700
Content-transfer-encoding: quoted-printable
Message-id: <831A6285-C7C2-454D-84C7-0700BC796B4C@apple.com>
References: <57A211F9.1020809@uclouvain.be>
To: =?utf-8?Q?Fabien_Duch=C3=AAne?= <fabien.duchene@uclouvain.be>
X-Mailer: Apple Mail (2.3124)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsUi2FAYpcu5Z1G4QftsJot7H6YxWnxefZ3N
gcljyZKfTB6vjn1nCWCK4rJJSc3JLEst0rdL4MqY++knY8FE7opN04UbGPs4uxg5OSQETCSW
H3vMDGGLSVy4t56ti5GLQ0hgL6PE4WM9TDBFf5YvYodIbGSUmLLmEyNIgldAUOLH5HssXYwc
HMwC6hJTpuRC1PxilHi+ux1sqrCApET3nTtQdrBE54mfrCA2m4CWxNvb7WA2p4COxPMZL1hA
bBYBVYnPE86wQcw0lpgy0wgkzCygLfHk3QVWiLU2Erc3NoDdJgQUv986hx2kXETAUWLDpHiI
k2UlnpxcxAJhb2CT6N+pPoFRZBaSo2chHD0LyYIFjMyrGIVyEzNzdDPzzPUSCwpyUvWS83M3
MYJCfbqd2A7Gh6usDjEKcDAq8fBukFwULsSaWFZcmXuIUZqDRUmc1//UgnAhgfTEktTs1NSC
1KL4otKc1OJDjEwcnFINjJoNOcFvw46uP21kOGFGZa3RzWCBU20XvfbUzhbb0XelQsf5+q+F
vrxPZd6E7V8RyVf9VfbtYn3zxdeqW+PeBzW8uy1/1SQq2Srir5ryRdurVSI355zcXrSe9cZ8
27qXmSZHNx6RmNfNIpXNt3GN06kNxsti+j8t4qn87fJotYbJk8Yvopc/KimxFGckGmoxFxUn
AgBZau6uVgIAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUi2FDMr8uxZ1G4wZQZlhb3PkxjtPi8+jqb
A5PHkiU/mTxeHfvOEsAUxWWTkpqTWZZapG+XwJUx99NPxoKJ3BWbpgs3MPZxdjFyckgImEj8
Wb6IHcIWk7hwbz1bFyMXh5DARkaJKWs+MYIkeAUEJX5MvsfSxcjBwSygLjFlSi5EzS9Giee7
25lBaoQFJCW679yBsoMlOk/8ZAWx2QS0JN7ebgezOQV0JJ7PeMECYrMIqEp8nnCGDWKmscSU
mUYgYWYBbYkn7y6wQqy1kbi9sYEJxBYCit9vncMOUi4i4CixYVI8xMmyEk9OLmKZwCg4C8mh
sxAOnYVk6AJG5lWMAkWpOYmVZnqJBQU5qXrJ+bmbGMHBWRi1g7FhudUhRgEORiUe3g2Si8KF
WBPLiitzDzFKcDArifDO3QkU4k1JrKxKLcqPLyrNSS0+xJgM9MlEZinR5Hxg5OSVxBuamBiY
GBubGRubm5iTJqwkzptwfH64kEB6YklqdmpqQWoRzBYmDk6pBkZVaa97E60fH3rmvbpOTl8u
YNfGxGkGnGHH5d/npEh/Cr8kc3/OpD7Jw5e3uFYsyz63XIIj1/WPU2HE2o0p92y0KrxDHswR
Mg5rdzDpXTnrq9vPXrag5y63KvMvPJRL1RNa6OZ7ckv8fdGeGzPFv3AXrborf6k8wzR+WXv7
SquJry4JC39Zu1GJpTgj0VCLuag4EQC7KSsVkgIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/LWr1tN500EfBvFOTy_rYfniijZY>
Cc: MultiPath TCP - IETF WG <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Multipath TCP Address advertisement 2/5 -
Reliability
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:52:43 -0000
> On Aug 3, 2016, at 8:47 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/ > > This is the part 2/5 : reliability. > > In RFC6824, ADD_ADDR options can be attached to segments carrying data > or pure acknowledgements. > In practice, notably given the length of ADD_ADDR with IPv6 addresses > and the HMAC, it is very likely that they will be often sent as pure > acknowledgements. > This implies that ADD_ADDR are sent unreliably, which could be > problematic when the ADD_ADDR is required to allow the establishment of > additional subflows, as in load balancing scenarios. > We propose to rely on the "E" (Echo) flag in the ADD_ADDR option. > This echo flag is used to acknolwedge a received ADD_ADDR by echoing it. > If the acknowledgement is not received, the ADD_ADDR option will be > retransmitted up to N times. I support the addition of the E-flag. Especially, as it improves reliability if one chooses to do the load-balancer deployment as described. Christoph > > Fabien > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp
- Re: [multipathtcp] Multipath TCP Address advertis… Yoshifumi Nishida
- Re: [multipathtcp] Multipath TCP Address advertis… Alan Ford
- Re: [multipathtcp] Multipath TCP Address advertis… Yoshifumi Nishida
- [multipathtcp] Multipath TCP Address advertisemen… Fabien Duchêne
- Re: [multipathtcp] Multipath TCP Address advertis… Alan Ford
- Re: [multipathtcp] Multipath TCP Address advertis… Yoshifumi Nishida
- Re: [multipathtcp] Multipath TCP Address advertis… Christoph Paasch
- Re: [multipathtcp] Multipath TCP Address advertis… Juliusz Chroboczek
- Re: [multipathtcp] Multipath TCP Address advertis… Fabien Duchêne
- Re: [multipathtcp] Multipath TCP Address advertis… Alan Ford