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

Yoshifumi Nishida <> Thu, 04 August 2016 06:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4866012D16B for <>; Wed, 3 Aug 2016 23:36:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kLvZ7AYBsLfF for <>; Wed, 3 Aug 2016 23:36:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23CC912D131 for <>; Wed, 3 Aug 2016 23:36:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id ADBD4278471 for <>; Thu, 4 Aug 2016 15:36:28 +0900 (JST)
Received: by with SMTP id w127so162557198vkh.2 for <>; Wed, 03 Aug 2016 23:36:28 -0700 (PDT)
X-Gm-Message-State: AEkoout3b9DqIXFvqw0QOB+X9noTCc5uzibgN7EjNP9Tg51WPdAXkIP5mV4DqFLOHjuH7g1PD2Yv7xKex8HksQ==
X-Received: by with SMTP id h187mr36315148vkg.84.1470292586778; Wed, 03 Aug 2016 23:36:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 3 Aug 2016 23:36:26 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Yoshifumi Nishida <>
Date: Wed, 3 Aug 2016 23:36:26 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: =?UTF-8?Q?Fabien_Duch=C3=AAne?= <>
Content-Type: multipart/alternative; boundary=001a114bd45c59d94b0539392b21
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 06:36:36 -0000

Hi Fabien,

On Wed, Aug 3, 2016 at 8:47 AM, Fabien Duchêne <>

> 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
BTW, I'm not sure if the draft tries to replace the current ADD_ADDR or to
propose an additional ADD_ADDR option.

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.

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.