dummynet/queue

[Dan Lukes]

vita at fio.cz wrote:

> >      Dobra - zacinam byt vice-mene uspokojen ve sve zvedavosti 


> Ja jsem to pochopil stejne jako ty. Navic jsem zkoumal jesli by se 
> prece jenom
> na prichozim toku, ktery je omezeny uz providerem, nedal nejak zaridit
> spravedlivy pristup ke kapacite linky.
>
> V pripade, ze si udelam pipe, ktara bude mit o neco nizsi kapacitu nez 
> prichozi

	To je stejny smer uvah jako u me - ostatne, v jednom z predchozich 
dotazu jsem vyslovne popsal priklad, kdy softwarove omezeni bylo mensi 
nez fyzicka kapacita linky (a ostatne, ty vis odkud jsem ten priklad vzal).

> linka, a do te pipe povedou napr. 2 queues se stejnou prioritou, bude to
> vypadat takhle:
>
> Trocha znaceni
> KL - kapacita linky (omezena providerem nebo schopnosti media, karty atd.)
> KP - kapacita pipe (KP < KL)
> R = KL - KP rozdil
> KQ1 = KQ2 = KP/2 kapacity toku pres fronty q1 a q2
>
> Pokud v nejakem okamziku nastane napr. takova (nespravedliva) situace, ze
> toky prislusne frontam q1 a q2 jsou v pomeru napr.
> 1:2 a jejich soucet je KL, tak pri pruchodu pipou budou zahazovany 
> vyhradne
> pakey z fronty q2 a to v mnozstvi odpovidajicim prutoku o velikosti R.
>
> V pripade ze TCP stack bude dostatecne elasticky, melo by dojit k 
> tomu, ze tok
> pres q2 se snizi a tudiz vznikne zvysena kapacita pro tok pres q1 a 
> tok pres q1
> se zvysi.

	Ano, take predpokladam, ze tak by se to melo, u rozumne zprogramovaneho 
stacku, chovat - obzvlaste, pokud za zahozeny paket odejde zpet 
ICMP_SOURCESQUENCH (na coz BSD stack, pokud vim, reaguje zmensenim 
okna), nicmene, i kdyby na tohle ICMP nereagoval, stejne by melo dojit 
ke zpomaleni (ledaze je implementovan SACK, coz casto je, pak by to s 
tim zpomalenim nebylo az tak zhave).

> to trochu slozitejsi analyzovat, co se bude presne dit.

	Naprosto souhlasim.

> Je mozne ze dojde k uplenemu vyrovnani toku a stabilizaci na hodnotach 
> KQ1 a
> KQ2, ale i kdyby ne k jistemu nastoleni spravedelnosti prece jen doslo.

	Ano, v pripade "slusne napsanych" TCP stacku, v pripade TCP komunikace 
za cenu trvale ztraty casti prenosoveho pasma. Ostatne, jak sam popisujes:

> Zaverem bych chtel dodat, ze je to ode me cista teorie, ktera navic
> predpoklada dostecne elasticky TCP stack, ktery je schopen reagovat na
> zmenu pruchodnosti o velikosti R. I v pripade, ze by tenhle model byl
> spravny, je otazka jestli dostatecne popisuje skutecny stav.


	Dalsi otazka je, jaky je vztah mezi "schopnosti byt spravedlivy" a 
pomerem KP/KL - a az se zjisti tohle, tak zda nebude cena za 
"spravedlnost" neprimerene vysoka.

						Dan


-- 
Dan Lukes      tel: +420 2 21914205, fax: +420 2 21914206
root  of FIONet,  KolejNET,  webmaster  of www.freebsd.cz
AKA: dan at obluda.cz, dan at freebsd.cz, dan at kolej.mff.cuni.cz