Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

Alan Ford <> Fri, 13 December 2019 12:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FA4A1207FF for <>; Fri, 13 Dec 2019 04:38:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 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, 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 kXjrw_4U6d4x for <>; Fri, 13 Dec 2019 04:38:31 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0F95D12004A for <>; Fri, 13 Dec 2019 04:38:31 -0800 (PST)
Received: by with SMTP id y17so6490068wrh.5 for <>; Fri, 13 Dec 2019 04:38:30 -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=GXTl6aFKj7f6/asHalGFHT+WXwPE5eZmYhynLz3cOFY=; b=PeOBNDtmGgbxqRmRa12CHEiEmQ9tGTWKEYiRKNkT7BQ1yKJ5PesanqHuLNfALxPU6L WYvBy7SDORzJN/Jq/gsrzOMV754N5xtMBJ5rLsaUGMn/HkIh/Kwb1pmvP/iy5L5M5JVL MBxC/fSfutFXpQkYJRpq3xxmx81CO/+VcS5sSfYogEg24W1c8u465DoWzQznjQ43vKrF f3un/kd4eMcRpuvIsDfFfxZz8H/rWWbkqiSQ2sWyUeA7vNKYV77CVkF3bi5BhIVqFVlR YozmhHG9zRdNY4gRCkLWAY+xs+ZFC3XQFKy50LwYYJdhTzOUyBUZSb4CAYilI74Z1zkk XSUA==
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=GXTl6aFKj7f6/asHalGFHT+WXwPE5eZmYhynLz3cOFY=; b=lKZ6zZc+1eriB5eePgTpu689HgXW2QD+HrSrY50TaGbAdIKFz6hNHnuBmmQmGFACJU l4Ku4sH2VKHse37il/RGoGxzRSrEXi/oUWNXrluObadTvp/wdRQE2cJUjcu0oe+8Epxm welmnDbJUvZc5Rt7o8q5/zbNbdTuBYZn4zFLzJlM4I1k1BfnMGIv1flQ6TbluTQIjqzh LkstvOLjA30ZWkoyb83jZ+Rt2cCLEHFegX78NzE+E7r1Db9fDCiDHmmBcTSm7imTcDX1 Hwt8aRS228f4Gu+8O44Qr9vag5DbJw2RqhEuSw7UmATspY/nveOBzanEiOKhH4T38inJ AOoQ==
X-Gm-Message-State: APjAAAWX2xPMt0dVBpwVvCzClD4oDaHE0GiXcM7JHomKJqTyOD8bJmzp AtOb08Jv3bhWpmBWzFnE674=
X-Google-Smtp-Source: APXvYqyzzU7H25ITw82xOOADej1hGanwnpzuwSpQ371WpsSKH1j7Y2cSWD9THEGugI7ZPAL1Cg1SLQ==
X-Received: by 2002:a05:6000:1047:: with SMTP id c7mr12926914wrx.341.1576240709463; Fri, 13 Dec 2019 04:38:29 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id h2sm9835086wrv.66.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Dec 2019 04:38:28 -0800 (PST)
From: Alan Ford <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_8F03BF77-C56C-421E-BB79-0DF43196CFE1"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 13 Dec 2019 12:38:26 +0000
In-Reply-To: <>
Cc: Christoph Paasch <>, Yoshifumi Nishida <>, MultiPath TCP - IETF WG <>, Philip Eardley <>, Mirja Kuehlewind <>, mptcp Upstreaming <>, Paolo Abeni <>
To: Matthieu Baerts <>
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: Fri, 13 Dec 2019 12:38:34 -0000

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.