前面提到过 ECMP 和 TCP 之间的互不友好，pacing 收益和中断开销的互斥，在事实上阻碍了 packet-based LB 的部署，也限制了交换机，服务器的并发性能，同时潜在增加了 bufferbloat 的概率，而适用 packet-based LB 的短突发，老鼠流又无法承受 TCP 的建连开销，向后兼容的普遍刚性意味着几乎所有基础设施若不迁就 TCP，其崭新特性难尽其功。
虽在广域网领域很难改变现状，但在数据中心，仔细读上段文字，理解了掣肘间前因后果之后，在做双边传输优化或自研新协议之时，我们将获得启发。下面以最小修改 TCP 为例描述一个原教旨多路径 TCP 的构建过程。
我们的目标不是多路径，多路径只是手段，我们的目标是充分利用基础设施的并发能力，提高资源利用效率，只不过在数据中心普遍的 CLOS 架构下，多路径的策略非常合理且容易实现，因为 CLOS 在拓扑上本身就是 ECMP 原生的。问题转化为如何让 TCP 支持按 packet 分发，在宏观上充分利用 ECMP 能力，在微观上让转发节点解除流约束，充分利用硬件多处理能力，让硬件变得更简单，自然也就更高效。
若要 TCP 数据分发可按 packet 而不是 5-tuple-flow 执行，如何最小化修改 TCP？这个问题很有趣。
MPTCP 的路子显然把问题复杂化了，因为 MPTCP 是以 TCP 为基准的多路径协议，而不是以底层网络为基准的。交换机和服务器处理 MPTCP 的行为不能有任何不同，每一个 subflow 仍是一个 5-tuple-flow，这在底层的视角看，和标准 TCP 并无不同。TCP 流式约束只约束端，并不约束网络转发节点，TCP 又无法区分乱序和丢包，所以 TCP 在对待乱序需要非常谨慎而严格，避免无效重传。
TCP 的方式是维护一个 reordering 度量，在该度量的约束下，TCP 以重复 ACK 或 SACK 立即回复乱序状态，将处理收敛到 sender 的 update scoreboard 算法。
若以底层资源为基准来分析，自然就会有另一种不同于 reordering 度量但却更自然的方法处理乱序。如果底层网络是严格按照 packet 分发数据包的，那跑在该网络上的传输协议天然就是多路径的，因为乱序几乎是必然的，所以必须对乱序宽容，而宽容的方式自然就是提供一个时间窗口 w，在该时间窗口 w 之后再以重复 ACK 或 SACK 回复乱序状态。
这将是最简单的支持 packet-based 多路径分发的方法，sender 端无需任何改动，这才是真正的多路径 TCP，无论底层网络如何实现，这种 w-based MPTCP 都可兼容，例如，在传统的 5-tuple-flow 分发的网络中，w 将等于 0，相当于标准 TCP 收到乱序报文后立即回复 ACK/SACK。问题转化为 w 的计算问题。
设带宽为 B，已知的或测得的，RTT 为 T，已知的或测得的，若单路径送达，C = (B*T)/MSS 则为单路径报文容量，若 n 路径送达，每条路径承担 C / n 报文，到达时间为 T / n，因此需容忍等待 w = T - T / n 时间，n 可通过测量实际 delivery_rate 和 B 之比获得。
除了在延迟 w 之后按照标准 TCP 的方式发送重复 ACK/SACK 外，还可以直接发 NACK，但这就要修改更多代码了。
so？
所以说，reorder 根本就不是问题，不需要解决，reorder 是一个基本属性，维持 order 才是问题，维持不住时，就会给端到端协议带来必须要解决的问题。既然 reorder 是属性，协议要做的只是对 reorder 宽容，这就是原教旨的真含义。
如果底层网络是一个不丢包的无损网络，将不再需要区分乱序和丢包，而在现实中，底层网络的误码丢包率本就很低，加之 w-based MPTCP 充分利用 ECMP 路径，反过来极大均匀分发了流量，几乎避免了拥塞，因此这种方式大有可为。
最后，这是一个思想，不针对 TCP，只是用 TCP 最容易讲明白，记住，若不是 TCP，可在双边交互更多信息，这需要设计更好的协议头。
浙江温州皮鞋湿，下雨进水不会胖。