Subject: [multipathtcp] Public MPTCP server running Linux MPTCP 0.4

From: Sébastien Barré <[email-masked]>
Date: Thu, 18 Nov 2010 18:05:04 +0100

Hi,

For those interested in playing with the latest version of MPTCP, it is 
possible to connect to our public MPTCP server:
http://mptcp.info.ucl.ac.be/

It allows you to test MPTCP through HTTP browsing, flash video, iperf or 
file download.

regards,

Sébastien.

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Thu, 18 Nov 2010 18:12:10 +0100

> http://mptcp.info.ucl.ac.be/

Hello Sébastien,

Can you tell me if your public MPTCP server is multi-homed and what are 
the characteristics of its interfaces (number and bit rate) ?
Thanks,

Bruno Mongazon

---

From: Dominik Kaspar <[email-masked]>
Date: Thu, 18 Nov 2010 18:26:27 +0100

Hi Sébastien,

$ iperf -c mptcp.info.ucl.ac.be -t180
------------------------------------------------------------
Client connecting to mptcp.info.ucl.ac.be, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local [...] connected with 192.135.167.249 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-180.1 sec  1.94 GBytes  92.5 Mbits/sec

It works, but what can we learn from this test?

Greetings,
Dominik

2010/11/18 Sébastien Barré <[email-masked]>:
> _______________________________________________
> multipathtcp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multipathtcp
>

---

From: Sébastien Barré <[email-masked]>
Date: Thu, 18 Nov 2010 18:40:16 +0100

Hi Bruno,

Op 18-11-10 18:12, Bruno Mongazon-Cazavet schreef:
>
> Hello Sébastien,
>
> Can you tell me if your public MPTCP server is multi-homed and what 
> are the characteristics of its interfaces (number and bit rate) ?
Of course ! I should have written that info on the web page, will do.
Anyway, here it is. The server has two public addresses. It is 
multihomed in that the ingress path is selected based on the address you 
use to reach it (192.135.167.249 or 192.135.168.249). The egress is 
single-path, though, except of course for the first few hops. Both 
interfaces are 100Mbps.

regards,

Sébastien.

---

From: Sébastien Barré <[email-masked]>
Date: Thu, 18 Nov 2010 18:53:46 +0100

Hi Dominik,

wow, you're fast ! See below:

> $ iperf -c mptcp.info.ucl.ac.be -t180
 From this one, probably not much. However, if you run a packet sniffer 
together with this, you should learn much more.
One nice thing with a public server is that it allows people to quickly 
check if MPTCP goes to them correctly, through the real Internet with 
the real middleboxes.

A big part of the protocol is devoted to make MPTCP run across the 
Internet as it is now. However it is good to know to what extent the 
goal is achieved or if some exotic middleboxes manage to stop us.

Other than this, you can check what perf you get. Our server has two 
interfaces (note that I just notice that I forgot to enable one, done 
now). But you can have as many as you want at your side.

Finally, sometimes people are just happy to see that a protocol is not 
only text on a paper, but actually a running box.

Of course, this does not replace a lab, but I think it is a tool that 
some people will find helpful, given that I have been requested to do it 
several times already.

Oh, yet another thing: You can try to crash it :-) . This is helpful for 
us as well (given we get the corresponding bug report), because it 
allows improving the code over and over.

Thanks for giving feedback so quickly !

Sébastien.
> Greetings,
> Dominik
>
>
> 2010/11/18 Sébastien Barré<[email-masked]>:
>> Hi,
>>

---

From: Dominik Kaspar <[email-masked]>
Date: Fri, 19 Nov 2010 17:51:52 +0100

Hi Sébastien,

If you mean the measured throughput was fast, yes. But I wasn't fast
in installing MPTCP... I have not actually installed it yet. I only
started an iperf test with a normal TCP connection assuming that it
might be of use to you.

However, I have just downloaded MPTCP v0.4 and the patched kernel is
now compiling... I'll try to run a real test on Monday with MPTCP
enabled on my side, too.

Cheers,
Dominik

2010/11/18 Sébastien Barré <[email-masked]>:
> check if MPTCP goes to them correctly, through the real Internet with the
> real middleboxes.
>
> A big part of the protocol is devoted to make MPTCP run across the Internet
> as it is now. However it is good to know to what extent the goal is achieved
> or if some exotic middleboxes manage to stop us.
>
> interfaces (note that I just notice that I forgot to enable one, done now).
> But you can have as many as you want at your side.
>
> Finally, sometimes people are just happy to see that a protocol is not only
> text on a paper, but actually a running box.
>
> Of course, this does not replace a lab, but I think it is a tool that some
> people will find helpful, given that I have been requested to do it several
> times already.
>
> Oh, yet another thing: You can try to crash it :-) . This is helpful for us
> as well (given we get the corresponding bug report), because it allows
> improving the code over and over.
>

