11   End-to-end performance

Projekt End-to-end performance se zabývá teoretickými a praktickými stránkami zajištění vysoké propustnosti a dalších kvalitativních komunikačních parametrů vyžadovaných aplikacemi při komunikaci přes rozlehlé vysokorychlostní sítě.

Projekt má svoje internetové stránky, kde je možné nalézt všechny naše články, technické zprávy, prezentace, výsledky experimentů a vytvořený software. Shrnutí nejdůležitějších výsledků projektu v roce 2003 a výběr některých zajímavých technických problémů uvádíme dále.

11.1   Přenosy velkých objemů dat v rozlehlých vysokorychlostních sítích

Internet je již téměř od svého úplného počátku velmi rozlehlou počítačovou sítí překonávající desítky tisíc kilometrů. Teprve v nedávné době si však Internet připsal další dva klíčové atributy. Za prvé, stal se vysokorychlostním. To znamená, že jeho linky mají dnes kapacitu řádu jednotek a výjimečně i desítek gigabitů za sekundu. Za druhé, uživatelé v oborech jako fyzika či astronomie začali přenášet opravdu veliké objemy dat - od terabajtů až po petabajty.

Po tom co se sešly všechny tři atributy pohromadě (rozlehlost, vysoká rychlost a veliké objemy dat) se ukázalo, že stávající komunikační protokoly, zejména spolehlivý transportní protokol TCP, kterým se dnes v Internetu přenáší více než 95 % dat, a mechanismy používané při zpracování dat na koncových stanicích nejsou dostačující. Je potřeba je zásadně vylepšit, abychom dosáhli vysoké propustnosti a dalších kvalitativních parametrů, jako například nízké fluktuace zpoždění, které moderní aplikace vyžadují. Problematika se obvykle shrnuje pod názvem end-to-end performance.

V roce 2003 jsme na téma přenosu velkých objemů dat v rozlehlých vysokorychlostních sítích prezentovali několik příspěvků na zahraničních i tuzemských konferencích a seminářích. Některé zajímavé technické podrobnosti popíšeme v následujícím textu.

11.2   Konfigurace koncových stanic

Ukazuje se, že do přenosových rychlostí řádově 100-300 Mb/s je většina problémů s nedostatečnou propustností způsobena nedostatky v konfiguraci koncových stanic. Na vyšších rychlostech je obvykle třeba již provést další ladění a úpravy týkající se komunikačních protokolů. V této části textu se zmíníme o několika nejvýznamnějších faktorech ovlivňujících propustnost, které se týkají konfigurace na koncové stanici.

11.2.1   Socketové vyrovnávací paměti

Propustnost protokolu TCP je vždy shora limitována velikostí socketových vyrovnávacích pamětí na straně vysílače i přijímače. Ty totiž určují maximální velikost TCP okénka cwnd počítaného na straně vysílače nebo rwin oznamovaného ze strany přijímače. Okénko určuje maximální objem dat, která mohou být přenesena za jeden interval RTT. Standardní velikost socketových vyrovnávacích pamětí ve většině operačních systémů je v rozmezí 16-64 kB. Takto malé okénko spolu s RTT v řádu desítek až stovek milisekund limituje propustnost na desítky až jednotky Mb/s bez ohledu na to, jak velká je volná kapacita sítě.

Socketové vyrovnávací paměti mohou být nastaveny pro všechna nová TCP spojení na úrovni operačního systému nebo pro jedno TCP spojení uvnitř aplikace. Nastavit lze buď pevnou hodnotu, nebo může být použita určitá automatika, která se snaží podle požadavků spojení a stavu sítě nastavit optimální velikost. Jako příklad můžeme uvést příkazy pro nastavení socketových vyrovnávacích pamětí pro všechna nová TCP spojení v operačním systému Linux na hodnotu 2 MB:

systctl -w net/ipv4/tcp_rmem=4096 2097152 16777216
systctl -w net/ipv4/tcp_wmem=4096 2097152 16777216

