5 ms·

They lost me when it became obvious that PCC doesn't interoperate very well with "normal" TCP (let's call it reno-tcp[1]). TCP is not the optimal solution and P

by baruch 12y ago

They lost me when it became obvious that PCC doesn't interoperate very well with "normal" TCP (let's call it reno-tcp[1]). TCP is not the optimal solution and PCC may very well be better but there is just no way to use a new and unfair-to-reno and ignore all consequences. There must be some safeguards to handle all the older systems (be they routers, embedded systems, IoT or just plain old Win XP machines). It is an interesting approach and an interesting research that drives us forward but it is in no way a practical approach. They implemented this thing in UDT, if they can come up with a Linux patch that would be awesome for real world testing and implementation verification. [1] Reno is the original TCP congestion control, New-Reno was the most common adaptation for a long time. These days CUBIC is the default in Linux, Windows has their own algorithm. All of these behave in a very similar way to the old Reno, they all have the basic structure of AIMD - Additional Increase, Multiplicative Decrease (slowly increasing on no signal and fast decrease on loss signal). in the case of CUBIC and H-TCP the slow increase is not very slow and the fast decrease was slowed down to handle very high speed links and high latency (high bandwidth delay product).

jorangreef 12y ago
Further on in section 4.3 they actually discuss TCP friendliness in more detail and show that 1 PPC flow (with often more than 10x throughput) is more friendly to 1 unselfish TCP flow than 10 selfish TCP flows. Also, PPC is not too far ahead of SABUL (UDT), and SABUL has been shown to have excellent fairness when compared with TCP.
- baruch 12y ago
  They only compared with multi-TCP, and while this is a method that can be used to utilize high BDP with AIMD-TCP it is not a common use case. In most cases you just have a browser with independent streams or a bittorrent client with quite a few somewhat short-lived connections to a wide range of locations and also just a plain single transfer from a remote server to upgrade your Debian system. These are all not quite multi-TCP and there was no real mention of fairness of PCC against a single TCP stream, even of the CUBIC form, not to mention just plain old NewReno. I can't tell if it's really unfair as I didn't test it myself, but they hint that there is a wide gap between PCC and NewReno or even CUBIC. The algorithm as I understand it also seems to imply that PCC will dominate a NewReno stream with ease, especially when PCC is an established connection and the NewReno is only starting up as the PCC will feel a small bump of losses, probably not do much about it (i.e. not reduce rate by much) and the NewReno generated packet losses will fly under the radar of PCC. At least that's the feeling I get from reading the paper, again, no idea about actual behavior but I'm no longer paid to look at packet traces of congestion control algorithms. (Shame, it was fun while it lasted :-)
  - jorangreef 12y ago
    I think in practice it will work well, given that bufferbloat is often the cause of congestion on a home network. TCP itself is usually quadratically impaired when it comes to reacting and backing off in the face of increasing latency caused by buffers (uploading a large file through Dropbox or Google Drive will most likely cause ping times on other machines on the same network to degrade from milliseconds to seconds). When it comes to bufferbloat, a single TCP flow can dominate all others and be highly unfair because TCP's congestion algorithms are so slow to react (they often only react to packet loss and not latency). LEDBAT and delay-based congestion algorithms were designed to handle bufferbloat well, and PCC is essentially a superset of these, taking into account loss rate and throughput in addition to just delay.