---

From: Sébastien Barré <[email-masked]>
Date: Fri, 19 Nov 2010 17:59:07 +0100

Hi Dominik,

> now compiling... I'll try to run a real test on Monday with MPTCP
Nice ! Happy to know this.
cheers,

Sébastien.

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Mon, 22 Nov 2010 12:00:20 +0100

Hello Sébastien,

Thanks for your reply.
One more question:

Does MPTCP 0.4 implement "coupled congestion control" ?

I mean a way to use paths according to congestion control.
Thanks,

Bruno.

---

From: Sébastien Barré <[email-masked]>
Date: Mon, 22 Nov 2010 12:15:05 +0100

Hello Bruno,

> I mean a way to use paths according to congestion control.
0.4 does not contain it. 0.4 uses the default CC per subflow (which is 
cubic if you don't touch anything, but can be changed to whatever exists 
in the kernel, it is just not coupled).

However, Christoph Paasch is actively working on implementing CCC 
(Coupled Cong Control) for Linux MPTCP, and I think we should quickly be 
able to release a 0.5 with CCC in it.

regards,

Sébastien.

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Mon, 22 Nov 2010 18:05:11 +0100

Hello Sébastien,

Thanks for reply.
In addition could you tell me if there is any reason for MPTCP not to 
work properly with a PPP interface ?

Regards,
Bruno.

---

From: Sébastien Barré <[email-masked]>
Date: Mon, 22 Nov 2010 18:16:46 +0100

Hello Bruno,

> work properly with a PPP interface ?
AFAICT, a PPP interface has not necessarily an IP address. Since MPTCP 
uses IP addresses as path handles, I suspect the problem is there.
Probably it could be supported with minor modifications, though.

regards,
Sébastien.

---

From: Christoph Paasch <[email-masked]>
Date: Tue, 23 Nov 2010 10:02:56 +0100

Hi all,

in fact a properly configured PPP interface has an IP address. It is provided 
by the IPCP-Protocol, when setting up the ppp-link. Thus, in my opinion mptcp 
should work.

Feel free, to submit a bug-report with all the details at 
https://scm.info.ucl.ac.be/trac/mptcp/wiki/submit_patch

You will need to be registered to be able to do so. Just send an e-mail to 
Sébastien or me, then we will provide you a login/password.

I will try to reproduce your bug as soon as I have the time to, and see what's 
going wrong in the code.

Cheers,
Christoph

--
Christoph Paasch

Research Assistant
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP --- http://inl.info.ucl.ac.be/mptcp
Université Catholique de Louvain

www.rollerbulls.be
--

---

From: Bruno Mongazon-Cazavet <[email-masked]>
Date: Tue, 23 Nov 2010 10:30:47 +0100

Christophe,

> by the IPCP-Protocol, when setting up the ppp-link. Thus, in my opinion mptcp

Yes. My PPP interface has an IP address.

> Sébastien or me, then we will provide you a login/password.

Thanks, i will.

> I will try to reproduce your bug as soon as I have the time to, and see what's

I have perform a few tests as follows:

A)
-ppp path on
-traffic uses ppp
-add wlan path
-multipath seems ok

B)
-ppp and wlan paths are on
-traffic uses wlan path only

C)
-ppp and wlan paths are on
-traffic uses wlan path only
-cut wlan
-alternate ppp path not functioning

D)
-wlan path is on
-traffic uses wlan path
-add ppp path
-no multipath activated

Hope it helps.
Regards, Bruno.

---

From: Dominik Kaspar <[email-masked]>
Date: Tue, 23 Nov 2010 10:55:04 +0100

Hi Sébastien,

How does MPTCP merge the TCP segments that travel over different paths
back into a single flow? Is there a (large) buffer at the receiver
that compensates for packet reordering when the path latencies are
very different and segments get out of order?

Greetings,
Dominik

---

From: Sébastien Barré <[email-masked]>
Date: Tue, 23 Nov 2010 12:11:51 +0100

Hi Dominik,

> very different and segments get out of order?
Yes, exactly this. There is a connection-level socket structure with a 
receive queue and out-of-order queue, just like
any normal socket. That socket receives segments from the subflows as 
soon as they are in order at the subflow level.

To take into account varying path latencies, I have modified the "DRS" 
algorithm, used in the kernel to tune the size of the receive buffer, so 
that it reserves enough space to allow all pipes to be filled (including 
during fast rexmit).
Note however, that this tuning is capped at the system-wide configured 
max receive buffer size. So if that config variable is set too low, you 
may find that MPTCP is less efficient than single-path TCP, simply 
because it is lacking buffer space.

regards,

Sébastien.