Dotaz - Agregace

[Cartman182]

Co to znamená Agregace 1: 50 , když je net 25mb/s ? ...

[huhla]

Co je to agregace?

Tento pojem se často vyskytuje (např. malým písmem pod ceníkem) u linek sdílených, které se jinak snaží tvářit jako "širokopásmové" a v tabulce ceníku se pokoušejí "ohromit zákazníka" velkými čísly u rychlostí. Aniž ovšem říkají, zda (kdy, jak často a na jak dlouho) těchto rychlostí vůbec bude dosaženo. Typickým projevem je, že ty rychlosti tam jsou uvedeny dvě: "nominální" (ta větší, ve skutečnosti "maximální") a nižší (tzv. "zaručená", ovšem nikdo neví, jak "zaručená" - jestli např. smluvně a také jak je "vymahatelná").

Existence těchto dvou čísel je dána právě tím, že taková linka je tzv. agregovaná. Nesdílené linky uvádějí rychlost jen jednu (a také právě tuto rychlost garantují).

Exaktní definice zní, že agregace je poměr celkové kapacity "společné" části trasy pro všechny zákazníky daného poskytovatele (nebo pro skupinu těchto zákazníků) k tomu, kolik kapacity je (může být) těmto zákazníkům celkem prodáno. Je to (u sdílených linek) vždy menší číslo, než jedna (udává se jako "1:x") .

Zkusme na chvíli zapomenout, že se jedná o přenos dat ... a představme si (pro agregaci 1:50, viz ADSL) dům s padesáti byty, kde každý z nich opouští z oné místnůstky trubka o průměru 15 cm, ovšem (na rozdíl od "opravdové kanalizace") také celý ten dům opouští jen trubka o průměru 15 cm, před kterou se těch 50 "bytových" trubek sejde. Trubka je spočítána tak, aby obsah jedné nádržky trubkou protekl přesně za stejnou dobu, za kterou se jedna nádržka naplní (a možno vyslat další ...). No a máme dokonalý model českého ADSL z roku 2003 - a v podstatě i jakékoliv jiné sdílené linky, tedy linky s agregací (lišit se můžeme jen agregačním poměrem, tedy "počtem nájemníků na jednu společnou trubku o stejném průřezu"). Jen pojem "stahovač" (viz častá "vysvětlení" poskytovatelů, proč sdílené linky fungují pomalu) je nutno nahradit pojmem "splachovač" - ale ten za to přece nemůže, že to potřebuje používat.

Celkem nezáleží na "směru toku". V daném příkladu (kanalizace) zřejmě převládá tok "od uživatele do světa" (opačný směr si přeje málokdo), v Internetu je to ve většině případů obráceně (ale ne vždy, viz "peer to peer" sítě, hry, telefonie, ...) - ale princip je stále tentýž.

Ona totiž i data procházejí v určitých "dávkách", kterým se (u dat) říká pakety. Systém (i tento kanalizační) bude fungovat bez problému jen v případě, že svoji "dávku" v danou chvili pošle jen jeden byt. Co nastane, spláchnou-li krátce po sobě dva? No, to záleží na konkrétním uspořádání toho "soutoku". Naštěstí data (na rozdíl od obsahu kanalizace) nemají možnost se vrátit zpátky.

Zbývají tedy jen dvě možnosti. Jedna z nich je, že před soutokem se (třeba na každé dílčí trubce nebo společně pro dům) udělá "zásobník", ve kterém se obsah chvíli zdrží, než bude mít volnou společnou trubku odtokovou. To se ovšem projeví prodloužením "doby odezvy" (u dat je delší "ping", u kanalizace váš konkrétní produkt udělá do kanalizace městské později "žbluňk"). U kanalizace to nevadí, u dat ano (na ta data někdo čeká a např. u telefonie nebo u hry by je rád dostal dost rychle). Druhá možnost je, že před soutokem se na každé trubce udělá "přepad", kterým vypadne ven ten obsah, který nemá v danou chvili možnost odtéci (na datech se tomu říká ztracené pakety, u kanalizace si to pojmenujte jak chcete). Tohle ovšem vadí už i u kanalizace (obsah jsme chtěli mít někde jinde, než "na zemi u soutoku"). Samozřejmě je možná i kombinace ("přepad" bude na "zásobníku").

Ale jistý a neměnný je jeden fakt: takovou společnou trubkou může v danou chvíli protéci jen jedna padesátina (při agregaci 1:50) toho, co by po ní mohl barák chtít v případě úplavice.

