Subject: [iccrg] New MPTCP congestion control algorithm

From: "Walid, Anwar I (Anwar)" <[email-masked]>
Date: Wed, 9 Jul 2014 02:01:50 +0000

Hi:

Please find the paper "Multipath TCP: Analysis, Design and Implementation" at http://arxiv.org/pdf/1308.3119v2.pdf.

This paper presents a new MPTCP congestion control algorithm and the theory behind it. The algorithm is implemented in the Linux kernel and its performance is compared with prior algorithms. Comments are welcome.

Best,

Anwar Walid

---

From: Dave Taht <[email-masked]>
Date: Tue, 8 Jul 2014 20:28:53 -0700

5 questions:

1) I see figures for RTT, but not for buffer size. (Admittedly my eyes
glazed over at all the math.)

2) Did you try simultaniously bidirectional traffic (basically a
variant of the classic edge bufferbloat test: one mptcp flow up, one
down, one ping)
What is the induced latency on your tests? Modifications like capping
the decrement of the window size make me nervous.

3) What tools and scripts were used to generate the traffic?

4) Is there ECN support in the mptcp code yet? (the lack thereof was
what has stopped me from doing anything with it, but the potential in
doing mptcp over a multi-homed homenet network keeps me wanting to try
it)

5) Tried any of the new AQM+packet schedulers yet? (fq_codel, pie, etc)

As a general note, wifi performance today can have induced latencies
*well* in excess of the 10ms you use here...

On Tue, Jul 8, 2014 at 7:01 PM, Walid, Anwar I (Anwar)
<[email-masked]> wrote:
> Hi:
>
>
>
> Please find the paper “Multipath TCP: Analysis, Design and Implementation”
> at http://arxiv.org/pdf/1308.3119v2.pdf.
>
>
>
> This paper presents a new MPTCP congestion control algorithm and the theory
> behind it. The algorithm is implemented in the Linux kernel and its
> performance is compared with prior algorithms. Comments are welcome.
>
>
>
> Best,
>
>
>
> Anwar Walid
>
>
>
>
>
>
> _______________________________________________
> iccrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/iccrg
>

-- 
Dave Täht

NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article

---

From: "Walid, Anwar I (Anwar)" <[email-masked]>
Date: Wed, 9 Jul 2014 04:26:42 +0000

Btw this message is from the irtf not ietf- I sent the paper  to both. But Steven's point is still valid.
Anwar

Sent from my iPhone

---

From: Christoph Paasch <[email-masked]>
Date: Wed, 9 Jul 2014 11:06:58 +0200

Hi Dave,

> doing mptcp over a multi-homed homenet network keeps me wanting to try

in the Linux implementation of MPTCP, ECN has always been supported.

Cheers,
Christoph

---

From: "Walid, Anwar I (Anwar)" <[email-masked]>
Date: Thu, 10 Jul 2014 04:22:13 +0000

Hi Dave,

Thanks for your questions/comments. Responses are embedded.
Best,

anwar

-----Original Message-----
From: Dave Taht [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2014 11:29 PM
To: Walid, Anwar I (Anwar)
Cc: [email-masked]; [email-masked]; Qiuyu Peng; [email-masked]; Steven Low; HWANG, JAE HYUN (JAE HYUN); [email-masked]
Subject: Re: [iccrg] New MPTCP congestion control algorithm

5 questions:

1) I see figures for RTT, but not for buffer size. (Admittedly my eyes glazed over at all the math.)
A: We used a default value of Dummynet for the buffer size of 50 packets.

2) Did you try simultaniously bidirectional traffic (basically a variant of the classic edge bufferbloat test: one mptcp flow up, one down, one ping) What is the induced latency on your tests? Modifications like capping the decrement of the window size make me nervous.
A: We did not do that yet. Bidirectional throughput measurement is supported by Iperf, so it should be easy to test.

3) What tools and scripts were used to generate the traffic?
A: Our measurement (traffic generation) tool was Iperf. We made a simple shell script with 'ssh' to generate traffic from the remote host.

