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

Alan Ford <> Thu, 04 August 2016 07:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1D5F212B04A for <>; Thu, 4 Aug 2016 00:58:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oZy38cUTSHQN for <>; Thu, 4 Aug 2016 00:58:01 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 47EDC12B040 for <>; Thu, 4 Aug 2016 00:58:01 -0700 (PDT)
Received: by with SMTP id o80so367309569wme.1 for <>; Thu, 04 Aug 2016 00:58:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=NOGdhJ1lOlw0K7jdexugAiqpSbUPHf+dsN+8nWQAxQI=; b=fuhNHlei+KQg0XKyxQX+3RwYD/JTZNGTSQECqeb60pImNyclBsnIUdeMivIwz5tn3z dI6fWzfb/dTFb0UdrJzwrLAjrPP8L4N/wOo8ghoVize0j2Yty543pG3YfokbJ+IJxpWi pyzssHeI5yiVdE9gxcMiyf6kWEikEaix0NYxtGDa4woVXoe52Q4JRZOZKDr2bEqhYWCW fiMi2RjBO59bhZVf8beDCTGK+V/Xs/pWjXMvYkuSrBxuf8qjsIto9fqBx9MuM2GIxiXo IPc+SVMLWLeNLaGSqH/uiGSvzXBLM3Ou2N2NN+dwfxHVkOUFPVrpIpmemYRrbh9Pf6e6 7glg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=NOGdhJ1lOlw0K7jdexugAiqpSbUPHf+dsN+8nWQAxQI=; b=e/zwtP7YaA7gBihO5BaLNcQqZcey0vjJF4elgpZOXqiVA02NqsXPTnbktBW2NM8JNO TYDsaM/kLq5pODYVRHvf12PtAQ9TZ/WTnfaCcX3uAsYj8xfypseXVnlj5uyg1sIhWQZI F1NsDBq++oF/nMDKXChD56Nybz/lS3+Z0+y9GkU1Hi/GvWXT8ZMfGLGwlGz7v+cVLCZE hcH9eUHLXpJWugmXp0RqoP9u0tkssxozGUgpfpDec9XrMv3qLtU2GQHVbQztHRj1gu2t wDH0rkx8+kosxxx1an/y1z2pqh6iZ6i3gZ9f4BeIkcIBCNM3V0nNn0uJlJkpKwBxdwSa 1bqg==
X-Gm-Message-State: AEkooutHUTxTbCswrHEz4N7kd+q8eb5/ZLVTsmOTPvlbcM5oITifcsoSKnehx7PrPJDlAA==
X-Received: by with SMTP id w6mr29352189wmf.63.1470297479690; Thu, 04 Aug 2016 00:57:59 -0700 (PDT)
Received: from alans-mbp.lan ( []) by with ESMTPSA id q23sm2288123wme.17.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 04 Aug 2016 00:57:59 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_320D7422-0E3E-4DA6-81E5-57CF843C929B"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Thu, 04 Aug 2016 08:57:57 +0100
Message-Id: <>
References: <> <>
To: Yoshifumi Nishida <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Cc: "" <>
Subject: Re: [multipathtcp] Multipath TCP Address advertisement 2/5 - Reliability
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Aug 2016 07:58:04 -0000

Hi Yoshi,


> On 4 Aug 2016, at 07:36, Yoshifumi Nishida <> wrote:
> Hi Fabien,
> On Wed, Aug 3, 2016 at 8:47 AM, Fabien Duchêne < <>> wrote:
> Hello,
> As agreed in Berlin during IETF96, I'm sending a series of emails to
> discuss the different contributions proposed
> in <>
> 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 have several comments on this. Please let me know if I miss something.
> 1: Do we really need ADD_ADDR reliability in all cases? An end node might want to send ADD_ADDR for 'just in case' rather than for "I want you to use this" 
> BTW, I'm not sure if the draft tries to replace the current ADD_ADDR or to propose an additional ADD_ADDR option.

The argument is that by making it reliable, you only need to send it once to know it’s been received, even if the far end does not use it.

> 2: The sender cannot be sure whether the info in ADD_ADDR will be used or not. It depends on the peer's decision.   
> I might prefer re-transmitting ADD_ADDR up to N times when the sender doesn't receive MP_JOIN to the address for a certain amount of time.

As above, by making it reliable you only need to send it once to know it’s been received, even if the far end chooses not to use it.

I think I’m sold on this idea now, given the additional recent comments. I support this.

> 3: "the receiving host MUST return the exact option.." Although it is MUST, can we always do this? There might be a situation where there is no option space or no segment to send.  

I would assume the same rules as ADD_ADDR are followed, so it’s sent on a duplicate ACK in that case.