Re: [multipathtcp] Multipath TCP Address advertisement 2/5 - Reliability

Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> Wed, 03 August 2016 21:01 UTC

Return-Path: <jch@pps.univ-paris-diderot.fr>
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 29DF212D851 for <multipathtcp@ietfa.amsl.com>; Wed, 3 Aug 2016 14:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 v3iQN7vBLySJ for <multipathtcp@ietfa.amsl.com>; Wed, 3 Aug 2016 14:01:37 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB05D12D5AE for <multipathtcp@ietf.org>; Wed, 3 Aug 2016 14:01:36 -0700 (PDT)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/56228) with ESMTP id u73L1Yx3002791; Wed, 3 Aug 2016 23:01:34 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 5F7D661FA1; Wed, 3 Aug 2016 23:01:34 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id EqFWbWnC9xn9; Wed, 3 Aug 2016 23:01:33 +0200 (CEST)
Received: from trurl.pps.univ-paris-diderot.fr (col75-1-78-194-40-74.fbxo.proxad.net [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 57DE861F9D; Wed, 3 Aug 2016 23:01:30 +0200 (CEST)
Date: Wed, 03 Aug 2016 23:01:30 +0200
Message-ID: <87h9b1wor9.wl-jch@pps.univ-paris-diderot.fr>
From: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
To: Alan Ford <alan.ford@gmail.com>
In-Reply-To: <2F3600BC-5BA6-4171-BCD1-6C678B41C63F@gmail.com>
References: <57A211F9.1020809@uclouvain.be> <2F3600BC-5BA6-4171-BCD1-6C678B41C63F@gmail.com>
User-Agent: Wanderlust
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Wed, 03 Aug 2016 23:01:34 +0200 (CEST)
X-Miltered: at korolev with ID 57A25BAE.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 57A25BAE.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@pps.univ-paris-diderot.fr>
X-j-chkmail-Score: MSGID : 57A25BAE.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/3Gz39n41E3kr6noq25SZqE5Es_k>
Cc: "multipathtcp@ietf.org" <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: Wed, 03 Aug 2016 21:01:39 -0000

> I am neutral on the addition on this flag… We have spare bits, so could
> easily allocate this. But is it worth it?

I haven't read the draft.  But it looks to my uneducated eyes that adding
this flag carries little additional implementation complexity, so even if
it turns out to be useless it won't harm much.  On the other hand, should
it turn out to be useful at a later date, it will be difficult to add in
a backwards compatible manner.

Can somebody who has implemented this flag confirm that it's easy to
implement, and that there are no hidden gotchas?

-- Juliusz