4) Is there ECN support in the mptcp code yet? (the lack thereof was what has stopped me from doing anything with it, but the potential in doing mptcp over a multi-homed homenet network keeps me wanting to try
it)
A: As Christoph mentioned, MPTCP implementation already supports ECN.

5) Tried any of the new AQM+packet schedulers yet? (fq_codel, pie, etc)
A: Not yet. Interesting direction.

6) Did you try asymmetric links?
Not yet, and would be quite interesting to test. We tried asymmetric paths where some are fast and others are slow, but they are all with symmetric links.

---

From: Dave Taht <[email-masked]>
Date: Thu, 10 Jul 2014 23:28:10 -0700

> A: We used a default value of Dummynet for the buffer size of 50 packets.

The default packet limit on linux is 1000 packets. (which can include
TSO sized 64k "packets"). Additionally, below that, the tx-rings on
ethernet are often in the 256 entry range, now moderated by "byte
queue limits" on certain ethernet drivers, which caps the tx ring at X
amount of bytes determined by what can keep the hardware busy.

Was TSQ emulated at all? tcp small queues, which makes hosts (but not
routers) behave a little better.

Cisco switches are often ~2800 packets for gigE capable stuff. DSLAMs
and CMTSes use bytes (64k-256k), the CMTSes I've seen are largely
configured with 512KB (cablelabs uses 256KB in their emulations).
DOCSIS 2.0 cablemodems typically 128K, DOCSIS 3.0 typically 256KB. I
don't know what enodebs use, judging from the RTTs, It's quite a lot.
Wifi is even worse, with 4 hw queues of  1000 packets, and underlying
driver buffering in the 128 per hw queue (but thankfully, no GSO or
TSO)

I would be comforted knowing your modifications to capping AIMD
weren't going to break anything if you were to rerun your simulations
with some of these real world packet limits baked in,the results of
the different cc controllers ought to be "interesting".

You can use a byte limit in linux by using the "bfifo limit 64k"
qdisc. a packet fifo is pfifo limit 1280, and all the nifty new aqm
and packet scheduling code for sfq, fq_codel and pie started to get
baked in 3.6 and later.

> A: We did not do that yet. Bidirectional throughput measurement is supported by Iperf, so it should be easy to test.

That, plus a simultaneous ping is often useful.

> A: Our measurement (traffic generation) tool was Iperf. We made a simple shell script with 'ssh' to generate traffic from the remote host.

For more complex measurements and plots, see netperf-wrapper on github.

> A: As Christoph mentioned, MPTCP implementation already supports ECN.

I guess I had misread some previous information. It's just the ns2
model that lacks support for ecn, port numbers, hystart, etc.

I see the current mptcp release is linux 3.11 based. Any ideas as to
when a 3.14 or later release will arrive?

> Not yet, and would be quite interesting to test. We tried asymmetric paths where some are fast and others are slow, but they are all with symmetric links.

The vast majority of paths along the edge of the internet are
asymmetric, not only in the DSL and Cable cases, but wireless
connections tend to have a better MCS rate from the AP to the
laptop/tablet than from the laptop/tablet (due to antennas, mostly).

I have been working as part of the GSOC summer of code to get a set of
ns3 models that let asymmetric rates be better emulated.

-- 
Dave Täht

---

From: Christoph Paasch <[email-masked]>
Date: Fri, 11 Jul 2014 11:09:44 +0200

Hi Anwar & Dave,

> the different cc controllers ought to be "interesting".

Anwar, you might take a look at 
http://inl.info.ucl.ac.be/publications/benefits-applying-experimental-design-improve-multipath-tcp
which takes an "experimental design" approach to evaluate MPTCP.
It allows to cover a much larger parameter-space.

> when a 3.14 or later release will arrive?

In the next coming weeks we will make a release based on 3.14.

Cheers,
Christoph

---

From: "Walid, Anwar I (Anwar)" <[email-masked]>
Date: Mon, 21 Jul 2014 12:25:23 +0000

Hi:

A new I-D has been submitted: draft-walid-mptcp-congestion-control-00.txt 

http://tools.ietf.org/html/draft-walid-mptcp-congestion-control-00

Best,

anwar