Coupled Congestion Control for MPTCP - IETF · Coupled Congestion Control for MPTCP Mark Handley, Damon Wischik, Costin Raiciu

CoupledCongestion Controlfor MPTCP

Mark Handley,Damon Wischik,Costin Raiciu

Resource pooling means the network is better able toaccommodate a surge in traffic

oralossofcapacity

byshi/ingtrafficandthereby“diffusing”conges9onacrossthenetwork.

Linking the subflows can reduce the traffic sent onthe more congested path, and so balance load.

The subflow that has the smaller window increases less anddecreases more.

In our initial experiments with multipath congestioncontrol, we investigated a simple setup with twopaths, each with the same packet drop probability.

Two separate (uncoupled)TCP congestion controllersuse the two paths equally

A naive coupled congestion controller,inspired by Kelly+Voice (2005), flapsfrom one path to the other

timethroughput onbottom path

throughput ontop path

The noisy nature of congestion feedback makes itdifficult to estimate congestion levels.

▼ ▼▼ ▼ ▼ ▼▼ ▼▼

▲ ▲ ▲ ▲ ▲ ▲ ▲ ▲▲▲ ▲ ▲ ▲

▼ ▼ ▼▼ ▼▼ ▼randomdrops

randomdrops

Thetoplinkissocongested!

Ibe@erswitchtothebo@omlink.

Nowthebo@omlinkismorecongested!

loss rate 1%

loss rate 1%

▲▲

* * *

• But the longer we average, the worse we are at reactingpromptly when congestion truly does change.

(This is why TCP probes continuously, rather thanaccumulating an ever more accurate average over itsentire run-time.)

We could alleviate flappiness by averaging over alonger timescale

TheZenofresourcepoolingInorderformul9pathconges9oncontroltopoolresourceseffec9vely,itshouldnottrytoohardtopoolresources—insteadofusingonlythepathsthatcurrentlylookleast‐congesteditshouldinsteadmaintainequipoise,i.e.itshouldbalanceitstrafficequallybetweenpathstotheextentnecessarytosmoothouttransientfluctua9onsinconges9onandtobereadytoadapttopersistentchanges.

We devised a parameterized family of multipathcongestion control algorithms, indexed byφϵ[0,2], to investigate the tradeoff between loadbalancing and equipoise.

φ0 2

“fullycoupled”subflows

uncoupledregular

TCPflows

varying degreesof coupling

We devised a parameterized family of multipathcongestion control algorithms, indexed byφϵ[0,2], to investigate the tradeoff between loadbalancing and equipoise.

φ

0 2

“fullycoupled”

uncoupled

φ

Decreasing φ improves resource pooling andeffectively moves traffic away from congestion.

φ“fullycoupled” uncoupled

With varying background traffic, low values of φmove so much traffic off the more congestedpath that we miss opportunities to send.

φ“fullycoupled” uncoupled

On/off flows

Long lived flows

Neither extreme for φ seems desirable. Howabout intermediate values?

φ =1 is aninterestingcase.

• Reasonableload balancing,goodequipoise.

• Very simplealgorithm.

φ =1 is an algorithm that just links the increases.

Assign a weight to each link, and run a weighted version ofthe φ=1 algorithm. We have an adaptive algorithm forchoosing the weights:

– the multipath flow gets as least as much throughputas if it used the best single path

– the multipath flow takes no more bandwidth on anylink than a single-path TCP would.

We tweaked the φ=1 algorithm, to ensurefairness with TCP.

morecongestedshort RTT

less congestedlong RTT

wifithrough-put [Mb/s]

3Gthrough-put [Mb/s]

time[min]

We have a working implementation: mobile host

wifi

3GlaptopwithmultipathTCP

serverwithmultipathTCP

Clients

Server

15TCPs

5TCPs

10MPTCPs

We have a working implementation:Resource pooling with a multihomed server