Multipath TCP && TCP Loss Probe && Client Congestion Manager

Registered by Paul McKenney

Networking Topics:
1. Linux Kernel Implementation of Multipath TCP
2. TCP Loss Probe (TLP): fast recovery for tail losses
3. Client-based Congestion Manager for TCP

=== Linux Kernel Implementation of Multipath TCP ===
[Slides](http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/08/christoph-paasch-networking.pdf)

MultiPath TCP (short MPTCP) is an extension to TCP that allows a single TCP-connection to be split among multiple interfaces, while presenting a standard TCP-socket API to the applications. Splitting a data-stream among different interfaces has multiple benefits. Data-center hosts may increase their bandwidth; smartphones with WiFi/3G may seamlessly handover traffic from 3G to WiFi,... MultiPath TCP works with unmodified applications over today's Internet with all its middleboxes and firewalls.

A recent Google Techtalk about MultiPath TCP is available at [1]

In this talk I will first present the basics of MultiPath TCP and how it works and show some of the performance results we obtained with our Linux Kernel implementation (freely available at [2]). Second, I will go into the details of our implementation in the Linux Kernel, and our plans to try submitting the MPTCP-patches to the upstream Linux Kernel.

[1] http://www.youtube.com/watch?v=02nBaaIoFWU
[2] http://mptcp.info.ucl.ac.be

Topic Lead: Christoph Paasch <email address hidden>

=== TCP Loss Probe (TLP): fast recovery for tail losses ===

[Slides](http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/08/tcp_loss_recovery_nandita.pdf)

Fast recovery (FR) and retransmission timeouts (RTOs) are two mechanisms in TCP for detecting and recovering from packet losses. Fast recovery detects and repairs losses quicker than RTOs, however, it is only triggered when connections have a sufficiently large number of packets in transit. Short flows, such as the vast majority of Web transfers, are more likely to detect losses via RTOs which are expensive in terms of latency. While a single packet loss in a 1000 packet flow can be repaired within a round-trip time (RTT) by FR, the same loss in a one packet flow takes many RTTs to even detect. The problem is not just limited to short flows, but more generally losses near the end of transfers, aka tail losses, can only be recovered via RTOs.

In this talk, I will describe TCP Loss Probe (TLP) - a mechanism that allows flows to detect and recover from tail losses much faster than an RTO, thereby speeding up short transfers. TLP also unifies the loss recovery regardless of the "position" of a loss, e.g., a packet loss in the middle of a packet train as well as at the tail end will now trigger the same fast recovery mechanisms. I will also describe experimental results with TLP and its impact on Web transfer latency on live traffic.

Topic Lead: Nandita Dukkipati <email address hidden>
Nandita is a software engineer at Google working on making Networking faster for Web traffic and Datacenter applications. She is an active participant at the IETF and in networking research. Prior to Google she obtained a PhD in Electrical Engineering, Stanford University.

=== Client-based Congestion Manager for TCP ===
Today, one of the most effective ways to improve the performance of chatty applications is to keep TCP connection open as long as possible to save the overhead of SYN exchange and slow start on later requests. However, due to Web domain sharing, NAT boxes often run out of ports or other resources and resort to dropping connections in ways that make later connections even slower to start.

A better solution would be to enable TCP to start a new connection as quickly as restarting an idle connection. The approach is to have a congestion manager (CM) on the client that constantly learns about the network and adds some signaling information to requests from the client, indicating how the server can reply most quickly, for example by providing TCP metrics similar to today's destination cache. Such a CM could even indicate to the server what type of congestion control to use, such as the relentless congestion control algorithm such that opening more connections does not gain advantage on aggregate throughput. It also allows receiver-based congestion control which opens new possibilities to control congestion. The Linux TCP metrics have similar concept but there is a lot of room for improvement.

Topic Lead: Yuchung Cheng <email address hidden>
Yuchung Cheng is a software engineer at Google working on the Make-The-Web-Faster project. He works on the TCP protocol and the Linux TCP stack focusing on latency. He has contributed Fast Open, Proportional Rate Reduction, Early Retransmit implementation in Linux kernel and wrote a few papers and IETF drafts of them. He has also contributed to rate-limiting Youtube streaming and the cwnd-persist feature of the SPDY protocol.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
Tom Herbert
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.