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