Hi Shachar, let me reiterate.
Shachar Shemesh wrote:
<snip>
Another inaccuracy, I believe, in your statement is that the ISP isn't
the one determining the rate at which packets are sent to you. The TCP
on the server you connect to is. On a similar note, the ISP does not
control your window size or rate, your own TCP does. The ISP can only
affect the line characteristics, nothing else.
You misunderstood me with the whole ISP issue. I was simply referring to
"fooling" the ISP to send you packets at a specific rate and not per sei
stating the ISP has no control, the ISP defines a bandwidth cap for you
(via VPN?) and perhaps a QoS definition for line priority etc. but
beyond that does not really get involved. And yes, the TCP window size
is affected by how you drop packets by your own connection, I never said
the ISP has direct control over your TCP window size..
When another machine connects to you, it will burst the data until
packets start to drop. The steady state of the connection will be what
you paid for - no amount of buffering can change that. This means that
the rate at which the sending TCP sends out the data will be identical
to the rate at which you pull it from the ISP's buffers, and the buffers
will remain full.
Yep, that is also the behavior I was describing.
Let's say your down connection is 2Mb/s, and the ISP has 256KB (2
seconds worth) of buffers. If you limit your incoming speed (at your
end) to 1.8Mb/s, all sending TCP will learn it and send stuff out at
1.8Mb/s. Even if the ISP's buffers burst and fill up, they will be
deflated at 0.2Mb/s, which means that at steady state, they will be
empty. Mission accomplished, and no significant degradation of bandwidth.
nop, that is not entirely accurate although there is no rule for this,
it takes playing around, usually up to 1Mbit the ISP can supply you a
steady stream of bandwidth without needing to buffer much on their end.
However, if you are requesting 2Mbit bandwidth the ISP will have
fluctuating traffic from their end (say 1Mbit steady and bursts of up to
10Mbit) which they will then fill a "buffer" with. Conclusion, trying to
simply cut your estimated buffer from your ISP will not reduce its
buffer, you need to use tc to hard limit the download stream in order to
drop packets early on and maintain a stream of say 1Mbit, the ISP
incoming traffic will be less buffered and will leave space for you to
download and receive with.
BTW- The use of IMQ comes in handy in addition because you can drop
packets and give different types of traffic an opertunity to be received
while drooping packets you are not interested in receiving above a
certain rate.
There really is no need to cut your bandwidth in half over this.
It is not a matter of "half" as a rule but rather playing around to see
from what point the ISP has a lot of buffering done, from my experience
700kbyte/s is about the limit where no buffering occurs. (Netvision is
my ISP with a Cable connection of 3Mbit/278kbit)
Shachar
=================================================================
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]