Příklad vlivu zvětšení socketových vyrovnávacích pamětí na dosaženou propustnost při přenosu ze sítě CESNET přes síť Géant do sítě Uninett (Norsko) je na obrázku. Řešení bohužel není tak jednoduché. Některé operační systémy - například Linux, zejména s jádry řady 2.4 - obsahují vnitřní aritmetiku, která způsobí, že skutečný limit pro TCP okénko bude odlišný od specifikované velikosti socketové vyrovnávací paměti. Tento operační systém navíc obsahuje řadu dalších mechanismů, které mají vliv na dosažitelnou propustnost. Podrobnější popis některých mechanismů jsme uvedli v [UbC03] a [UbC03a]. Připravujeme technickou zprávu s podrobnějším popisem dalších mechanismů.

Další problém může vzniknout, nastavíme-li velikost socketové vyrovnávací paměti příliš vysoko. Veliké okénko pak může způsobit naplnění front na směrovačích, což spolu s fluktuací dat v síti zvýší pravděpodobnost ztrát paketů, na které následně reaguje řízení zahlcení snížením propustnosti. Přítomnost tohoto jevu lze do určité míry detekovat sledováním závislosti aktuální propustnosti na aktuálním TCP okénku nebo sledováním fluktuace RTT. Například na obrázku vidíme, že RTT sledovaného spojení výrazně fluktuovalo až na několikanásobek RTT v prázdné síti o hodnotě asi 40 ms. V určitém okamžiku došlo ke ztrátě paketu v důsledku naplnění fronty směrovače, snížení propustnosti a tím i stabilizaci RTT.

[Obrázek]

Obrázek 11.1: Závislost propustnosti na velikosti socketových vyrovnávacích pamětí

[Obrázek]

Obrázek 11.2: Fluktuace RTT během TCP spojení

Důležitým prvkem, který musí být správně nastaven, je fronta síťového rozhraní (txqueue), do níž přicházejí pakety od všech datových toků, které mají být odeslány přes dané síťové rozhraní. Podrobnější diskusi o konfiguraci txqueue jsme uvedli v [UbC03a]. Zjednodušeně lze říci, že pro síťový adaptér typu gigabitový Ethernet obvykle postačí nastavit txqueue na velikost 1000 paketů.

11.2.2   Konfigurace aplikací

V některých případech může být propustnost limitována přímo vlastnostmi aplikace, kterou uživatel používá. Zjistili jsme například překvapivě nízkou propustnost při přenosu souborů programem scp. Socketové vyrovnávací paměti, fronta txqueue a další vlastnosti síťové podpory v operačním systému byly řádně nastaveny. Zátěž procesoru způsobená šifrováním byla na obou koncových stanicích malá.

Zjistili jsme, že příčinou je způsob organizace dat v protokolu ssh. Data jsou přenášena v blocích o standardní délce 32 kB. Tyto bloky se potvrzují na aplikační úrovni a standardní maximální počet odeslaných a dosud nepotvrzených bloků jsou čtyři. Protokol scp si tedy vytváří své vlastní okénko nad TCP okénkem a jeho standardní velikost je 128 kB. Velikost tohoto aplikačního okénka je možné nastavit konstantami ve zdrojovém kódu balíku ssh. Vliv zvýšení tohoto okénka na zvýšení propustnosti na jedné z testovaných tras je znázorněn na obrázku. Zvýšení objemu šifrovaných dat samozřejmě vedlo také ke zvýšení zátěže procesoru.

[Obrázek]

Obrázek 11.3: Závislost propustnosti na velikosti vnitřního okénka protokolu ssh

11.3   PERT

PERT (Performance Enhancement and Response Team) je vznikající mezinárodní aktivita, jejímž cílem je vytvoření technických a organizačních prostředků, které by měly pomoci uživatelům při řešení problémů s výkonností komunikace síťových aplikací. Mělo by jít do určité míry o prostředek analogický k organizaci CERT, zabývající se řešením bezpečnostních problémů.

CESNET se podílí na návrhu struktury PERTu, který zatím probíhá v rámci aktivity TF-NGN projektu Géant. V druhé polovině roku 2004 by práce na PERTu měly být součástí připravovaného projektu GN2. Naše zkušenosti s přípravou aktivity PERT jsme shrnuli v příspěvku do deliverable D8.1 "Multi-domain monitoring and PERT" projektu Géant.

