At 08:34 p.m. 07/07/03 -0700, you wrote:
The point is that if X sends 1024 and Y tries to send 1 but fails, the firewall cannot tell and therefore can't do anything about it.
Which firewall? In case of having it doesn't have anything to do here. Let's put aside any coercive device to concentrate in TCP behavior.
I'm not nearly as confident as you in the tcp mechanisms. First, the upstream routers might favor one flow over another for whatever reason. Second, even if tcp works as you'd like, the convergence will be much faster if there's some unused bandwidth.
Perhaps you are right, perhaps you are not. Who knows? TCP behavior is a funny game with very clear rules. One of them is: first one that loses a packet has to cut its rate by half. Who's lucky? Do you know? Packets are dropped by routers in a random selection process. TCP flows are always fighting to increase their shares. Sometime one of them is ahead, but, it loses a packet. Like Monopoly. Walk back seven step, man!! you are castigated.
But I think that things really are stacked against the new flow.
Why? Are the routers conspiring against it?
First the old one is going fast, and if it happens to lose a packet to the new one, it will probably barely notice, just receiving a sack and not slowing down.
** to the new one **
I going to understand ** to the old one **. Is not as easy. In fact TCP congestion algorithms are far away for being easy. Simplifying, the game is: if you lose a packet you have to cut your sending window by a half. Check your new congestion window, check your outstanding packets, check your peer advertising window, and depending of this, calculate how many packets you can send, if you can send any, at all.
However, in the reverse case, the new flow is starting slow, and if it loses a packet it waits for a timeout to send another one, then if it loses another it waits a longer timeout. Eventually, when the new flow tries to speed up it's always bumping against the old one, causing it to slow down again.
Probably the first flow has a higher probability to lose a packet because it has more packets flowing out there. And if it happens, it has to cut its window by a half. At this moment the second flow is at slow-start, its window is increasing almost geometricaly (it doubles each time it receives an ack). Again, who knows? The fight is fighting.
Timeout is an extreme case. Probably a duplicate ack advertises the flow that one packet has been lost. Then slow-start is not the answer, just fast retransmit and fast recovery and then congestion avoidance.
What about if the routers are RED routers. RED routers conspire (they if fact are designed to conspire!!) against stronger flows, those that maintain more packets in the router queue. Then the first flow has to walk with care. Someone out there is tring to kill one of its packets.
Are you really sure the system is guaranteed to converge to 50-50, or even to converge at all? I'm not. Please convince me. In any case, the firewall here is clearly not contributing to this since it's not dropping any packets, or even slowing them down.
Again any firewall doesn't matter.
I did some work to try to convince you. Have a look at http://opalsoft.net/qos/TCPvsTCP.htm.
Finally, to close this pleasing conversation, don't forget that when you configure your "controller devices" you are not controlling TCP, you are just conspiring against it by killing some packets and using the simple rule, "if you lose a packet, cut your window", to put under control the average throughput.
Best regards,
Leonardo Balliache
