Subject: [multipathtcp] Question on Data Sequence Mapping

From: Rao Shoaib <[email-masked]>
Date: Mon, 15 May 2017 17:39:12 -0700

Hi,

Section 3.3.1 of RFC 6824 says

The data sequence mapping specifies a mapping from subflow sequence 
space to data sequence space. This is expressed in terms of starting 
sequence numbers for the subflow and the data level, and a length of 
bytes for which this mapping is valid.

<...>

A mapping is fixed, in that the subflow sequence number is bound to the 
data sequence number after the mapping has been processed. A sender MUST 
NOT change this mapping after it has been declared;

Does it mean that I can not map the data sequence to another (higher) 
TCP sequence number on the same flow.

The reason I am asking this is that if this is allowed  TCP and MPTCP 
processing can be separated on the recv side. For example, TCP could 
accept the packet but MPTCP could reject it. Since data level ack would 
not be sent the peer would retransmit, possibly using the same flow but 
with a different mapping so that TCP would accept the packet.

Is this legal to do and if not than why ?

Regards,

Rao

---

From: Rao Shoaib <[email-masked]>
Date: Mon, 15 May 2017 17:54:59 -0700

I think I have answered my questions. As long as the subflow-sequence 
number and Data sequence number in the DSS option are unchanged  things 
will work.

Rao

On 05/15/2017 05:39 PM, Rao Shoaib wrote:
> A mapping is fixed, in that the subflow sequence number is bound to 
> the data sequence number after the mapping has been processed. A 
> sender MUST NOT change this mapping after it has been declared;
>
> accept the packet but MPTCP could reject it. Since data level ack 
> would not be sent the peer would retransmit, possibly using the same 
> flow but with a different mapping so that TCP would accept the packet.
>
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp

---

From: Mark Handley <[email-masked]>
Date: Tue, 16 May 2017 09:27:32 +0100

The main rule is that you can't change the data corresponding to subflow
sequence numbers after you first send the DSN mapping.  In practice,
this largely means don't retransmit different data corresponding to
subflow sequence numbers than you did the first time.  The rationale is
that there are stateful middleboxes that can re-assert the original
data, and will corrupt MPTCP unless you maintain this invariant.

You can, of course, also retransmit MPTCP data on another subflow, so
MPTCP has to be capable of receiving the same data more than once and
remove duplicates.  There's no obvious use for sending the same MPTCP
data more than once on the same subflow, but I don't believe it's
explicitly disallowed.  The original mapping would not change, but you'd
have an additional subflow mapping for the same data.  I would expect an
MPTCP receiver to permit this, but it isn't something we ever considered
when we were writing the spec.  I'm just not sure why anyone would want
to do it.

Mark