Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

Alan Ford <> Thu, 05 December 2019 23:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2086012020A for <>; Thu, 5 Dec 2019 15:30:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 7TyKFOzZWn-S for <>; Thu, 5 Dec 2019 15:30:09 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B23E1201A3 for <>; Thu, 5 Dec 2019 15:30:09 -0800 (PST)
Received: by with SMTP id q9so5887000wmj.5 for <>; Thu, 05 Dec 2019 15:30:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KSf+w5GpFAR4LsOLNNnSaeZvlbQ48F3Bk2hAGbWiF10=; b=FEvkzs2mI8a7XGvZ6UhSnywJwP6jLjd5h6MujhPOsp554SA1sBkAMwvUGO/WHEZVWf 2qWbU7HZ3WzU1wRGvEPLMwgu51r5baueAlKdTx3ay/a30rSc2IzHAMkZ1JEs6sSgl6vW ENXhAguJc/cZHw7eydosY20ifHm0bZg0Rh71mzT+b0/h325Ue/WQ0GA8NvozV6//6XgR lAr+dSkY8m9BsHPK88yknnFXCX2E2F7DLKv8ybqr+KH/AVkIG/1+/h3BD60RRHtLcFdZ RCQiL14Osa79Tn5DJ1b0Hl16uXAN/OObs1PWaKVoZPPpnUDF2UbC7G4SaLHkvBatRxjP pEug==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KSf+w5GpFAR4LsOLNNnSaeZvlbQ48F3Bk2hAGbWiF10=; b=B462z8a6VJGER5h8qT5e35hxMvQPd27TZOVToBSpfDZuq8ZTCN7MXJUQKK9hUibA8R YXG4zlOifjwxH8Aqg+gBO8EP11Kn4Qqe6SqwrQFjbmyXGaqrDYFAlEQ7UVe3THoIIMqk PzGm2M4bp1ESkl3bansviOSId5m+htZP+lIQ1yXJ4sicGhr5i6vEiIkDq6ZnQ2jmLeLl eQr81zw5iMbBMayJQp5Ud9WFY0iCyE/M5pNqaqdwwp6GjWImsc2PAHWdpC75CNbYeeUI dNfBgONpTpm++iMczJne2aYI/3xTRnqW/l8N6Remck5f7HkJDATSxoVu+es/yCMbGg2m L/Qg==
X-Gm-Message-State: APjAAAU4govWTsjIdWPhAODSvmDwfxBGP0PgBdOM+BBLWEAw621HTHWg q6RflPxN/Sp/4JYgC13EQFE=
X-Google-Smtp-Source: APXvYqxM1a/glsK1yJv3sjCoLq0i3zxc58l97NkU2jrZB1RaePItODjd2NII65pIqz8slvhruDZdDw==
X-Received: by 2002:a1c:4489:: with SMTP id r131mr7648080wma.6.1575588607430; Thu, 05 Dec 2019 15:30:07 -0800 (PST)
Received: from alan-mbp.lan ( []) by with ESMTPSA id d12sm14009725wrp.62.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Dec 2019 15:30:06 -0800 (PST)
From: Alan Ford <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CADACC42-0CD9-470D-9957-EF1B7DCA8593"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 5 Dec 2019 23:30:04 +0000
In-Reply-To: <>
Cc: MultiPath TCP - IETF WG <>, Yoshifumi Nishida <>, Philip Eardley <>, Mirja Kuehlewind <>, mptcp Upstreaming <>
To: Christoph Paasch <>
References: <> <> <> <> <20191202172757.GA84163@MacBook-Pro-64.local> <> <> <> <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Dec 2019 23:30:11 -0000

> On 5 Dec 2019, at 17:39, Christoph Paasch <> wrote:
> Hello Alan,
>> On Dec 5, 2019, at 7:03 AM, Alan Ford < <>> wrote:
>>> On 5 Dec 2019, at 00:33, Christoph Paasch < <>> wrote:
>>>> On Dec 4, 2019, at 1:50 PM, Alan Ford < <>> wrote:
>>>> Thank you for the clarifications. I was revisiting the text to see ways to make these clarifications, however I find myself unsure of the need; please see comments below:
>>>> Section 3.1 clarification
>>>> Towards the end of Section 3.1 we actually say the following:
>>>>    The SYN with MP_CAPABLE occupies the first octet of data sequence space, although this does not need to be acknowledged at the connection level until the first data is sent (see Section 3.3).
>>>> Which would seem to cover exactly this concern.
>>> I'm not sure how it covers the concern, because the issue I raise is that the client needs to somehow find out if the MP_CAPABLE made it to the receiver. And the clarification I suggest is to spell out that it is the DATA_ACK (see my next comment).
>>>> However if you still feel further clarification is required, then we could add this also to the sentence you suggest, i.e.:
>>>>    If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE can be inferred by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3). 
>>> The ambiguity here is that DSS does not imply DATA_ACK. One could send a DSS without a DATA_ACK, but that would not signal to the client the reliable delivery of the MP_CAPABLE. Only the DATA_ACK will do so.
>> OK well maybe I am not understanding your concern here. The first sentence I quote says that the MP_CAPABLE needs to be DATA_ACKed when the first data is sent.
> Actually, strictly reading, the first sentence says that it must not be acknowledged until first data sent. It does not say that a MP_CAPABLE MUST be DATA_ACKed.

I really don’t read it like that - It makes no comment about when NOT to do something, simply that it needs to be acknowledged when data is sent. We could clarify it by changing it to:

   The SYN with MP_CAPABLE occupies the first octet of data sequence space, and this MUST be acknowledged at the connection level at the time the first data is sent or received (see Section 3.3).

>> The sentence beginning “If B has Data to send first” means:
>> - A->B SYN
>> - B->A ACK + DATA + DSS
>> DSS can contain one or both of DSM and DATA_ACK. However the previously quoted sentence says that the MP_CAPABLE needs to be acknowledged at the connection-level (i.e. DATA_ACKed) when the first data is sent.
>> However in writing this I realise that that text makes no comment about who is sending data. Because the intention is it applies to any data being sent (if B is sending, then it will include a DATA_ACK as well as a DSS; if A is sending then B will acknowledge with a DATA_ACK), but it could be read by someone to mean “only when acknowledging the first data does the MP_CAPABLE need to be included in the DATA_ACK”, which is not the desired meaning.
>> I am all for improving clarity so I think a clearer version of “If B has data…” would go:
>>     If B has data to send first, then the reliable delivery of the ACK + MP_CAPABLE is ensured by the receipt of this data with an MPTCP Data Sequence Signal (DSS) option (Section 3.3) containing a DATA_ACK for the MP_CAPABLE (which is the first octet of the data sequence space).
>> Would you be ok with that? It is shorter than the other edits whilst still being unambiguous.
> This however does not say that the reception fo a DATA_ACK allows A to stop sending the MP_CAPABLE. I still think that it should be spelled out somewhere.

Remember this is the case where B is sending data first. There would not be retransmitted MP_CAPABLEs from A in this case, since A has no data to send. The acknowledgement ball is entirely in B’s court, and thus if A received a data packet from B without a DSS option it would consider the connection non-MPTCP-capable.