3 ms·

The article emphasizes that TCP congestion control can make TCP underperform with respect to the actual available bandwidth. So True and So Frustrating! But it

The article emphasizes that TCP congestion control can make TCP underperform with respect to the actual available bandwidth. So True and So Frustrating! But it doesn't seem to talk about the virtues of congestion control - the primary one being it prevents the collapse of the Internet. Reacting to packet loss by just trying harder results in nothing but a network filled with doomed packets. This is not theoretical - before Van Jacobson that was the Internet. I'm not defending the status quo nor TCP - TCP has deep problems figuring out what is really loss. and it speeds up too slowly but still doesn't manage to slow down when it should resulting in induced delay. But the mere fact that is worried about congestion (not just unreliability - one result of congestion) and sharing the channel isn't its problem. have a look at QUIC, ledbat, Minion and the recent IETF TAPS BoF for work going on improving transport options in these areas. Its just the wrong takeaway to read that article and say "UDP is better because it doesn't have congestion control" - you need to consider CC in any reliable UDP based transport you roll too. rfc 5405 provides some advice (http://tools.ietf.org/html/rfc5405 http://tools.ietf.org/html/rfc5405) - its a little dated but still useful.

twic 13y ago
Excellent point, awesome RFC! It's worth reproducing this point from the abstract, which makes the same point you do: > Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. It's a shame that the internet requires this kind of good behaviour from individual hosts, because it leaves it vulnerable to buggy or malicious nodes. But as long as it does, it's essential that users of UDP know about this.
- zurn 13y ago
  On the other hand it's very fortunate that the internet architecture is what it is, because the "dumb network, end-to-end protocols" design principle has enabled deployment of new and improved protocols and applications without touching the network routers, which would have been very difficult to coordinate. Might be difficult to believe now but this was a radical idea at the time. (Or at least enabled it for ~25 years until NAT put a damper on it - let's all keep our thumbs up for IPv6).
zurn 13y ago
> TCP has deep problems figuring out what is really loss. and it speeds up too slowly but still doesn't manage to slow down when it should resulting in induced delay TCP is really pretty reasonable. Fast retransmit/fast recovery lets TCP eat up small packet losses without entering congestion control. Plus everybody recently upped their intial congestion window to 10. Also, there was an attempt to deploy ECN (explicit congestion notification) for TCP, but net equipment vendors and providers resisted deploying it. It was specced as an official standards track TCP feature in 2001.
- lucian1900 13y ago
  The one major problem TCP currently has is the assumption that packet loss is always caused by congestion, which is a simplification that proves most damaging over radio links. There are smaller problems (but still worth fixing), like TLS over TCP doing a few more round trips more than necessary. QUIC tackles this in particular.
  - fulafel 13y ago
    How would you change TCP to improve its behaviour here? Current radio link layers (3g, wifi) are designed to play nicely with TCP. Their below-IP layers do their own retransmissions to make up for radio link issues. They have to take into account radio channel congestion - it doesn't help if everyone on the channel just starts shouting louder and repeating themselves.

twic 13y ago

Excellent point, awesome RFC! It's worth reproducing this point from the abstract, which makes the same point you do: > Because congestion control is critical to the stable operation of the Internet, applications and upper-layer protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic. It's a shame that the internet requires this kind of good behaviour from individual hosts, because it leaves it vulnerable to buggy or malicious nodes. But as long as it does, it's essential that users of UDP know about this.

zurn 13y ago
On the other hand it's very fortunate that the internet architecture is what it is, because the "dumb network, end-to-end protocols" design principle has enabled deployment of new and improved protocols and applications without touching the network routers, which would have been very difficult to coordinate. Might be difficult to believe now but this was a radical idea at the time. (Or at least enabled it for ~25 years until NAT put a damper on it - let's all keep our thumbs up for IPv6).

zurn 13y ago

> TCP has deep problems figuring out what is really loss. and it speeds up too slowly but still doesn't manage to slow down when it should resulting in induced delay TCP is really pretty reasonable. Fast retransmit/fast recovery lets TCP eat up small packet losses without entering congestion control. Plus everybody recently upped their intial congestion window to 10. Also, there was an attempt to deploy ECN (explicit congestion notification) for TCP, but net equipment vendors and providers resisted deploying it. It was specced as an official standards track TCP feature in 2001.

lucian1900 13y ago
The one major problem TCP currently has is the assumption that packet loss is always caused by congestion, which is a simplification that proves most damaging over radio links. There are smaller problems (but still worth fixing), like TLS over TCP doing a few more round trips more than necessary. QUIC tackles this in particular.
- fulafel 13y ago
  How would you change TCP to improve its behaviour here? Current radio link layers (3g, wifi) are designed to play nicely with TCP. Their below-IP layers do their own retransmissions to make up for radio link issues. They have to take into account radio channel congestion - it doesn't help if everyone on the channel just starts shouting louder and repeating themselves.