Tudíž sejde-li se více "provozu" v jednu chvíli, je momentální účast na komunikaci s městskou kanalizací pro každého jednotlivého účastníka splachovací akce menší (!), než na kolik je dimenzována "jeho vlastní" trubka. Ano, při úplavici je to (s agregací 1:50) jedna padesátina, to se prostě neokecá. Maximálně tak něco vypadne "přepadem" (což asi není tak úplně ono, že).

Takto byl ten barák prostě naprojektován - a v projektu (u ADSL ve velkoobchodni nabidce RAO, u těch ostatních slušnějších poskytovatelů malým písmem v cenících) to je uvedeno. Všechno ostatní už jsou jen různé metody, jak se s touto situací vyrovnat (např. také datový limit - u kanalizace dost těžko realizovatelná představa, u dat ostatně také, na "širokopásmovém" připojení, určeném k rychlému přenosu objemných dat, např. videa).

Ano, i v našem hypotetickém příkladě vznikne (následně) velmi vážný problém, když tu úzkou společnou trubku nikdo nájemníkům neprozradí před nastěhováním. A dokonce když jim tvrdí, že "to se nepozná". A vrchol všeho, když chvíli nechá obsah všech trubek padat rovnou do kanalizace městské, aby (když už má byty hezky obsazené natěšenými nájemníky, chlubícími se skvělou funkčností svého levného WC přátelům) tam tu společnou trubku teprve vložil - a nazve to třeba "ukončená stabilizace".

Jistě, jsou zde od počátku určité náznaky ... např. mnohonásobně nižší nájemné, než bylo do té doby v kraji zvykem, navíc v nájemní smlouvě se ohledně WC vyskytuje neznámé slůvko "agregace" (v jehož výkladu se zpravidla značně liší pan domácí od nezávislých odborníků na kanály).

Já vím ... všichni si představují, že ten hajzl vyhoví (za ty peníze) i vašim vysokým nárokům :-)))

Pozn.

Pokud půjde o více přípojek(bytů) na jeden společný agregační bod, třeba 200, navyšuje se samozřejmě i šíře trubky(přenosové trasy za agr. Bodem), tzn u 512/128 a agregace 1:50 s 200 uživateli na 1 agregačním bodu by vzorec vypadal asi takto 200*512/50 =2Mbit a vyjde vám šířka přenosové trasy za agreg. bodem pro 200 uživatelů.

Pokud by všichni najednou začali stahovat, dostanete se na dost nízkou rychlost na uživatele(vydělíte 50) a ještě musíte odečíst další faktory(kvalita linky, přenosová rychlost nikdy nedosahuje nom. Rychlosti), takže rychlost je velmi nízká.

Důvody, proč se uplatňuje agregace

 Nucená agregace slouží jako uměle vytvořené neužší hrdlo na cestě mezi koncovým uživatelem a jeho ISP. Všechny technologie v cestě jsou dimenzovány a do nákladů BC na ADSL služby promítány tak, aby bez problému přenesly kapacitu úzkého hrdla nucené agregace.

 Pokud by nebyla nucená agregace implementována v IP, vyskytlo by se úzké hrdlo na jiné technologii po cestě mezi koncovým uživatele a ISP. Takovéto hrdlo dané jen kapacitou transportní vrstvy by zapříčinilo negativní ovlivňování uživatelů různých ISP a různých služeb bez ohledu na jejich profil uživatelského chování a jimi předplacený agregační poměr.

Zdroj níže uvedeného článku uvádím taktéž

http://atm.felk.cvut.cz/mps/referaty/2003/jorgt/SubWeb/Agregace.htm

Agregace

Agregací rozumíme poměr kapacity připojení do světa k součtu kapacity prodané zákazníkům. Agregace je u poskytovatelů připojení běžná, její poměr je však jedním z nejdůležitějších ukazatelů kvality připojení. Český Telecom začal od počátku srpna agregovat velmi brutálně, někteří zákazníci si stěžovali, že jimi dosahovaná rychlost spadla pod úroveň běžného dial-upu. Zvýšení rychlosti vůči koncovým uživatelům je hezkým gestem, smysl by však mělo jedině při zvýšení kapacity linek spojujících každý DSLAM na ústředně se světem. Český Telecom tvrdí, že spojení dokáže v případě nutnosti zvýšit. Pokud má k DSLAM, resp. ústředně natažena optická vlákna, s kapacitou by neměl být problém.

