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 29, 2019 at 1:13:38 PM 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>
On 28 Nov 2019, at 19:49, Christoph Paasch <cpaasch(a)apple.com
> On Nov 28, 2019, at 8:16 AM, Alan Ford <alan.ford(a)gmail.com
> Hi Christoph,
> Thank you for the feedback. Comments inline...
>> On 27 Nov 2019, at 19:29, Christoph Paasch <cpaasch(a)apple.com
>> Section 3.3.1, page 32 & 33, "A data sequence mapping does not
>> 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”
The problem with the MAY is that the sender can't really know if the receiver accepts
it (more regarding this below)
> 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?
Let me try to clarify what exactly we mean with early/late mapping so that we are all on
the same terms here:
A TCP-segment with sequence-number 1 holds a DSS-option with subflow-sequence number 1001
and data-length 100. This means we need to allocate space to store this DSS-option so that
when the TCP-segment with seqno 1001 arrives we can know the mapping. There may be coming
more of these DSS-options which all need to be stored in allocated memory. It is unclear
what the limit to this is and there is no way to communicate this limit to the sender.
I don’t think we have ever intended to support a mapping like this. If the text is not
clear here then yes, we might have an issue.
We intend only to support: A TCP segment with sequence-number 1 holds a DSS option for SSN
1 and length 10000 (so multiple segments in the future).
Or, slightly more convoluted, a TCP segment with SN 100, length 100, which holds a DSS
option for 151-250, and bytes 50-150 were already covered by a previous mapping.
I do not believe we have ever intended mappings on data segments where the segments do not
include any of the mapped data. We did, however, intend to support mappings on pure ACKs
in order to avoid any option space limits.
The receiver receives data without DSS-options with TCP-sequence 1 to 1001. The
corresponding DSS-option however arrives with the TCP-segment with seqno 2001. Here, the
receiver needs to hold on to this data, waiting for the TCP-segment with the DSS-option.
At one point the receiver needs to drop the data due to memory limits. Again, the sender
has no way for knowing what this limit is.
So this is slightly more problematic, and this is what the MAY in the text is designed to
I believe we had intended to support a situation where you could have a segment 1-1000
without a DSS option, and 1001-2000 also without, and then 2001-3000 with the option then
providing a mapping for 1 to 2001 or higher. This would allow a sender to start pushing
out data before it knew what a mapping might look like. It does, however, seem an unlikely
situation but you as a receiver could of course reduce the subflow window size in order to
limit buffering. The text does recognise the memory issue and point out that this won’t be
DATA ACKed and as such a sender should soon realise and retransmit on a separate subflow
and then this subflow may eventually be closed.
Another situation would involve two mappings on the same TCP segment. If the first 50
bytes of a segment are covered by the mapping provided in that segment, but there are then
also another 50 bytes, then the mapping can’t be provided until the next segment.
I guess my initial thought here is that this was intended to cover a number of corner
cases but if it does not work for you then there are several compliant ways of dealing
When the DSS-option comes together with the corresponding
TCP-sequence it is straight-forward to store it together with the data. There are no
issues with memory-allocation,... as all of this is accounted together with the announced
window (yes, the memory is not counted against the window, but the receiver can foresee
the DSS-option overhead when computing what window he should announce).
When a receiver gets data without a DSS-option, he can store it for up to 64KB of data as
that is the maximum data-level length and the last segment of the 64KB-train could be
holding the DSS-option. After that he has to drop the data.
When the mapping partially covers the segment it also isn't a problem as the unmapped
part can safely be dropped and the mapped part can be passed on to the MPTCP-layer.
All of this does not imply that every segment of a mapping needs to hold the DSS-option.
Just one of them needs to have it.
That last statement aligns with what was intended in the text. But are you really saying
that, or are you saying that the first one needs to have it? Because that would be a