Subject: [multipathtcp] Testing Multipath TCP through real middleboxes

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 16 Apr 2013 17:24:41 +0200

Hello,

As you know, the design of Multipath TCP has been heavily influenced by 
various types of middleboxes that process/modify/... various fields of 
the IP/TCP packets. Multipath TCP is in theory capable of handling these 
middleboxes and either go through or at worst fallback to regular TCP.

In order to check this fallback mechanism, we ask your help to perform 
test behing as many real middleboxes as possible. To ease the testing, 
we have placed a modified kernel inside a virtualbox image, added 
several measurement scripts to automate the test and collect packet 
traces. The tests run on Linux and MacOS. They do not currently work on 
Windows. You can download the virtualbox image from :

http://multipath-tcp.org/pmwiki.php?n=Users.AboutMeasures

The script needs about 15 minutes to complete and you will have access 
to a trace of all the packets sent and received by your virtualbox and 
our server if you'd like to check the interference caused by your 
middleboxes. We'd appreciate tests in networks that are more likely to 
include middlboxes such as entreprise networks, WiFi hotspots or 
cellular networks.

 From a technical viewpoint, the tests use various applications 
including traceroute, ftp (to trigger NAT ALG), http, https, scp. We use 
multipath subflows (1 and 4) and a modified Multipath TCP kernel that 
provides more debugging and also three different schedulers. The first 
scheduler is the standard MPTCP scheduler that sends packets over the 
best subflows, a second scheduler that sends packets in strict round 
robin and a scheduler that copies each packet over all subflows to 
detect the impact of retransmissions.

Since Multipath TCP has never been deployed/tested on a large scale, 
these tests might trigger some alarms from firewalls/IPS/DPI boxes that 
could detect unknown behaviour. If this happens, please send a report to 
Fabien Duchene indicating the type of alarm.

All the data collected will be analysed and if the wg is interested, we 
could present the results of the analysis at the next IETF.

Thanks for your help,

Olivier Bonaventure

-- 
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be