O tom, jak je agregace v síti Českého Telecomu přesně realizována, se ví jen velmi málo. Záchytným bodem může být alespoň to, co je psáno ve velkoobchodní nabídce: že agregace bude realizována technikou CAR (Committed Access Rate) firmy Cisco. Co když je příčina všech problémů právě ve volbě této techniky a způsobu jejího fungování? Před prvním i druhým zapnutím agregace musel mít Český Telecom v ruce úplné statistiky o všech relevantních datových tocích, a tak si mohl spočítat, jak velký efekt by zavedení agregace mělo teoreticky přinést. Podobně jednotliví ISP znají datové toky generované jejich zákazníky, a i z nich by si měli umět odvodit teoretický výsledný efekt. Proč se nyní skutečný efekt tolik rozchází s deklarovaným očekáváním? Není to náhodou kvůli tomu, že agregace skrze mechanismus CAR sice omezuje "objem" přenášených dat na síťové vrstvě (IP paketů) tak, jak by teoreticky měla, ovšem na přenosový protokol TCP (využívaný například protokolem HTTP) má výrazně horší vliv - tedy že snižuje jeho propustnost podstatně více, než by měla?

Teď se omlouvám méně technicky orientovaným čtenářům, ale bez malé exkurze do odbornějších partií to nepůjde: CAR je technika charakteru tzv. policingu, nikoli charakteru shapingu. Fakticky to znamená, že "nadbytečné" pakety jednoduše zahazuje (zatímco shaping se snaží nejprve různě "formovat" datový tok, třeba určitým pozdržením těch paketů, které právě nejdou přenést). Obě techniky se uplatňují na úrovni síťové vrstvy (tj. zahazují nebo zdržují IP pakety), a ovlivňují tudíž chování protokolu IP. Pro fungování aplikací, používaných uživateli, je ale podstatný také vliv, který to má na protokoly vyšších vrstev - zejména na protokol TCP na transportní vrstvě, jenž je využíván i aplikačním protokolem HTTP (v rámci služby WWW).

Protokol TCP je ovšem velmi "propracovaný" protokol, který se snaží průběžně adaptovat na změny v přenosovém zpoždění a pravidelnosti doručování jednotlivých IP paketů. Díky tomu se dokáže celkem snadno a efektivně vyrovnat s vlivem skutečného shapingu. Mnohem hůře se ale vyrovnává s důsledky policingu, které se projevují výpadky jednotlivých IP paketů. Protokol TCP interpretuje každý výpadek (ztrátu) IP paketu jako důsledek zahlcení, přechází z kontinuálního potvrzování na jednotlivé, a následně teprve postupně přechází zpět na kontinuální potvrzování. Jinými slovy a s větším zjednodušením: když narazí na ztracený paket, prudce šlápne na brzdu, a pak se zase pomalu a opatrně rozjíždí. Když mu CAR takto čas od času (nebo častěji) zahodí nějaký paket, není těžké si domyslet, že celkový "přenosový výkon" protokolu TCP poklesne, a to třeba i dosti výrazně. No a příčina dnešních problémů může být právě v tom, jak výrazně, resp. jak rychle klesá "výkon" protokolu TCP s četností ztrát IP paketů. Co když to je tak, že třeba několik málo procent zahozených IP paketů způsobí, že celkový "výkon" protokolu TCP klesne o celé desítky procent?

V odborné literatuře je tento problém popsán a prostudován. Případné zájemce mohu odkázat třeba na tuto studii, která uvádí konkrétní závislost mezi četností výpadků a chování protokolu TCP a konstatuje, že "výkon" TCP je extrémně citlivý i na velmi nízkou četnost výpadků IP paketů (méně jak pět procent). To by pak vysvětlovalo i pozorování mnoha uživatelů, kteří zjistili, že různé download manažery dokáží z agregované linky "vymáčknout" více než třeba obyčejný browser. Mohou totiž různě optimalizovat chování protokolu TCP, který používají ke stahování. Především by to ale mohlo vysvětlovat to nejpodstatnější: proč se někde agregace neprojevuje téměř vůbec, a jinde tak drasticky. Pokud je totiž vztah mezi četností výpadků (zahazování) IP paketů a degradací chování protokolu TCP silně nelineární, což je, pak stačí, aby se "zátěž" generovaná zákazníky určitého ISP pohybovala někde kolem "bodu zlomu", kde se tato nelinearita projevuje nejvíce. Pokud je jen málo pod tímto bodem, pak se chování protokolu TCP mění jen velmi málo - ale pokud zátěž naroste, třeba jen nepatrně, může to vyvolat již velmi rapidní degradaci přenosových schopností protokolu TCP.

Řešením může být vhodné "vyladění" parametrů techniky CAR (která skutečně umožňuje nastavovat řadu různých parametrů a celých strategií, podle kterých dochází k zahazování IP paketů v rámci tzv. policingu). Snad se právě na tomto pracuje (viz zmínka o "ladění parametrů").

