Re: [multipathtcp] Benoit Claise's No Objection on draft-ietf-mptcp-experience-06: (with COMMENT)

Olivier Bonaventure <> Thu, 27 October 2016 19:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1298512989E; Thu, 27 Oct 2016 12:59:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xQncz9vMnKHt; Thu, 27 Oct 2016 12:59:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38713129855; Thu, 27 Oct 2016 12:59:13 -0700 (PDT)
Received: from mbpobo.local ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 8CC8B67DD54; Thu, 27 Oct 2016 21:59:05 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.9.2 8CC8B67DD54
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1477598345; bh=GdogTDcNDsUXK1MpuewX8RcjIEkgXLv7sl+72otPEu4=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=E1bomrTIiv60jWOrSqmo//Tx4HqkO3Ur2McBTo8ulPkZadwkrQu0xqgDEQaWSt6ct HA7W7rzv67V1M0MFpRFui5vGpbVmiEa86Z+stYkXHDAjkpbKAuvoWQqYgguqFxFq0P U6Q4oM4ofZpxAQblU/nAz3tnvzvo+ZOMbosxUhVI=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-5
References: <>
To: Benoit Claise <>, The IESG <>
From: Olivier Bonaventure <>
Message-ID: <>
Date: Thu, 27 Oct 2016 21:59:05 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: 8CC8B67DD54.A77C4
X-SGSI-MailScanner: Found to be clean
X-SGSI-Spam-Status: No
Archived-At: <>
Cc:,,, qin Wu <>
Subject: Re: [multipathtcp] Benoit Claise's No Objection on draft-ietf-mptcp-experience-06: (with COMMENT)
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, 27 Oct 2016 19:59:16 -0000


> Benoit Claise has entered the following ballot position for
> draft-ietf-mptcp-experience-06: No Objection

Thanks for your comments. A new version of the draft will appear soon on 
the IETF servers.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thanks for this document.
> - This document contains a couple of possible improvements.
> I believe this important aspect of the draft should also be mentioned in
> the abstract.


> - Just a thought (no need to reply):
> On one side, section 3.1 speaks of "middlebox interference".
> On the other side, this document via
> [I-D.lhwxz-hybrid-access-network-architecture] proposes just that: a new
> middlebox function.
> This new middlebox might generate some interference for others.  Sarcasm
> warning: I guess that middleboxes are like children, we can only stand
> ours.
> I wanted to make that point, in light of all the middlebox discussions
> these days, for example in the QUIC charter.

I agree, but middleboxes could also help the deployment of MPTCP. At 
least this is what we observe with hybrid access networks using MPTCP to 
combine DSL and LTE and smartphones using MPTCP to bond WiFi and LTE.

> - Another thought (again no need to reply)
>    "Since September
>    2013, Multipath TCP is also supported on smartphones and tablets
>    running iOS7 [IOS7].  There are likely hundreds of millions of
>    Multipath TCP enabled devices.  However, this particular Multipath
>    TCP implementation is currently only used to support a single
>    application.  Unfortunately, there is no public information about the
>    lessons learned from this large scale deployment."
> Yes, this is really unfortunate.

This is now fixed. A description of this deployment and some lessons 
learned will appear in the next issue of the IETF Journal. A reference 
to this forthcoming paper has been added.
> Below is Qin Wu's OPS directorate review:
> I think this document is well written and ready for publication. Here are
> a few editorial comments:
> 1.       Section 1, paragraph 2 mentions that three implementation are
> open sources. Which three of them are open sources? I think it includes
> apple MP-TCP, but it is not clear in the text.

This has been fixed.

> 2.       Section 2.2 paragraph 7 points out using REMOVE_ADDR option may
> cause operational problem, but I don’t see any discussion on this in the
> operation experience section, is this an open issue that needs to be
> addressed in the future or other document?

This is the generic problem of the loss of REMOVE_ADDR and ADD_ADDR 
options. There are still discussions on this issue within the MPTCP
working group.

> 3.       Section 3.1 talks about the v0.87 Multipath TCP implementation
> What does V0.87 stands for? Version number? is there any reference to
> it?

This was the version used in the paper. I have removed this number.

> 4.       Section 3.2
> s/the the default congestion control/ the default congestion control


> 5.       Section 3.2 last paragraph said that Reports from some users
> indicate that they seem to favor OLIA. It looks this statement is
> groundless statement.

This comes from discussion with users but not real measurements. I have 
removed this sentence.

> 6.       Section 3.9
> s/ returned to the DNS query/return in response to the DNS query


> 7.       Section 3.10 said:
> “
> A better approach would probably be to try a few attempts on
> the WiFi interface and then try to use the second interface for the
> initial subflow as well.
> ”
> When trying to use second interface for initial subflow? A few attempts
> on the WIFI interface fails?


> 8.       Section 3.2
> s/accomodate/accommodate
This sentence has been removed because there are still discussions on 
this topic in the MPTCP mailing list.