Identifikovali jsme dvě skupiny uživatelů, kteří mají zájem o činnost aktivity PERT a kteří jsou ochotni zapojit se jako pilotní uživatelé PERTu. První skupinou jsou lidé zabývající se gridovými technologiemi (zejména kolegové z Masarykovy univerzity), druhou skupinou jsou lidé starající se o přenos obrazových materiálů (videostreaming) přes Internet.

Začali jsme vytvářet WWW stránky aktivity PERT, které by měly obsahovat tři základní části:

Navrhli jsme strukturu popisu výkonnostních problémů v databázi a vytvořili jsme testovací databázi pomocí MySQL a skriptů PHP4. Po zvážení požadavků jsme dospěli k závěru, že bude třeba realizovat novou verzi databáze na základě systému Request Tracker (RT) se skripty pro uživatelské rozhraní. Identifikovali jsme následující požadavky na databázi a motivace vedoucí k této volbě:

Předpokládáme, že v rámci eskalace řešení bude každý případ předběžně vyhodnocen a předán k řešení příslušnému pracovníkovi podle jedné z následujících oblastí příčin problémů:

Jedním z pravděpodobně nejobtížnějších úkolů bude nalezení a případně vyškolení pracovníků v "první linii", kteří budou přijímat případy a identifikovat oblasti příčin problémů, jakožto i pracovníků zodpovědných za jednotlivé oblasti.

Dalším klíčovým úkolem pro úspěch aktivity PERT je vytvoření kvalitního systému pro sledování výkonu (performance monitoring). Požadavky na tento systém jsou v současné době formulovány na základě zkušeností z mnoha měření výkonnostních charakteristik. Vývoj tohoto systému bude rovněž součástí projektu GN2.

11.4   Odhad kapacity trasy

Aktuální volná kapacita určité trasy přes počítačovou síť, to je část instalované kapacity, která není zaplněna existujícím provozem na síti, je velmi důležitou informací. Říká nám jakou propustnost můžeme očekávat od další spouštěné síťové aplikace, zda je někde na síti krátkodobě či dlouhodobě přetížené místo, zda je někde v síti nějaký problém nebo zda bude potřeba udělat upgrade instalované kapacity.

Nástroje pro měření volné kapacity, například program iperf, se snaží volnou kapacitu změřit tím, že ji plně využijí, tedy posílají do sítě maximální možný tok dat. Tato metoda má samozřejmě negativní dopad na existující provoz uživatelů a je možné ji používat pouze krátkodobě.

Nástroje pro odhad volné kapacity naproti tomu pošlou jen několik paketů odeslaných v pečlivě nastavených vzájemných časových rozestupech. Na základě vyhodnocení časů jejich odeslání a jejich příjmu na druhém konci testované trasy je potom odhadnuta volná kapacita. Existující provoz má totiž vliv na změnu časového rozestupu testovacích paketů.

11.4.1   Klasifikace nástrojů pro odhad kapacity trasy

Protože možnost odhadu kapacity trasy bez jejího zatěžování je velice atraktivní, rozhodli jsme se ověřit, zda existující nástroje tohoto typu jsou použitelné i v rozlehlých vysokorychlostních sítích. Předchozí provedené studie byly omezeny na nižší rychlosti nebo jednodušší síťové topologie. Nástroje můžeme klasifikovat mimo jiné podle následujících kriterií:

Klasifikace několika známých nástrojů reprezentujících různé přístupy je shrnuta v tabulce.

Každá linka Instalovaná vs.    
Nástroj vs. úzké místo volná kapacita Metoda Umístění
Clink bottleneck instalovaná RTT vysílač
Sprobe bottleneck instalovaná disperze vysílač i přijímač
Pchar každá linka instalovaná RTT vysílač
Pathchar každá linka instalovaná RTT vysílač
Pathrate bottleneck instalovaná disperze vysílač i přijímač
Pathload bottleneck volná disperze* vysílač i přijímač
ABwE bottleneck volná disperze vysílač i přijímač
* relativní jednosměrné zpoždění

Tabulka 11.1: Kategorie nástrojů pro odhad kapacity trasy

