Re: [multipathtcp] MPTCP implementation feedback for RFC6824bis

Alan Ford <> Thu, 28 November 2019 16:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 22EF0120895 for <>; Thu, 28 Nov 2019 08:16:40 -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 Ahhi4cJWGREs for <>; Thu, 28 Nov 2019 08:16:38 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C7D5120893 for <>; Thu, 28 Nov 2019 08:16:38 -0800 (PST)
Received: by with SMTP id b6so2175996wrq.0 for <>; Thu, 28 Nov 2019 08:16:38 -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=zoaXdLG9/xei7Nk1ER+cXqheDgLda+3/+PYW+KjuDJs=; b=M+DqrwvsRv7OWYF1dQJi1LFSJLb6SAfI3o1Qkg9ZQ7LcqSza78Oi3oL4ojSSuk6bx3 iTfTJ4nMTztbvxeu7RuFoHHGZBXr4bJq/tDgqFxeQOUbBLoHLrqitfY4tzCCgnxCl6TY Zwr90jj4rammmdXMwo6e7U4dDcJ45X3ub9F8TYy26F30tNCSgQKFiksr0O3aTYB9hQX9 YgSRkMvhHWmoyEC5DF+G5I4oa5Ls4hGULaiqpEZlzzVnOSBQqqZHeDFdxhTWVaTe4Q7R sXOBfHtyHjJQsw2W/ysuLg04bA/i6QBjPTPc2SAV5kfTmhITTJQWRziYQrX1nEPiGM9e w57Q==
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=zoaXdLG9/xei7Nk1ER+cXqheDgLda+3/+PYW+KjuDJs=; b=NTDqm6u4Pbf7E+QDCd4gxMQ708fD54c8zsuuDgvYyVRgdOi2+8iqZIv04+RRNKl4KI ZNLnZ6pVc3BYA9Au8sYb6H569ngiEI86/2fiVd1b2BKkvdRL0QfKAK9kAEBt8M1c5GHh 4uTEIBS7Zj3a5jy7gFVJFLkdBLniVi8FiGSSL/Ajp7RTgMKIYX5vrV+jdHn+xK4CAEjO du6PM0HE+N3usFXPR3FOFJFdBBK0z5O5tVcHxziO7mqvUjzkArh/78BE7YyGRBP1kKfJ EsKcQkiZq6qxympLKlHIzIrF69wBRVQcELRDD2M2VpVpHH3fxw7tPNR73mA1L2BvK418 Ss8w==
X-Gm-Message-State: APjAAAXTSZhltThwuv+3XsVQef3es0h4JdvV9U/OxHM+iCFjIqzy93ZK H+umAdcHI+x9MfQXN66pXYc=
X-Google-Smtp-Source: APXvYqw0R8c2ARvLPUUvAR+hk8Aa0U7Webi8pQBKmY1wCSRmdM79J7Y0Sf4N5UGYe0hu0z3+T9pOAw==
X-Received: by 2002:a5d:49c4:: with SMTP id t4mr42728777wrs.226.1574957796471; Thu, 28 Nov 2019 08:16:36 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id w10sm10523678wmd.26.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Nov 2019 08:16:35 -0800 (PST)
From: Alan Ford <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_115D2D64-E2EE-4435-86E7-6B15CA0285FD"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Thu, 28 Nov 2019 16:16:31 +0000
In-Reply-To: <>
Cc: MultiPath TCP - IETF WG <>, Yoshifumi Nishida <>, Philip Eardley <>, Mirja Kuehlewind <>, mptcp Upstreaming <>
To: Christoph Paasch <>
References: <>
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, 28 Nov 2019 16:16:40 -0000

Hi Christoph,

Thank you for the feedback. Comments inline...

> On 27 Nov 2019, at 19:29, Christoph Paasch <> wrote:
> Hello,
> as I mentioned during the meeting last week in Singapore, the team working on upstreaming MPTCP into the Linux Kernel has some feedback on RFC6824bis that would be good to be factored into the RFC before publication.
> Here is the list of comments/changes the team is suggesting:
> Section 3.1, page 19, "If B has data to send first,..."
> The first phrase states that when A receives a DSS from B it indicates successful delivery of the MP_CAPABLE. However, it is not the DSS but rather the DATA_ACK that indicates this. Digging through some past e-mail exchanges I had with Alan I see that that was indeed the intention.
> We are thus suggesting to change this text to:
> 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 a MPTCP Data Sequence Signal (DSS) option that includes a DATA_ACK (Section 3.3). Further, whenever A receives a DATA_ACK from B it is a signal of the reliable delivery of A's MP_CAPABLE. After this, A can send data to B with a regular DSS option.

That seems entirely logical clarification, and was the intention anyway. A developer probably infers the meaning but clarification is no bad thing.

> Section 3.3.1, page 32 & 33, "A data sequence mapping does not need..."
> This paragraph states that it is permissive to send a mapping in advance. Late-mapping is specified a bit higher around the sentence 
> "Implementations MAY hold onto such unmapped data for a short while in the expectation that a mapping will arrive shortly"
> This kind of early/late mapping announcements are difficult to handle in an implementation. The Linux Kernel implementation of <> has always disallowed such kind of mappings. Meaning, whenever a DSS-option is received such that the range specified by the relative subflow-sequence number in the DSS-option and the data-length does not (partially) cover the TCP sequence number of the packet itself, the subflow will be killed with a TCP-RST. The problem around handling such early/late mappings is that it is unclear for how long the stack needs to remember these mappings (in the early-mapping case), or for how long he needs to hold on to the data (in the late-mapping case).
> We thus suggest to change this to the following:
> Whenever a DSS-option is received on a packet such that the mapping of the subflow-sequence space does not partially cover the TCP-sequence number of  the packet itself, the host MUST discard this mapping and MAY destroy the subflow with a TCP-RST. It should be noted that a DATA_FIN that does not come with data has a relative subflow-sequence number of 0 and thus should be handled separately.

This one I do have an issue with:

- It is a technical change
- Wording to this effect has been in the document since pretty much the beginning
- It is a MAY which might as well say “there is no guarantee this would work”

Most importantly, the replacement text seems not to address this issue at all. If I read it correctly, it says that the data sequence mapping option MUST partially cover the subflow sequence space of the packet itself. But that has nothing to do with late or early mapping, both could partially cover the subflow sequence space and preceding data.

Can you clarify exactly what you want to permit and prevent, here?

Best regards,