So the solution is to throttle incoming to 99.9% of total incoming bandwidth. Well, actually since you have no control over who can send you data, this only works in steady state. So perhaps you should make it 95% or 90%. It depends whether you mind there being the odd blip where someone starts sending you traffic, but it takes a second or so while you instruct other senders to slow down. In the meantime you will be overloaded.
And how does RED/GRED solve that or are you not addressing that?
RED and GRED are used in conjunction with something that queues packets and releases them slowly. So you can use IMQ on the incoming stream and then HTB, etc or do it on the outgoing stream.
The idea is that you could temporarily let the incoming queue get really, really large until the sender fills their send window with data, then perhaps this might throttle the send speed... (iffy), or you could look at your queue and when it gets beyond a certain size then you (wastefully) drop some of the packets, which because of the way TCP works means that the sender slows down. The "R" in these two algorithms means that packets get dropped randomly, as opposed to, say, waiting for the queue to fill up and then drop any incoming packets until it clears down a bit - the theory is that this is fairer ("drop randomly" instead of "drop most recent").
My understanding when talking to this guy and all the stuffs which I've
read seems to point that RED is good at handling these sort of things.
(but then again, it's not as good as TCP windowshaping, which
incidently, all i've heard/read is that it's Good, but whether or not it
drops packets(or compared to RED/GRED), I have no idea.
You need to read how TCP works. People have a variable sized output buffer and keep that amount of data "in transit" at any one time. Once the window fills up, ie there is a load of data in-transit, then they pause until they get some acknowlegments that the data was received. TCP also changes the size of this window based on whether packet drops occur, and in fact the whole point of a load of clever TCP algorithms are to find the optimal window size so that we don't overload the receiver, but still keep the net link in full use.
Simple throttling algorithms just drop a few packets to encourage the sender to slowdown. However, this is wasteful because you already downloaded them, then throw away, then you clearly have to download them again! However, fiddling with windowsize is obviously going to be complicated... No one has written anything free yet.
In this case you pay for NOT 512Kbit/s of IP bandwidth, but 512Kb/s of ATM bandwidth. And unfortunately the relationship between the two is slightly complicated.I have no idea what's the difference actually.
Well read the rest of the very clear flipping email that I took 20 mins to write!!!!!
To save you the headache of worrying about those calculations consider sending a 49 byte packet. It will clearly need to be split into two 48 byte packets (yes?),1st packet = 48byte
2nd packet = 1 byte
YES?
No second packet = 48 bytes!!! It only has 1 byte of data in it, the rest is blank. ATM ***only*** sends data in 53 byte packets - 48 contain data + 5 byte header.
So if your MTU is a multiple of 48 then you will waste very few packets, otherwise you will have some wastage. If you have a P2P app which sends data in random, probably small sized packets, then frequently they won't be a multiple of 48, and the wastage will be large compared with the size of the IP packet being sent..... However, the kernel is throttling based on the size of the IP bandwidth consumed, whereas you might already have overloaded your link despite the kernel thinking its 3/4 full
Solution is to enhance the kernel calculation of rate on the ADSL line so that it knows it is different to the rate used on an ethernet connection.
However, every ADSL provider does it slightly differently. It's not easy to find the correct calculation....
then each packet has a 5 byte header = 53 bytes1st packet = 48+5 = 53byte
2nd packet = 1+5 = 6byte
Nope.... See above. (Or search the net for ADSL QOS and ATM. There are plenty of references and a really good HOWTO)
huh?? I take it that you're saying the maximum/min for each packet is
53bytes (yes?)
....you're getting it!
So big FTP transfers with large IP packets don't waste too much, but if you have a load of SSH users, or some P2P users, or something else which spits out tons of small packets then the IP bandwidth might be loads less than the ADSL bandwidth, hence some people really throttle back to be sure they have control of the inbound connection
That's what I want actually. The (or rather my) holy grail and without
severely limiting my inbound traffic. (50%?? Man.. I'm not gonna waste
50% of what I'm paying. It's like buying a big mac and only getting the
buns minus the patties)
Well, some people prefer to avoid any blips in their latency rather than worrying about some wasted bandwidth. Different needs that's all
(Some people buy a big mac and throw out the gurkin as well...)
However, without a clever patch then there was previously no other way to limit the download link. Remember they *weren't* limiting themselves to 50% of what they paid for, what they were doing was putting 50% of the magic number in the script. Because of the size of packets in transit they were actually consuming 100% of the link, but only registering as using 50% of the equiv ethernet bandwidth... People fiddle around and determine this number empiracally based on the type of data they receive....
Look at it another way, depending on the type of data you transmit, eg P2P it can consume (waste) up to 50% of the bandwidth in useless ATM cells...
Clear as mud?
I didn't know mud was clear. (so that means, I've not a clue)
Sorry, english uses irony a lot. My fault. The phrase means "clear as something which isn't very clear"..? ie Did I explain it badly? or "Still confused?"
So the answer was obviously yes.... Hopefully the above helps. Try the ADSL-QOS Howto is you still have questions
Ed W _______________________________________________ LARTC mailing list / [EMAIL PROTECTED] http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
