Dotaz: Uprava HTB pro "zpozdeny traffic shaping"?

[moole]

Zdravim, zatim jsem tu nenasel dotaz na toto "vyssi HTB tema". Spravuju internetovou gateway asi pro 4000 uzivatelu, vse jede v poradku, ale stale zbyva zbytecne nevyuzita vstupni konektivita. Chtel bych ji rozdat timto zpusobem:

Kdyz zacne uzivatel stahovat, pojede mu napr. prvnich 5 MB plnou rychlosti rozhrani (jakoby bez shapingu, ale pritom stale s akceptovanim rate a ceil rodicovske tridy - vstupni konektivity), a az pote, bude-li dal stahovat, klesne do standardniho qosu htbckem (zacnou se dodrzovat rate a ceil). Az prestane stahovat (nebo pomaleji nez je mozne jeho tridu obsluhovat), zacne se zase plnit kyblik onech 5 "rychlych" MB touto jeho nevyuzivanou prenosovou rychlosti (ceil).

Pokud dobre chapu koncept HTB, tak takhle to nastavit nejde. Nyni muzu nastavit cburst 5120kb, HTB tak porusi hodnotu ceil (coz chci), ale po chvili tim celou tridu "vyhladovi" a ta prestane poustet traffic uplne (coz nechci), dokud se zase nedoplni jeji kyblik tokenu.

Byla by potreba asi jeste jedna uroven (rate, ceil a treba roof), ktera by dostala rburst 5120kb a nezapocitavala svuj traffic do trafficu sve tridy, ale jen te rodicovske (aby nemohla omezit ostatni tridy na stejne urovni)..

Neresili nebo neimplementovali jste uz takovyhle zpusob shapingu nekdy/mekdo/nekde? Jednoduse jde o to, poskytnout uzivatelum komfort z nevyuzite konektivity, a pritom neumoznit zahltit sit zbytecnym sosanim :)

Diiiky za nazory/rady.

Odpovědi

[b42]

Asi to vubec neni to, co chcete, ale bylo by treba mozne pro takove spojeni vytvorit zvlastni tridu a pomoci iptables matche "connbytes" do ni klasifikovat spojeni, ktera nepresahla urcity datovy limit ...

[Opičák]

řešil jsem to samé....bez úspěchu, berličky nemá smysl tvořit, protože to zbytečně zatěžuje iGW. Možná poradí někdo jiný a "neumřu" blbý .

[moole]

Napsal jsem o radu Devikovi, ale zatím se neozval... má, počítám, dost své práce :/

[secido]

Necitas odpovede? connbytes to riesi.

[dan]

Connbytes to bohuzel neresi v pripade, kdy stahovac stahuje ve spouste streamu.

Resenim je omarkovat traffic do nekolika trid (sam pouzivam realtime, interaktivni, default, p2p a tridu s nizkym stropem pro notoricke stahovace) Connbytes v tomto pripade pouzivam pro premarkovani velkych interaktivnich http streamu do default.

Pokud se vhodne nastavi priority a raty techto trid, stahovaci muzou stahovat temer plnou rychlosti, ale dulezite pozadavky jsou vyrizeny prednostne.

Sice to neni spravedlive co se tyce rozdelovani rychlosti mezi uzivatele, ale garantuje to alespon jakousi kvalitu sluzeb.

[moole]

To je bohuzel neco jineho, nez potrebuji.

Aby byly nabizene sluzby konkurenceschopne, jsou oznacovany a lisi se sirkou pasma (rychlosti) a jako takove je musi dodrzovat. Mohl bych Vami popsanou klasifikaci povesit na kazdou uzivatelskou tridu, ale to je

1) prilis HW narocne

2) je to nad ramec nasich povinnosti (je na uzivateli, jak nalozi se svou sirkou pasma)

3) dovoli to (z naseho pohledu nezadoucim trafficem) na 100% vytizit sit, ktera bohuzel nema stejnou propustnost ke kazdemu uzivateli. Doba reakce htb na zmenu pomeru prenasenych protokolu pak bude patrna, takze by to v takovem pripade stejne nebylo uplne "ono".

Presto diky!

[moole]

Docela jasne jsem popsal, jak si predstavuji, aby to fungovalo, a myslim, ze uprava HTB je nejjednodussi cestou, jak toho dosahnout. connbytes to takto vyresit neumi a pokud, tak s vyrazne horsi efektivitou (dalsi dve tridy a dva marky pro kazdeho uzivatele).

Devik je autorem HTB, proto jsem mu napsal, jestli by se k tomu mohl vyjadrit - ma-li to smysl a je-li to vubec mozne do HTB dopsat. Implementace bych se s jeho pozehnanim samozrejme ujal sam, protoze obecne zadana funkcionalita to urcite neni.