Re: rate-limit

Da, prima parte e exact mecanismul de autoreglare TCP, dar explicat
intr-un limbaj mai "human-readable" decat al meu. Cea de-a doua parte, cu
algoritmul de calcul insa mi se pare ca are totusi o aroma de empirism de
genul "burtologiei" mele, pentru ca sunt greu de cuantizat cu precizie
caractersticile traficului, mai ales in cazul unui ISP (oricum, e o
informatie de start buna, mi s-a parut foarte interesant punctul de
vedere).

In plus, pot sa dau un exemplu de utilizare cu "skill" a rate-limiturilor
care nu are nimic de a face cu algoritmul asta (si care e un pont pentru
ISP-istii din .ro :D)


AR-390 de la Allied Telesyn sunt o solutie wide-spread in .ro de conversie
E1-G703 to Ethernet (fluxuri SNR, Orange, CFR etc). Problema cu ele e ca
daca le pui IP-uri pe interfete merg la 2 megi, dar daca le pui in
bridging, de pe la 1.6-1.7 incepe sa creasca ping-ul, se pierd pachete si
o dau in balarii, si asta datorita proastei bufferizari si conversii Layer
2 de pe mediul ethernet pe E1 (probabil ca controller-ul de E1 e
ieftinaciune, si fara preprocesare layer 3 e dezastru).
Eu le-am pus totusi in bridging, si le-am dus la 1.9megi fara sa creasca
pingul, cu un rate-limit pe cisco-urile din capatul celalalt al
ethernetului. Si rate-limitul asta era ceva de genul 3000000 6000 6000 (or
smth like that, e tot empirism la mijloc). Rationamentul e simplu: faci
intervalul de esantionare cat mai mic pe ethernet, si astfel elimini
bursturi mari pe intervale de timp scurte, care intepenesc bufferele
interne din AR-uri.

Nice, huh?

-- 
Adrian Racasan
Canad Systems Internet
Departamentul Tehnic
Tel: +40-21-3210070 , +40-74-0100486


> in final am gasit niste explicatii, cat or fi de bune nu stiu, dar na si
> tie(voua):
>
> When configuring the burst rate you need to take into account that some
> protocols implement mechanisms
> that reacti on packet loss. For instance, Transmission Control Protocol
> (TCP) reduces the window by half for
> each lost packet. This causes a "saw tooth" effect in the TCP traffic
> when TCP tries to accelerate to the line
> rate and is throttled by the policer. If the average rate of the saw
> tooth traffic is calculated, it is much lower
> than the policed rate. You can, however, increase the burst in order to
> achieve better utilization. A good start
> would be to set the burst equal to twice the amount of the traffic sent
> with the desired rate during Round-Trip
> Time (TCP RTT). If RTT is not known you can double the value of the
> burst parameter.
>
> The following example calculates the burst for a TCP session with a
> policing rate of 64 Kbps and given the
> TCP RTT is, 0.05 seconds:
> <burst> = 2* * = 2 * 0.05 [sec] * 64000/8 [bytes/sec] = 800 [bytes]
>
> <burst> = 2 * 0.05 [sec] * rate /8 [bytes/sec] = 2 * RTT [sec] * rate /8
> [bytes/sec] = rate / 1000 * 12.5 [bytes]
> RTT =~ 50ms
>
> In the example above, <burst> is for one TCP session, so it should be
> scaled to average the expected number
> of sessions traveling through the policer.
>
> C
> ---
> Send e-mail to [email protected] with subject "unsubscribe cisco"
> (without quotes) to unsubscribe from this list.
>
>  Acest mesaj a fost scanat de RAV Antivirus




 Acest mesaj a fost scanat de RAV Antivirus 
---
Send e-mail to [email protected] with subject "unsubscribe cisco" 
(without quotes) to unsubscribe from this list.