modong 12y ago
This actually can lead to a very interesting discussion about TCP friendliness, which I didn't have space to elaborate in paper: 1. The Trend of Selfish Applications: TCP's poor performance is not only an object of research study. More and more applications have chosen to ignore the notion of TCP friendliness and use selfish application-level optimization techniques such as opening many parallel connections (as in modern web browsers and GridFTP), contacting multiple servers in parallel (in BitTorrent), or modifying TCP to use a very large initial window size. In fact, some CDN providers use selfish optimization of TCP to accelerate data transfer from CDN servers to end users on the public Internet. This trend indicates that often, applications prefer higher performance regardless of potential TCP unfriendliness. Although we recommend use of PCC only when it is isolated from legacy TCP, it is likely that due to PCC's robust high performance, some or many users (especially those suffering in network environments that are challenging for TCP) will use PCC as another selfish performance optimization technique. Legacy TCP users, on the other hand, will unfortunately suffer from performance degradation when competing with PCC and other selfish optimization techniques under FIFO queue based network. What happens next in this tussle? One possibility is a slow arms race towards selfish high performance rate control. If done through adoption of PCC using our safe utility function, it will actually avoid a ``tragedy of the commons'' situation as we have shown. But more immediately, network owners (ISPs) will likely take action to avoid complaints. 2.ISP response to selfishness: o maintain legacy TCP users' satisfaction, network operators can respond to selfishness by deploying flow-level or customer-level resource isolation at the point of congestion. Of course this requires hardware support, but it is feasible for two reasons. First, unlike protocols like XCP and RCP, an ISP can deploy resource isolation as a local change at an individual congested device, requiring no signaling or packet header changes or explicit feedback to end-hosts. Second, the belief that per-flow FQ is infeasible for high speed switching hardware is now a misconception, with merchant silicon supporting hundreds of thousands of flows at hundred-gigabit speeds. Even by 1999, early implementations used limited hardware (less than 33Mhz FPGA or CMOS) to support FQ on multi-gigabit links. Today, an off-the-shelf EZchip NP-4 supports 256K flows with 100 Gbit throughput, VSC2202 supports 500K flows with Gigabit Ethernet throughput, and so on. We obtained a quote of $25 for the VSC2202, of which the cost of the FQ logic itself is only a fraction.} In certain cases resource isolation is already deployed; cellular networks for example use separate queues for each user. 3. Towards a new architecture? The above trends suggest that in-network resource isolation may be increasingly deployed as a consequence of the continuous tussle between applications optimising selfishly and ISPs protecting their infrastructure with means that are feasible to deploy. We argue that this process is actually (slowly) evolving the Internet towards a fundamentally better architecture: end-hosts focus on optimising their desired performance, while the network's job is to isolate resources across users. This architecture offers a clean separation of concerns. End-hosts in this architecture deal with what they can directly observe and control, leading to simple, clean designs and the flexibility to express their heterogenous objectives and even safely evolve to new end-to-end protocols. Similarly, the network deals with what it directly observes and cares about, i.e., competition between users or flows. Our evaluation has already demonstrated the flexibility that results from this architecture.
brighten 12y ago
baruch -- I'll add a bit to what Mo said. There are many systems, including major services from large companies that we all use every day, that use alternate or unfriendly TCPs behind the scenes (and sometimes in the public Internet). So while we wouldn't recommend deploying PCC Internet-wide without a good deal more development and testing, it's quite practical and useful today for many systems such as where PCC can be isolated from TCP.

by baruch 12y ago

jorangreef 12y ago

Further on in section 4.3 they actually discuss TCP friendliness in more detail and show that 1 PPC flow (with often more than 10x throughput) is more friendly to 1 unselfish TCP flow than 10 selfish TCP flows. Also, PPC is not too far ahead of SABUL (UDT), and SABUL has been shown to have excellent fairness when compared with TCP.

baruch 12y ago
They only compared with multi-TCP, and while this is a method that can be used to utilize high BDP with AIMD-TCP it is not a common use case. In most cases you just have a browser with independent streams or a bittorrent client with quite a few somewhat short-lived connections to a wide range of locations and also just a plain single transfer from a remote server to upgrade your Debian system. These are all not quite multi-TCP and there was no real mention of fairness of PCC against a single TCP stream, even of the CUBIC form, not to mention just plain old NewReno. I can't tell if it's really unfair as I didn't test it myself, but they hint that there is a wide gap between PCC and NewReno or even CUBIC. The algorithm as I understand it also seems to imply that PCC will dominate a NewReno stream with ease, especially when PCC is an established connection and the NewReno is only starting up as the PCC will feel a small bump of losses, probably not do much about it (i.e. not reduce rate by much) and the NewReno generated packet losses will fly under the radar of PCC. At least that's the feeling I get from reading the paper, again, no idea about actual behavior but I'm no longer paid to look at packet traces of congestion control algorithms. (Shame, it was fun while it lasted :-)
- jorangreef 12y ago
  I think in practice it will work well, given that bufferbloat is often the cause of congestion on a home network. TCP itself is usually quadratically impaired when it comes to reacting and backing off in the face of increasing latency caused by buffers (uploading a large file through Dropbox or Google Drive will most likely cause ping times on other machines on the same network to degrade from milliseconds to seconds). When it comes to bufferbloat, a single TCP flow can dominate all others and be highly unfair because TCP's congestion algorithms are so slow to react (they often only react to packet loss and not latency). LEDBAT and delay-based congestion algorithms were designed to handle bufferbloat well, and PCC is essentially a superset of these, taking into account loss rate and throughput in addition to just delay.