Dalším řešením by samozřejmě bylo použít místo techniky policingu (CAR) vhodnější techniku shapingu, která je obecně šetrnější vůči protokolu TCP. Bohužel ale platí, že shaping je provozně náročnější než policing, tj. Český Telecom by s ním měl více nákladů než nyní s policingem.

Níže uvedené jsem objevil na stránkách Čtc. Jde o tech. specifikaci carrier broadband služeb a konkrétně agregace se uplatňuje dle jejich slov i na bodech bez plného vytížení, aby to bylo spravedlivější..

http://www.wholesale.cz/dokumenty/doc/rao_priloha_2_technicka_specifikace_050614.doc

1.1 AGREGACE PROVOZU KONCOVÝCH UŽIVATELŮ

V souladu s definicí služby je provoz koncových uživatelů agregován s využitím agregačního mechanismu, který v rámci agregačního bodu omezuje kapacitu dostupnou koncovým účastníkům Poskytovatele.

Parametry agregace jsou specifikovány formou základního agregačního poměru definovaného pro každou službu. Při výpočtu agregačního poměru, který je uplatněn pro konkrétní agregační bod je navíc zohledněna problematika agregačních bodů s malým počtem uživatelů tak, že uplatňovaný agregační poměr pro počet uživatelů nižší než 200 lineárně závisí na počtu koncových uživatelů v daném agregačním bodě. Lineární náběh agregačního poměru je pro počty uživatelů nižší než 200 charakterizován vzorcem:

Pro výpočet agregované (dostupné) kapacity je použita celková kapacita přístupových linek všech konfigurovaných koncových uživatelů Poskytovatele v dané službě v daném agregačním bodě sítě IP. Odvození dostupné kapacity Poskytovatele je tak provedeno bez ohledu na aktuální stav koncových uživatelů služby (připojen či nepřipojen).

V bodu sítě IP je agregace realizována nuceným omezením datového toku v souladu s definovaným agregačním poměrem dané služby. Pro realizaci nuceného omezení je využita technologie CAR (Comitted Access Rate) ve vstupním i výstupním směru.

V rámci technologií páteřní sítě a DSLAM jsou již alokovány pouze kapacity odpovídající uplatněným agregačním poměrům a to takovým způsobem, aby v těchto technologiích nedocházelo k zahazování buněk.

Pro výpočet parametrů agregace je použita celková přístupová kapacita konfigurovaných uživatelů na daném agregačního bodu sítě IP bez ohledu na aktuální stav koncových uživatelů služby (připojen či nepřipojen).

počet účastníků poskytovatele v daném agregačním bodě Percentuální uplatnění dané agregace výsledný agregační poměr

1:20 1:50

1 - 10 účastníků neuplaťnována 1:1 1:1

11 - 25 účastníků 10 % 1:2 1:5

26 - 50 účastníků 20 % 1:4 1:10

51 - 100 účastníků 50 % 1:10 1:25

101 - 200 účastníků 75 % 1:15 1:38

201 a více účastníků 100 % 1:20 1:50

[Kamikaze211]

Ve zkratce agregace je sdílení internetu s ostatními účastníky. To znamená že kdyš máš agregaci 1:50 tak internet sdílíš s dalšími několika lidmi a výsledná rychlost nemusí být 1mb ale třeba 256...

[huhla]

Ve zkratce agregace je sdílení internetu s ostatními účastníky. To znamená že kdyš máš agregaci 1:50 tak internet sdílíš s dalšími 50 lidmi a výsledná rychlost nemusí být 1mb ale třeba 256...

No kami stačilo aby jsi si přečetl údaje z té tabulky a věděl by jsi že 1:50 neznamená že se o tu rychlost dělíš s padesátkou uživatelů.:):idea:

[PodFuck3r]

kde to zjistim pls? mám taky net společnej s několika lidma a rád bych se kouknul s kolika

[Kamikaze211]

V účastnické smlouvě internetu.

[PodFuck3r]

V účastnické smlouvě internetu.

to je blbost ;) každou chvíli se k nám může připíchnout kdokoli jinej a to asi na papíře nebude

[Kamikaze211]

Jak se může na váš internet připojit každou chvíli někdo jinej? Ve smlouvě musí být jasně dáno jakou máš agregaci...

[huhla]

PodFuck3r je to zbytečné se pídit, agregace se ve větší míře neuplatňuje. Vinou výkyvu rychlosti bývá buď to špatný technický stav tel linky (tedy přenosové trasy), nebo a to ve většině případů si za to uživatelé můžou sami. Otevřené or nezabezpečené WiFi, špatně zapojeno přímo u uživatele, nesprávný postup měření (to když se snažíš měřit rychlost a na pozadí tobě nebo bráchovi v PC běží torenty a jiné šmejdy).