Nástroj pathload by měl indikovat volnou kapacitu na úrovni protokolu IP, zatímco nástroj ABwE by měl ukazovat volnou kapacitu normalizovanou pro protokol TCP.

11.4.2   Shrnutí pozorování

Podrobnější popis zjištění o vlastnostech různých nástrojů jsme uvedli v technické zprávě CESNETu 25/2003 "End-to-end bandwidth estimation tools". Zde uvedeme shrnutí některých zajímavých pozorování. Pathload je ve standardní distribuci schopen pracovat do rychlosti 120 Mb/s. Vhodnou konfigurací vnitřních konstant se nám podařilo dosáhnout činnosti programu pathload až do rychlosti 800 Mb/s. Z testu na testbedu s kontrolovanou volnou kapacitou nastavenou generovaným tokem dat vyplynulo, že tento nástroj je schopen odhadnout volnou kapacitu v celém rozsahu hodnot (t.j. do 800 Mb/s) pouze velice hrubě. Pokud bylo požadované rozlišení 100 Mb/s, všechny naměřené hodnoty se do něj vešly. Pokud ale bylo požadované rozlišení jen 10 Mb/s, většina naměřených hodnot byla mimo rozsah.

Spustili jsme na dobu jednoho měsíce na dvou testovacích trasách přes síť Géant o více než 10 směrovačích a linkách OC-48 a gigabitový Ethernet sadu následujících nástrojů pro měření a odhad kapacity trasy s jedním měřením každým nástrojem za hodinu:

Vzorek naměřených hodnot ze čtyřdeního období na jedné z testovacích tras je na obrázku.

[Obrázek]

Obrázek 11.4: Měření a odhad kapacity trasy

Z obrázku je zřejmé, že hodnoty naměřené různými nástroji se podstatně liší a není proto jednoduché dojít k závěru, která hodnota se blíží skutečnosti. Obecně lze říci, že paralelní TCP iperf nebo UDP iperf mají větší šanci vyplnit volnou kapacitu, zároveň však také stresují stávající provoz, proto mohou naměřit i vyšší hodnotu než je reálná volná kapacita. Pathload funguje velmi nespolehlivě a často systematicky podhodnocuje volnou kapacitu. Podrobnější diskusi našich pozorování lze nalézt v interní technické zprávě [UKr03] projektu.

11.5   Simulace počítačových sítí pro výzkum mechanismů řízení zahlcení

Simulace a emulace sítí umožňují porovnávání různých variant řešení všech částí architektury počítačových sítí a vyhodnocování jejich výkonnostních charakteristik za definovaných a opakovatelných podmínek, na rozdíl od reálných sítí s datovým provozem s nepředvídatelnou dynamikou. Nejrozšířenějším programem pro simulace sítí je ns2. Naše zkušenosti s použitím ns2 pro studium mechanismů řízení zahlcení i několik našich rozšíření, která jsme do ns2 implementovali, jsme popsali v technické zprávě CESNETu 26/2003 "Experience with using simulations for congestion control research".

Ns2 je volně šiřitelný, diskrétní, objektově-orientovaný simulátor poskytující prostředky pro vytvoření modelu sítě, specifikaci vstupních dat i pro analýzu a prezentaci výsledků. K dispozici je i zdrojový kód simulátoru, což uživatelům umožňuje přidávat podporu pro nové komunikační protokoly, monitorovací nástroje a podobně.

Zpoždění paketu mezi vysílajícím a přijímajícím počítačem je v reálné síti tvořeno následujícími čtyřmi komponentami. Ns2 simuluje všechny komponenty kromě poslední:

11.5.1   Instalace a simulační skripty

Ns2 je implementován v C++ a Tcl a měl by pracovat na každém operačním systému kompatibilním se standardem Posix. Ke své činnosti používá několik dalších balíků (např. Tcl/Tk, xgraph), které mohou být instalovány buď zvlášť nebo spolu s ns2 z takzvaného balíku "all-in-one". Instalace bohužel není tak jednoduchá, jak jsme zvyklí u GNU software, t.j. ve stylu "configure, make, make install", ale vyžaduje trochu více kroků.

