Geoffrey S. Mendelson wrote:
>This just causes double transmission of the packets. The effective bandwidth
>of the line drops, but the actual queues still stay large.
>
No, this is plain wrong. TCP employs a very powerful congestion control.
When it notices that the connection exceeded its allocated bandwidth, it
will lower the transmission rate, thus eliminating the need to drop
further packets. This will also clear the ISP's buffers.
> The only way I can
>see to accomplish real queue reduction would be to selectively increase
>the latency of the line for low priority traffic.
>
Increasing latency is bad. Not only does it not solve the problem (TCP
has very good mechanisms for handling high latency connections without
losing bandwidth), but it also makes the user experience seem bad.
> This could be
>accomplished by holding back TCP ack packets so that the originating host
>really does not send faster than we want.
>
>
It MAY be possible to achieve this effect by manipulating the outgoing
packets window. This is not a trivial manipulation to perform, however.
The TCP window field's intepretation is dependent on a TCP option called
"Window Scale". This option is only attached to the session initiation
packets (the SYN and SYN+ACK), which means very stateful tracking of the
connection. Not impossible. I have implemented such a thing when I wrote
Check Point's "TCP sequence verifier" feature, but not pleasent either.
>This really is very impolite, it causes the sender to resend packets they
>had no reason to resend.
>
Sure they had reason to resend them. These packets were over the
available bandwidth.
> It causes a lot of uncessary retransmission
>
I don't think it causes any extra retransmission at all. The way TCP
detects the line's available bandwidth is by pushing the limit and
tracking lost packets. This means it will lose, approximately, the same
percentage of the packets no matter what the actual bandwidth is. I
don't see any difference between causing the drop at your end of the
connection and having the drop happen at the ISP's end due to buffer
full conditions, which is something that happens all the time anyways.
> just
>to keep you stats looking good, without actually doing any good.
>
>
Have you tried?
>Geoff.
>
>
Shachar
--
Shachar Shemesh
Lingnu Open Source Consulting ltd.
Have you backed up today's work? http://www.lingnu.com/backup.html
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
