Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

Matthieu Baerts <> Fri, 13 December 2019 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EFBF1200A3 for <>; Fri, 13 Dec 2019 05:10:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=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 N5EB1AYHGgDb for <>; Fri, 13 Dec 2019 05:10:56 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93A3712003F for <>; Fri, 13 Dec 2019 05:10:55 -0800 (PST)
Received: by with SMTP id k8so2582701ljh.5 for <>; Fri, 13 Dec 2019 05:10:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vq1ayNfpnmW30MpoffpkV2cp5J5tCbcEFyjajmK8XgA=; b=TfM+NQ7nqjkuV2rbYHenMYOq2x1vVIbkfpors9LAX5Rq4jr0hI3v1KvjhYxYZmEn42 GnSdscJwAXqFmc/dvkjpmLFn4DTsUGRaBdHkx4zRwzOpu2qUwb2w/wcwPrG0c0wjuPWu JEDfjKnf+xoSXBcqXDNUBStu7JmX8FeQ2StypkMZB+TE5gStexbLkQ/2rxueQfgPmOFD NGgMSB36KtreDCgiAF380SusHhoKcAY7tBeTDf++at7XbwyG/yMrYDMYDhQYGIwB3cwz RbCHMSlvTmvVSga9BukNMrfvqLDPavJPd3uEIp5nEkDZ+RmmCIQ0fORPOnv0R/bsIY0d oEpQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vq1ayNfpnmW30MpoffpkV2cp5J5tCbcEFyjajmK8XgA=; b=bcRRcnfL27KJL8x0XtsiDp6YtxbCbp9AEj9HaAwDcAG94YucmZkEj8KV6sFwDZyQKw fstuYWwiG0rdO6sl4MRkQz1yks8TgLlGG6tGPD8PqeSPuhVSjAsF8OpxUzvOaO9Z6SDk V2TMFKcIStp/FlDIiIc14/hb//FQ/opDsidoC1foOMlbKTeLOHS5jTzCtnpl6I7oHv7Z KYDMwxPT72Ni+oC1JfovfJBltV629Gqqg60ofO4AhTeqE1otCCNyBZ6/JHYo2ma9lCTo WNgF2jYo2NmAOIn/7JSNprrDIOymyZM1gCX93E8eJ7LnIjDFIH6eTfTC2NZkzmtjx2oM pkEw==
X-Gm-Message-State: APjAAAVgh8r1XaASKcABfTn2zzFsAInXGcF1WsPRZviyTZNcHguT7SiF nzlSR18pqcuXjQRSjFRVPfnsSS6Q3W/BSujiGyyMtg==
X-Google-Smtp-Source: APXvYqyQWYGuLx/USOVntwwpHpDEy/6KrcWZaiLwoyO9gT2NvzyrJ9Z256HuBQxAXhqmSyGO6T/fGmYoOAh31DjviIk=
X-Received: by 2002:a2e:6c06:: with SMTP id h6mr9081239ljc.246.1576242653744; Fri, 13 Dec 2019 05:10:53 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <20191202172757.GA84163@MacBook-Pro-64.local> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Matthieu Baerts <>
Date: Fri, 13 Dec 2019 14:10:41 +0100
Message-ID: <>
To: Alan Ford <>
Cc: Christoph Paasch <>, Yoshifumi Nishida <>, MultiPath TCP - IETF WG <>, Philip Eardley <>, Mirja Kuehlewind <>, mptcp Upstreaming <>, Paolo Abeni <>
Content-Type: multipart/alternative; boundary="00000000000074e894059995972a"
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: Fri, 13 Dec 2019 13:10:58 -0000

Hi Alan,

Thank you for your reply.

On Fri, Dec 13, 2019 at 1:38 PM Alan Ford <> wrote:

> Hi Matthieu,
> On 13 Dec 2019, at 00:10, Matthieu Baerts <>
> wrote:
> Hi Alan,
> On Thu, Dec 12, 2019 at 10:19 PM Alan Ford <> wrote:
>> Hi Christoph (and Matthieu & Pablo),
>> WRT checksums, we do say:
>>    For example,
>>    if the initiator sets A=0 in the SYN but the responder sets A=1 in
>>    the SYN/ACK, checksums MUST be used in both directions, and the
>>    initiator will set A=1 in the ACK.
>>    If A=1 is received by a host that does not
>>    want to use checksums, it MUST fall back to regular TCP by ignoring
>>    the MP_CAPABLE option as if it was invalid.
>> Which would seem to cover all these eventualities. The “C” bit is purely
>> an indicator, and the crypto negotiation is clearly specified too.
> Thank you for your answer, that's clearer for the A bit.
> Our concern was mainly about the version. How should we react if, as a
> server supporting only v1, we have this sequence:
> SYN (MP_CAPABLE: v2)  →
> In other words, the server told the client that the maximum version it
> supports is v1. But in the ACK+MP_CAPABLE, the client sends v2 again.
> According to the RFC, the negotiation is done in the SYN and SYN+ACK. How
> do we react if the following ACK is sending a version (e.g. v2) which is
> not the expected one (e.g. v1)?
> For the moment in our implementation, we fallback to regular TCP.
> It means that future versions of MPTCP have to set the proper version in
> the 3rd ACK -- the negotiated one -- and not a copy of what has been sent
> in the SYN.
> Should we add a clarification for that?
> I see your point but I don’t feel we need any clarification here. The
> exchange as you rightly point out is done on the SYN/SYN+ACK. So when the
> server sends the SYN+ACK with v1, that is the decision that has been made.
> Sending an ACK with v2 is not a valid response. So if the server receives
> this, it treats it as any other invalid option and ignores it, so it treats
> it as if the ACK does not have an MP_CAPABLE, and thus it will fall back to
> regular TCP.

Even if at some point, we thought about not checking the version in the 3rd
ACK because it was a bit unclear for us, we now do fallback to regular TCP
if the version in the 3rd ACK is not the expected one.
So it seems that at the end, we correctly interpreted the RFC there. If you
feel that no clarification is needed for that, that's fine for us!

Best regards,
[image: Tessares SA] <> Matthieu Baerts | R&D
Tessares SA | Hybrid Access Solutions
1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium