Multipath TCP and middleboxes
The design of Multipath TCP RFC 6824 has been heavily influenced by the presence of middleboxes in the global Internet. In [Honda2011] Micchio Honda and his colleagues showed that middleboxes could change almost any field of the IP and TCP headers. Based on these measurements, the MPTCP working group developed various heuristics to enable Multipath TCP to cope with the interference caused by middleboxes. The implementation of these heuristics inside the Multipath TCP implementation in the Linux kernel was more difficult than initially taught given all the corner cases that had to be supported. To verify the correct operation of these heuristics, Benjamin Hesmans wrote a set of Click elements that implement models of the various interferences that can be caused by middleboxes on TCP segments [Hesmans2013b] . MBClick [Hesmans2013a] could enable other implementors of Multipath TCP or other extensions to validate the interactions between their implementation and middleboxes.
While testing the impact of middleboxes, we also evaluated whether already deployed TCP extensions were vulnerable to middlebox interference. We knew from practical experience with our local firewalls that sequence number randomisation was still a default in many firewalls. We measured the impact of sequence number randomisation on existing implementations of the TCP Selective Acknowledgement options.
Source [Hesmans2013b]
The figure above shows that when an old firewall randomises the TCP sequence numbers without randomising the SACK blocks, the TCP throughput is lower when SACKs are enabled than when they are disabled. This unexpected results is due to an implementation choice in the Linux and MacOS versions that we tested. Both stacks completely ignore a packet that contains an invalid SACK block. With a dump sequence number randomiser, almost all received SACK blocks are invalid. This implies that as soon as there are packet losses, TCP acknowledgements are considered to be invalid and ignored. This blocks the fast retransmit mechanism and TCP can only rely on its retransmission timer to recover from packet losses.
References
| [Hesmans2013a] | Benjamin Hesmans, Click elements to model middleboxes, https://bitbucket.org/bhesmans/click} |
| [Hesmans2013b] | (1, 2) Benjamin Hesmans, Fabien Duchene, Christoph Paasch, Gregory Detal and Olivier Bonaventure, Are TCP Extensions Middlebox-proof?, Proceedings of the 2013 Workshop on Hot Topics in Middleboxes and Network Function Virtualization (HotMiddlebox), 2013, http://dx.doi.org/10.1145/2535828.2535830 |
| [Honda2011] | Michio Honda, Yoshifumi Nishida, Costin Raiciu, Adam Greenhalgh, Mark Handley, Hideyuki Tokuda, Is it still possible to extend TCP?, Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference, November 02-04, 2011, Berlin, Germany , http://dx.doi.org/10.1145/2068816.2068834 |