[multipathtcp] Testing Multipath TCP through real middleboxes

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Tue, 16 April 2013 15:24 UTC

Message-ID: <516D6D39.70705@uclouvain.be>
Date: Tue, 16 Apr 2013 17:24:41 +0200
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: multipathtcp <multipathtcp@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [multipathtcp] Testing Multipath TCP through real middleboxes
Precedence: list
Reply-To: Fabien Duchêne <fabien.duchene@uclouvain.be>

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

[multipathtcp] Testing Multipath TCP through real… Olivier Bonaventure