UDP BitTorrent Will Destroy The Interwebs! > You called it yourself, Karl

You called it yourself, Karl

reply to BubbaDude

reply to Combat Chuck
There is equipment out there that depends on the congestion management behavior of TCP. For instance, routers utilize algorithms such as Random Early Detection (RED) to start dropping packets based on queue depth. RED relies on the congestion management properties of TCP. I'm not talking about "throttling" here; rather, I'm talking about the simple fact that a router can only buffer so many packets that are destined for a congested link. Eventually, a router has to start dropping, and RED is one way of deciding what to drop.

If everyone decides to "roll their own" congestion management and layer it on top of UDP, there is a potential for some big problems as, in some cases, algorithms such as RED may not even be invoked on UDP packets. In the short term, the only solution may be a big hammer that impacts all UDP traffic.

I am not saying that TCP directly interacts with anything other than another endpoint to accomplish what you described: to avoid bombarding an overloaded segment.

What I am saying is that routers, employing algorithms such as RED, are designed to operate in the presence of TCP congestion avoidance, since TCP has been up until now the dominate protocol.

Specifically, RED results in early dropping of packets (as an egress queue is approaching full, but before it is completely full) which would normally cause a TCP transmitter's congestion window to shrink as it does not receive an ACK for the dropped packet. When packets for multiple TCP connections (presumably employing similar congestion avoidance) are passing through the same egress queue, all of the connections should throttle back similarly and the available bandwidth is shared close to fairly.

UDP, by itself, has no congestion avoidance. So a mix of UDP and TCP in the same egress queue will place TCP at a disadvantage as TCP will throttle back as packets are dropped while UDP keeps blasting away. Of course, uTP supposedly does incorporate congestion avoidance (layered on top of UDP), but it may or may not play fairly with concurrent TCP traffic.

Then in that case the problem has nothing at all to do with the protocol and everything to do with an overloaded link; a problem TCP congestion avoidance isn't going to solve.

Again TCP congestion avoidance has almost nothing to do with congestion avoidance; it has to do with scaling back TCP's response to allow the link to recover from a transient congestion situation due to the fact that TCP will begin to retransmit data effectively doubling the bandwidth used. If the link is constantly saturated such that this even becomes an issue, then the problem is a problem with the provider and not a problem with the protocol.
--
The world’s elusive, remember
where love's the leaf
faith, the river
what's born as flame dies in ember
see for yourself!

Consider this very simple scenario:

Host 1 has a gigabit NIC plugged into a gigabit switch.

Host 2 has a gigabit NIC plugged into the same gigabit switch.

Host 3 has a 10 Mbit NIC plugged into the same gigabit switch.

Ethernet flow control is disabled across the board.

Host 1 opens a TCP connection to Host 3. Obviously, host 1 can transmit packets at 1 Gbit, but they will eventually be dropped by the switch since Host 3 is linked at 10 Mbit. TCP will throttle the transmit bandwidth down to 10 Mbit (or slower). This is not a "transient" condition, and you cannot say that something is "wrong" with the network... it is what it is.

Now, host 2 opens a TCP connection to Host 3 (so we have two open connections to host 3). TCP on Host 1 and Host 2 will eventually slow down to roughly 5 Mbits/sec on each host (due to TCP's congestion window), effectively sharing the 10 Mbit link between the switch and Host 3.

This is not a "transient" situation, and TCP's congestion avoidance definitely comes into play here.

No, you are wrong -- unless you drive with a foot on the accelerator and another on the brake at the same time. Did you even read what I wrote? I guess not.

If not congestion avoidance, tell me how TCP deals with a slow (not necessarily congested) link in the path between between two hosts that are participating in a TCP connection.