开头啰嗦几句，关于mptcp的研究主要有两种：拥塞控制和数据包调度。关于多径的拥塞控制算法有LIA，OLIA，BALIA，wVegas，可以称作是耦合式的拥塞控制。为什么要采用耦合式的拥塞控制，而不是在各个子流上采用原有的TCP的拥塞控制算法（RENO，CUBIC）呢。用学术点的话说，考虑到网络中大部分是TCP流，MPTCP应该保有TCP友好的特性。用朴实的话说，做为一个研究项目，总要有些不同吧，要是MPTCP在各个子路径上仍是TCP的拥塞控制算法，怎么发论文呢？而在linux内核中实现的MPTCP，是可以使用单径的拥塞控制的（RENO，Cubic）。由于路径差异性，多径的传输会导致数据包的乱序到达，存在队头阻塞（head of line blocking）的现象，就是队头的数据包迟迟不到，而后面的数据包又不断到达，使得接收端的缓冲区占用不断增长。缓冲区的存在长度限制，当缓冲区溢出，新到的数据包就会被主动抛弃，引起非拥塞丢包。接收端检测到数据包丢包的后，拥塞控制为主动降窗，降低吞吐量。拥塞控制的降窗本身是为了缓解网络拥塞，而接收端缓冲区溢出的丢包，被误检为网络拥塞，从而影响MPTCP的吞吐量。这个问题就是MPTCP调度要解决的问题。关于数据包调度的算法，感兴趣的读者可以参考[1-4]。但是，我并没有看到这些文章的本质不同。而关于多径的拥塞控制，又需要那么点理论，基于TCP的流模型发现一个与前人不同的方法，又是一个很难的操作。啰嗦了这么多，就是关于MPTCP，发文章越来越难，研究生在选题的时候可以适当回避下这个领域。当你那多年不搞研究的老板，扔给你这个课题时候，迂回地同老板探讨下其他课题还是很有必要的。如果继续这个课题，最后的论文，怎么弄出效果比别人好的算法，就需要你去想些技巧了。
MPTCP是怎么重传数据包呢？MPTCP在数据包丢失后，可以通过另外的另外的路径进行数据重传。但是这样就会导致原来的路径的数据包序号存在一个空洞，接收端就会不断地发送sack，通知发送端，某个sequence number的数据包没有收到。问题的解决方案，就是可以选择其他路径重传，但是也必须在原有路径上重传一份。这个处理方式在[5]里有描述：
3.3.6. Reliability and Retransmissions
The data sequence mapping allows senders to re-send data with the
same data sequence number on a different subflow. When doing this, a
host MUST still retransmit the original data on the original subflow,
in order to preserve the subflow integrity (middleboxes could replay
old data, and/or could reject holes in subflows), and a receiver will
ignore these retransmissions. While this is clearly suboptimal, for
compatibility reasons this is sensible behaviour. Optimisations
could be negotiated in future versions of this protocol.
[1] Accelerating Multipath Transport Through Balanced Subflow Completion
[2] STMS: Improving MPTCP Throughput Under Heterogeneous Networks
[3] QAware: A Cross-Layer Approach to MPTCP Scheduling
[4] Low-Latency Scheduling in MPTCP
[5] https://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-12