Re: [MPTCP] Separating MPTCP packet processing from TCP

[Christoph Paasch <cpaasch at apple.com>]

[-- Attachment #1: Type: text/plain, Size: 3817 bytes --]

Hello Rao,

On 15/05/17 - 18:16:36, Rao Shoaib wrote:
> I am thinking the cleanest implementation would be to separate MPTCP
> processing from TCP. On the receive side, when a packet arrives TCP only
> does TCP processing (That leaves the code untouched), the packet is than
> passed upto MPTCP which does MPTCP processing and can either process the
> packet, drop it or send a reset.
> 
> The current implementation is doing receive processing in TCP because it
> wants to validate the packet and accept it in TCP  or not -- but why ? that
> seems to be an implementation choice.

you can look at mptcp_handle_options for the conditions upon which we stop
processing the segment, when coming from tcp_validate_incoming. For example,
when a MP_FASTCLOSE is received, the subflow gets killed with a TCP-RST.

The same holds when receiving a DSS-option without DSS-checksum although the
DSS-checksum has been negotiated.


The question would be, whether we can delay the killing of the subflow &
sending of the RST until later. This would mean that the packet gets
completely handled (acks processed, incoming data acknowledged,...)
by the TCP-stack and later on the subflow gets killed.
This *might* be ok from a protocol-perspective, but I'm not sure.

> In the case where the receiver drops the packet in MPTCP, no data ack will
> be sent and MPTCP will re-transmit, It can retransmit even on the same flow.
> To achieve this the code requires some change as the DSS option has to be
> saved. I think this is doable and is a much cleaner solution.

For incoming data, that's already how it is handled. We pass the segment to
the MPTCP-stack through the sk_data_ready callback, where we go over the
segments, check whether their DSS-checksum is correct, check if it is
in-window,... And if all is good, queue it at the MPTCP-level and send a
DATA_ACK.


Cheers,
Christoph

> Similarly we need to think about the Tx side -- That is not so straight
> forward but we need to think harder.
> 
> I can work on making the Rx changes but want to discuss it in case I am
> missing potential issues and if this is not a got option.
> 
> Comments  ?
> 
> Rao
> 

> From: Rao Shoaib <rao.shoaib(a)oracle.com>
> To: "multipathtcp(a)ietf.org" <multipathtcp(a)ietf.org>
> Date: Mon, 15 May 2017 17:39:12 -0700
> Subject: [multipathtcp] Question on Data Sequence Mapping
> 
> 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
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp(a)ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp

> _______________________________________________
> mptcp mailing list
> mptcp(a)lists.01.org
> https://lists.01.org/mailman/listinfo/mptcp