* Re: [LARTC] RED/GRED implementation for InBound Traffic Control (from
2004-07-09 19:11 [LARTC] RED/GRED implementation for InBound Traffic Control (from ISP) Ow Mun Heng
@ 2004-07-10 8:17 ` Ed Wildgoose
0 siblings, 0 replies; 2+ messages in thread
From: Ed Wildgoose @ 2004-07-10 8:17 UTC (permalink / raw)
To: lartc
>>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 bytes
>>
>>
>1st 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 / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 2+ messages in thread