Po instalaci ns2 můžeme začít vytvářet simulační skripty. Každý skript je napsán v jazyce Tcl a kompletně popisuje simulační úlohu. Zahrnuje popis síťové topologie, komunikačních protokolů a událostí, t.j. kdy mají být posílána jaká vstupní data. Je také možné specifikovat velikosti front směrovačů a limity pro TCP okénka. Vytváření simulačních skriptů je složitá úloha vyžadující znalost vytvářeného modelu sítě, tříd simulátoru ns2 a programování v Tcl.

11.5.2   TCP v ns2

Implementace TCP v ns2 má několik zajímavých vlastností. Za prvé, TCP v ns2 neimplementuje řízení toku (flow control) jako prevenci proti zahlcení přijímače. Je implementováno pouze řízení zahlcení (congestion control) jako prevence proti zahlcení sítě. Okénko zahlcení (cwnd) může růst až do limitu specifikovaného proměnnou window objektu TCP vysílače.

Za druhé, TCP v ns2 neimplementuje blokující volání pro předávání dat z vysílající aplikace do TCP vysílače. Musíme proto u linky odcházející z vysílající stanice nastavit dostatečně velikou frontu, aby nikdy nedošlo k jejímu naplnění v důsledku velkého objemu dat od vysílající aplikace.

Za třetí, TCP v ns2 neposkytuje přímo žádnou informaci o aktuální propustnosti. Je na uživateli, aby si sám vytvořil vhodnou podtřídu standardních tříd, která bude poskytovat informaci o aktuální propustnosti.

11.5.3   Příklad simulačního skriptu

Jednu z často používaných simulačních topologií znázorňuje obrázek. Počítače připojené ke směrovači R1 posílají data na počítače připojené ke směrovači R2. Celkový objem posílaných dat je vyšší než kapacita linky mezi směrovači R1 a R2, která tak vytváří úzké hrdlo (bottleneck). Tato linka má dále specifikované zpoždění a ztrátovost. Linky mezi počítači a směrovači jsou obvykle bezeztrátové a s konstantním zpožděním.

[Obrázek]

Obrázek 11.5: Jednoduchá simulační topologie

Je třeba provést následující kroky:

  1. Vytvořit objekt simulátoru ns2.
  2. Vytvořit objekty pro uzly, linky a fronty přiřazené k linkám a specifikovat jejich parametry, neboli vytvořit síťovou topologii.
  3. Vytvořit objekty pro TCP vysílač a přijímač.
  4. Vytvořit objekty pro vysílající a přijímající aplikaci a připojit je k objektům pro TCP vysílač a přijímač.
  5. Naplánovat události, zejména začátek a konec posílání vstupních dat a kdy má být simulace ukončena.
  6. Rozběhnout simulaci.

Příkladem simulačního skriptu zahrnujícího uvedenou topologii může být následující kód:

# 1. Vytvořit objekt simulátoru ns2
set ns [new Simulator]

$ns color 0 Red
$ns color 1 Blue

proc finish {} {
        exit 0
}

# 2. Vytvořit objekty pro uzly, linky a fronty přiřazené k linkám a 
# specifikovat jejich parametry, neboli vytvořit síťovou topologii
set pc1 [$ns node]
set pc2 [$ns node]
set r1 [$ns node]
set r2 [$ns node]
set em [new ErrorModel]

# Set link characteristics
$ns duplex-link $pc1 $r1 90Mb 20ms DropTail
$ns duplex-link $r1 $r2 50M 100ms DropTail
$ns duplex-link $r2 $pc2 90Mb 20ms DropTail

$ns queue-limit $pc1 $r1 6000000
$ns queue-limit $r1 $r2 300000

$ns duplex-link-op $pc1 $r1 orient right
$ns duplex-link-op $r1 $r2 orient right
$ns duplex-link-op $r2 $pc2 orient right

$em unit pkt
$em ranvar [new RandomVariable/Uniform]
$em set rate_ 0.0001
set streams 5
set segsize 1500

