Re: [LARTC] HTB burstable for 2 interface , how ?

[Leonardo Balliache <leoball@opalsoft.net>]

Hi, Don:

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



_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/