modong 12y ago

This actually can lead to a very interesting discussion about TCP friendliness, which I didn't have space to elaborate in paper: 1. The Trend of Selfish Applications: TCP's poor performance is not only an object of research study. More and more applications have chosen to ignore the notion of TCP friendliness and use selfish application-level optimization techniques such as opening many parallel connections (as in modern web browsers and GridFTP), contacting multiple servers in parallel (in BitTorrent), or modifying TCP to use a very large initial window size. In fact, some CDN providers use selfish optimization of TCP to accelerate data transfer from CDN servers to end users on the public Internet. This trend indicates that often, applications prefer higher performance regardless of potential TCP unfriendliness. Although we recommend use of PCC only when it is isolated from legacy TCP, it is likely that due to PCC's robust high performance, some or many users (especially those suffering in network environments that are challenging for TCP) will use PCC as another selfish performance optimization technique. Legacy TCP users, on the other hand, will unfortunately suffer from performance degradation when competing with PCC and other selfish optimization techniques under FIFO queue based network. What happens next in this tussle? One possibility is a slow arms race towards selfish high performance rate control. If done through adoption of PCC using our safe utility function, it will actually avoid a ``tragedy of the commons'' situation as we have shown. But more immediately, network owners (ISPs) will likely take action to avoid complaints. 2.ISP response to selfishness: o maintain legacy TCP users' satisfaction, network operators can respond to selfishness by deploying flow-level or customer-level resource isolation at the point of congestion. Of course this requires hardware support, but it is feasible for two reasons. First, unlike protocols like XCP and RCP, an ISP can deploy resource isolation as a local change at an individual congested device, requiring no signaling or packet header changes or explicit feedback to end-hosts. Second, the belief that per-flow FQ is infeasible for high speed switching hardware is now a misconception, with merchant silicon supporting hundreds of thousands of flows at hundred-gigabit speeds. Even by 1999, early implementations used limited hardware (less than 33Mhz FPGA or CMOS) to support FQ on multi-gigabit links. Today, an off-the-shelf EZchip NP-4 supports 256K flows with 100 Gbit throughput, VSC2202 supports 500K flows with Gigabit Ethernet throughput, and so on. We obtained a quote of $25 for the VSC2202, of which the cost of the FQ logic itself is only a fraction.} In certain cases resource isolation is already deployed; cellular networks for example use separate queues for each user. 3. Towards a new architecture? The above trends suggest that in-network resource isolation may be increasingly deployed as a consequence of the continuous tussle between applications optimising selfishly and ISPs protecting their infrastructure with means that are feasible to deploy. We argue that this process is actually (slowly) evolving the Internet towards a fundamentally better architecture: end-hosts focus on optimising their desired performance, while the network's job is to isolate resources across users. This architecture offers a clean separation of concerns. End-hosts in this architecture deal with what they can directly observe and control, leading to simple, clean designs and the flexibility to express their heterogenous objectives and even safely evolve to new end-to-end protocols. Similarly, the network deals with what it directly observes and cares about, i.e., competition between users or flows. Our evaluation has already demonstrated the flexibility that results from this architecture.

brighten 12y ago

baruch -- I'll add a bit to what Mo said. There are many systems, including major services from large companies that we all use every day, that use alternate or unfriendly TCPs behind the scenes (and sometimes in the public Internet). So while we wouldn't recommend deploying PCC Internet-wide without a good deal more development and testing, it's quite practical and useful today for many systems such as where PCC can be isolated from TCP.