for {set i 0} {$i < $streams} {incr i} {
# 3. Vytvořit objekty pro TCP vysílač a přijímač
 set tcpz($i) [new Agent/TCP/Reno]
 set tcpc($i) [new Agent/TCPSink]
 $ns attach-agent $pc1 $tcpz($i)
 $ns attach-agent $pc2 $tcpc($i)
 $tcpz($i) set fid_ 0
 $tcpc($i) set fid_ 1
 $ns connect $tcpz($i) $tcpc($i)
 $tcpc($i) listen
 $tcpz($i) set window_ 500
 $tcpz($i) set segsize_ $segsize 
# 4. Vytvořit objekty pro vysílající a přijímající aplikaci
# a připojit je k objektům pro TCP vysílač a přijímač
 set snd($i) [new Application/FTP]
 set rcv($i) [new Application/TCPCNT]
 $snd($i) attach-agent $tcpz($i)
 $rcv($i) attach-agent $tcpc($i)
}

set null [new Agent/Null]
$em drop-target $null
$ns lossmodel $em $r1 $r2

# 5. Naplánovat události, zejména začátek a konec posílání
# vstupních dat a kdy má být simulace ukončena
for {set i 0} {$i < $streams} {incr i} {
 $ns at 0 "$snd($i) start"
}
$ns at 0 "$rcv(0) settimer 0.1"
$ns at 0 "$tcpc(0) settimer 0.1"

for {set i 0} {$i < $streams} {incr i} {
 $ns at $TIME "$snd($i) stop"
}

$ns at $TIME "$rcv(0) stop"
$ns at $TIME "finish"

# 6. Rozběhnout simulaci
$ns run

11.5.4   Požadavky na paměť

Ns2 potřebuje operační paměť pro evidenci všech paketů, které jsou právě v síti. V rozlehlých vysokorychlostních sítích mohou být v kterémkoliv okamžiku v síti řádově desítky až stovky tisíc paketů. Potřebná operační paměť pak může dosáhnout řádu jednotek gigabajtů. Pro snížení nároků na objem operační paměti lze doporučit zařadit na začátek simulačního skriptu příkazy, kterými omezíme počet hlaviček, jež budou pro každý paket evidovány:

remove-all-packet-headers
add-packet-header TCP IP

11.5.5   Skripty pro dávkové zpracování

Pro vyhodnocování mechanismů řízení zahlcení v různých situacích často potřebujeme provést sadu simulací v určité síťové topologii s různými charakteristikami linky tvořící úzké místo. Můžeme chtít měnit propustnost, zpoždění, ztrátovost, ale i velikost paketů, počet paralelních toků dat, jejich trvání nebo granularitu výpočtu výsledných výkonnostních charakteristik. Dále můžeme chtít měnit rychlost reakce řízení zahlcení. Pro nastavování všech těchto parametrů v dávkovém zpracování a sledování dosažené propustnosti jsme vytvořili sadu skriptů. Jejich vzájemný vztah znázorňuje obrázek.

[Obrázek]

Obrázek 11.6: Skripty pro dávkové zpracování simulací

Činnost můžeme popsat následovně:

11.5.6   Monitorování propustnosti

Pro monitorování propustnosti na aplikační úrovni jsme vytvořili novou třídu Application/TCPCNT. Pro monitorování propustnosti na úrovni TCP jsme modifikovali třídu Agent/TCPSink. Podrobný popis obou těchto tříd je uveden v interní technické zprávě [UbK03] projektu.

11.5.7   Reakce na změnu volné kapacity

Pro studium reakce mechanismů řízení zahlcení na zvýšení nebo snížení volné kapacity trasy jsme vytvořili aplikaci Application/TCPFTP, kterou lze spojit s TCP vysílačem pro generování dávek paketů. Pro spuštění aplikace lze použít následující příkazy:

set snd [Application/TCPFTP]
$snd set interval_ n
$snd set burstsize_ m
$snd start

kde n je perioda dávek v sekundách a m je počet paketů o délce MSS, které budou poslány v jedné dávce. Pro zastavení aplikace můžeme použít příkaz:

$snd stop

11.5.8   Nastavení parametrů AIMD

Rychlost řízení zahlcení ve fázi slow start i congestion avoidance je v originálním TCP v ns2 pevná. Pro congestion avoidance jde o standardní AIMD(1, 0.5). Pro experimenty s novými návrhy Fast TCP je třeba mít možnost změny parametrů AIMD. Modifikovali jsme ns2 tak, že je možné nastavit rychlost jak fáze slow start, tak fáze congestion avoidance. Podrobný popis těchto rozšíření lze nalézt v interní technické zprávě [UbK03] projektu.

