The following message was held by the server (since Alan is not a list member), and due to
a mailman server bug could not be released for delivery. I'm forwarding the copy that
was sent to list owners.
From: Alan Ford <alan.ford(a)gmail.com>
Subject: Re: MPTCP implementation feedback for RFC6824bis
Date: November 28, 2019 at 8:16:31 AM PST
To: Christoph Paasch <cpaasch(a)apple.com>
Cc: MultiPath TCP - IETF WG <multipathtcp(a)ietf.org>, Yoshifumi Nishida
<nsd.ietf(a)gmail.com>, Philip Eardley <philip.eardley(a)bt.com>, Mirja Kuehlewind
<ietf(a)kuehlewind.net>, mptcp Upstreaming <mptcp(a)lists.01.org>
Thank you for the feedback. Comments inline...
On 27 Nov 2019, at 19:29, Christoph Paasch <cpaasch(a)apple.com
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
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 multipath-tcp.org
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?