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.
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
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.
Here is an attempt to not use tcp_skb_cb with minimal change to MPTCP
code and skb code. I have tested the change by using wget from
multipath-tcp.org. pcap file is attached.
The approach that I have taken is very straight forward. On Tx when an
skb is allocated and the underlying socket is MPTCP , 32 bytes extra are
allocated and reserved as the head room. This space is used for
passing what was being passed in tcp_skb_cb. An used bit in sk_buff is
used to indicate this special case and when skb is copied the extra data
is also copied. clone is not an issue as the data is shared. This work
for retransmission also because tcp_transmit_skb clones the original skb.
On the Rx side, options are parsed in tcp at that point we can reuse the
space that was used for ether and IP headers and no extra space is
The space used is always right below the skb head pointer because the
location of head never changes.
Please take a look and let me know what I have missed.