11.5.9   Asynchronní monitorování TCP charakteristik

Ns2 má zabudovánu možnost synchronního monitorování TCP charakteristik (cwnd, ssthresh,...) při každé změně některé charakteristiky. V některých případech může být přehlednější mít možnost asynchronního monitorování, které bude zaznamenávat hodnoty všech charakteristik pravidelně ve stanoveném časovém intervalu. Modifikovali jsme ns2 tak, aby poskytoval i asynchronní monitorování. Podrobnější popis lze opět nalézt v interní technické zprávě [UbK03] projektu.

11.5.10   Zjištěné problémy

Při simulacích s ns2 jsme se setkali s několika problémy nebo příznaky nečekaného chování:

Dokumentace těchto jevů a vysvětlení příčiny většiny z nich jsou uvedeny v interní technické zprávě [UbK03] projektu.

Simulátor ns2 v současné době používáme pro výzkum mechanismů pro řízení zahlcení v rozlehlých vysokorychlostních sítích. Připravujeme článek s návrhem některých úprav protokolu TCP pro tyto sítě.

11.6   Vytvořené programové balíky

V roce 2003 jsme v rámci projektu vytvořili několik programových balíků.

11.6.1   Hodnocení nástrojů pro odhad kapacity trasy

Tento programový balík byl použit pro srovnávací testy nástrojů pro měření a odhad kapacity trasy. Na základě zjištěných pozorování jsme vypracovali technickou zprávu CESNETu 25/2003 "End-to-end bandwidth estimation tools".

11.6.2   Analýza časových a geografických charakteristik datového provozu

Programový balík byl použit pro analýzu časových a geografických charakteristik netflow záznamů o mezinárodním provozu mezi sítí CESNET2 a sítí Géant a obecným Internetem. Technickou zprávu na dané téma připravujeme.

11.6.3   Sledování dynamických parametrů TCP spojení

Programový balík umožňuje nastavovat a sledovat některé důležité dynamické parametry TCP spojení. Jmenovitě umožňuje nastavovat parametry AIMD, vypínat, zapínat a monitorovat mechanismy CWV a CVR. Na základě měření s tímto programem chceme navrhnout vylepšení mechanismů pro řízení zahlcení a publikovat je v článku během 1. pololetí roku 2004.

11.6.4   Úprava emulátoru sítě NIST Net

Programový balík přidává do emulátoru sítě NIST Net možnost specifikace deterministické ztrátovosti a velikosti fronty emulovaného směrovače. Program bude zahrnut do technické zprávy o zkušenostech s emulacemi sítí, kterou plánujeme publikovat v 1. pololetí roku 2004.

11.7   Další aktivity projektu

Ve spolupráci s projektem Optické sítě a jejich rozvoj jsme provedli experimentální vyhodnocení možnosti přivedení technologie desetigigabitového Ethernetu až do koncové stanice. O výsledcích pozorování jsme zhotovili technickou zprávu CESNETu 10/2003 "Field trial with Intel 10Gigabit Ethernet adapters for PC".

Za důležitý výsledek projektu považujeme i navázání spolupráce se zahraničními partnery, které vedlo k zatím úspěšným jednáním o podílu CESNETu na několika projektech 6. rámcového programu Evropské Unie. Návrhy projektů jsou v současné době dokončovány nebo posuzovány.

11.8   Plánované aktivity

V dalším období chceme projekt zaměřit na tři oblastí. První oblastí je výzkum mechanismů pro řízení zahlcení ve vysokorychlostních sítích. Podařilo se nám v této oblasti získat rozsáhlé zkušenosti a máme rozpracované další publikace s návrhy na možná zlepšení. Druhou oblastí je performance monitoring. Zde chceme mimo jiné uplatnit výsledky mezinárodního projektu SCAMPI, který vyvíjí monitorovací platformu pro vysokorychlostní sítě na základě programovatelného hardware. Třetí oblastí je PERT. Druhá a třetí oblast by zároveň měly být součástí projektu GN2.

předchozí
obsah 		následující
další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz