Project Report (1998)

Átírás

1 lab TCP/IP forgalom analízise - esettanulmányok NETWORK INITIATED TCP FLOW CONTROL ALGORITHMS Project Report (1998) TECHNICAL UNIVERSITY OF BUDAPEST Dept. of Telecommunications and Telematics Távközlési és Médiainformatikai Tanszék Budapesti Műszaki és Gazdaságtudományi Egyetem Motivációk TCP CONTROL LOOP ABR CONTROL LOOP HOST1 ATM BACKBONE HOST2 LEGACY LAN1 ROUTER1 ROUTER2 LEGACY LAN2 2 1

2 Környezet GATEWAY 10 MB/sec. Ethernet 100 MB/sec. Ethernet S1,2: sender1,2 R1,2: receiver1,2 R1 R S1 S2 3 Hardver konfiguráció 1. Gateway Name: Rebeka, IP address: (100MB side) and (10MB side) Computer type: PC with P166 Intel processor 32 MB RAM memory 1 GB Hard Disk 3Com Fast Etherlink XL 3C905 Network Interface Card at the 100 MB side SMC Ultra 16bit Network Interface Card at the 10 MB side Operating system: LINUX Sender1 Name: proba, IP address Computer type: PC with P166 Intel processor 32 MB RAM memory 2x1 GB Hard Disk 3Com Fast Etherlink XL 3C905 Network Interface Card Dual boot system with LINUX 2.0 and LINUX 2.1 on the primary hard disk and NetBSD 1.3 on the secondary hard disk. 3. Sender2 Name: David, IP address: Computer type: SunUltra Enterprise 450 with UltraSparc II processor at 248 MHz 248 MB memory 4 GB Hard Disk CheerIO 2.0 Network Interface Card SunOs Release 5.6 Operating system 3. Receiver1 Name: Fornax, IP address: Computer type: PC with P166 Intel processor 32 MB RAM memory 1 GB Hard Disk SMC Ultra 16bit Network Interface Card Dual boot system with LINUX 2.1 and LINUX Receiver3 Name: Pallas, Computer type: PC with P100 Intel processor 16MB RAM memory 1 GB Hard Disk SMC Ultra 16bit Network Interface Card Multiple boot system with LINUX 2.0, LINUX 2.1 and NetBSD 1.3 operating systems. 4 2

3 Szoftverek Linux 2.0 Linux 2.1 NetBSD 1.3 SunOS Release 5.6 Különböző TCP implementációk Linux 2.0 implementáció Minden követelményt teljesít, mely a RFC 1122 és RFC 2001-ben van Slow start algorithm V. Jacobson s congestion avoidance algorithm Fast retransmit algorithm Fast recovery algorithm Implementáció neve: TCP Reno 5 Szoftverek 2 Linux 2.1 megvalósítás ugyanazokkal a jellemzőkkel bír, mint az előző, kisebb módosításokkal: a TCP kód újraírt IPv6 bővítés miatt Választható TCP Vegas kód is belekerült, mely alapértelmezés szerint inaktív 6 3

4 A TCP Vegas előnyei Sokkal pontosabb időzítési döntések, csomagújraküldések esetén (pontosabb RTT becslésen alapul a TCP timing opciójával) Pontosabb congestion avoidance mechanizmus (a mért és az elvárt teljesítmény összehasonlításán alapul) Módosított slow start mechanizmus (az elérhető sávszélesség becslésére felhasználja a nyugták érkezése közötti időket) 7 Packet Processing at TCP and IP level GATEWAY Ethernet1: 10 MB/s Ethernet2: 100 MB/s DATA ACK DATA ACK Device Driver Device Driver q0 q1 Output queues, based on TOS bit priorities Default size: 100 packets "Backlog" Queue Default size: q2 300 packets q0 q1 q2 Protocol Independent Device support routines Algorithm * "Delayed" queue * * IP Module (IP forward Functionality) To the local TCP layer 8 4

5 sock (free software) Forgalom generálás Name Description one.1024 one connection three.1024 three connections started simultaneously many five connections started simultaneously five.1024.delay1s five connections, 1s delay between each connection s.start

6 lab Slow Start és nyugtaküldési stratégiák Távközlési és Médiainformatikai Tanszék Budapesti Műszaki és Gazdaságtudományi Egyetem No. Algo. Sender Traffic # conn. Receiver Kbytes/sec # ovfl. 413 None Linux 2.1 one Linux (gw)

7 Megjegyzések A fogadó csak egy ACK-t küld egy csomagcsoportra Minden ACK érkezése a küldőnél egy csomagbörszt küldését eredményezi A küldő a cwnd-t minden egyes ACK érkezésekor eggyel növeli A sorok hossza növekszik a börsztök érkezésekor, a börsztök méretei pedig növekednek az idővel ACK érkezések 10 ms-ként

8 Megjegyzések Kb 200ms után, a küldő eléri a fogadó meghirdetett ablakméretének felső határát A sorhosszúság kb. 15 körül stabilizálódik A sorok hossza a börsztök érkezésekor növekszik ezeket a fogadó egy-egy csomagcsoportot nyugtázó ACK-ra küldött A sorok hossza fokozatosan csökken függően a 10 Mbps-os Ethernet kapacitásától 15 Slow Start with Linux 2.1 receiver 16 8

9 Megjegyzések A fogadó minden fogadott csomagot nyugtáz Az ACK-k folyama az ellentétes irányban a routeren keresztül nem börsztös A küldő növeli a cwnd-t 1-gyel minden nyugta fogadásakor (nehezen látható az ábrán) A sorhossz egyenletesen növekszik, nem börsztösen Kb 40ms után, a küldő eléri a fogadó meghirdetett ablakának felső határát Ez 5-ször gyorsabban történik, mint a Linux 2.0 fogadó esetében Mert a Linux 2.1 több ACK-t küld, mely felgyorsítja a slow-start fázist A sorhossz 18-nál stabilizálódik 17 Slow Start with NetBSD sender and receiver 18 9

10 0-1ms 1-3ms 6ms 7ms 7-87ms 87ms ms 130ms- Magyarázat és megjegyzések SYN küldés, fogadó nyugtázza Küldő nyugtát küld és még két adatszegmenst Fogadó nyugtázza az adatcsomagokat Küldő további két csomagot küld Fogadó nem küld nyugtát Fogadó küldi a késleltetett nyugtát A slow-start hátralévő része A küldő elérte a jobb szélét a meghirdetett ablaknak, innentől a küldő kis börsztöket küld, ahogy kapja a nyugtákat A példa bemutatja, hogy ha a fogadónál csak két csomag nyugtája vár, késlelteti azok küldését legfeljebb addig, amíg az időzítés lejár. 90 ms után, az ACK-ot nem késlelteti tovább az implementáció nem használja ki a 200ms-ot, több mint 2 ACK késleltetésénél 90ms után, az ACK-k közti rések egyformák, kb 4 ms. A NetBSD 4 ms-os időzítést használ. 19 Slow Start with NetBSD 1.3 receiver and Linux 2.1 sender 20 10

11 Megjegyzések A fogadó (NetBSD) nem használja a 200ms-os időzítőt az ACK késleltetésre. A fogadó NetBSD TCP különbséget tud tenni a NetBSD 1.3 és a Linux 2.1 küldő között. A NetBSD küldő időbélyegeket küld a TCP option mezőjében (12 bájt). A NetBSD fogadó különböző nyugtázási stratégiákat használ, függően a timestamp mező jelenlététől, tartalmától A NetBSD fogadó minden csomagot külön-külön nyugtáz 21 lab Csomagvesztések és torlódás elkerülés Távközlési és Médiainformatikai Tanszék Budapesti Műszaki és Gazdaságtudományi Egyetem 11

12 No. Algo. Sender Traffic # conn. Receiver Kbytes/sec # ovfl. 443 None Linux 2.1 one Linux (gw) Megjegyzések A slow start börsztös csomagvesztéssel és az adás szüneteltetésével ér véget Periódikus vesztések láthatók, melyeket a küldő gyorsan javít a vesztések nem okoznak jelentős teljesítménycsökkenést A sorhosszban periódikus minta van 300 ms után: lineáris növekedés, egy vesztés, egy esés. Ez mutatja a congestion avoidance mechanizmus működését a küldő oldalon: a vesztés észrevételekor csökkenti a congestion window értékét, majd ismét lineárisan (additívan) növeli 24 12

13 Az első 80 ms 25 Magyarázatok 26-36ms A fogadó felé a sorok túlcsordulnak, a csomagok eldobásra kerülnek 37-45ms 44-47ms A fogadó felé menő csomagok továbbításra kerülnek, a fogadó fogadja ezeket a csomagokat, de nem nyugtázza őket, mert néhány korábbi csomag is hiányzik A fogadó duplikált ACK-t küld 48ms A küldő újraküldi az első nemnyugtázott csomagot (fast retransmit) ms A fogadó továbbra is duplikált ACK-kat küld 76ms A fogadó nyugtázza az újraküldött csomagokat 26 13

14 200 ms környéke ms ms 275ms 330ms- Magyarázatok A küldő időzítője lejár és küld egy következő nemnyugtázott csomagot. Az időztés kb 200 ms A küldő továbbít egy csomagot rögtön, amint a fogadó nyugtázta az előzőt. A küldő nem növeli a congestion window méretét, amíg újraküldést végez A küldő minden elküldött adatára kap nyugtát (Az ACK számok ugrása). Slow start kezdődik. A gyors (exponenciális) növekedése a nemnyugtázott csomagoknak megáll és congestion avoidance szakasz következik ez látszik a sorhossz lineáris növekedéséből Börsztös csomagvesztés történt Az első vesztést a küldő vette észre a duplikált ACK-ból, és gyors újraküldés következett A következő vesztéseket szintén a küldő vette észre az időzítők lejáratakor emiatt slow start indult Ez a mechanizmus börsztös vesztéseknél gyakori 28 14

15 870 ms környéke ms ms ms 869ms ms 885ms Magyarázatok Egy csomag veszett el a közbenső sorok megtelése miatt A fogadó a korábbi csomagokat nyugtázza A fogadó a további csomagokat nem tudja nyugtázni, mert egy hiányzik. Emiatt a fogadó duplikált ACK-t küld A küldő 3 duplikált ACK-t kap, majd gyors újraküldést hajt végre A küldő folytatja a csomagok küldését, mivel nem érte el a fogadó advertised window méretét még. Egy ugrás látható az ACK numberek között a fogadó megkapta a hiányzó csomagot, és az azutániakkal együtt nyugtázta azt. 885ms- A küldő folytatja a csomagok továbbítását (fast recovery történt: slow start nem következik most). A gyors újraküldés nem okozott nagy teljesítmenycsökkenést 30 15

16 No. Algo. Sender Traffic # conn. Receiver Kbytes/sec # ovfl. 449 None Linux 2.1 one Linux (gw) 3 31 Megjegyzések A küldő forgalma nagyon börsztös nagyon ingadozó a sorhossz a közbenső routerben A börsztösség oka a fogadótól ritkán érkező nyugták A slow start vége csomagvesztéssel szünet következik a küldésben A küldő congestion window növekedése lassabb, mint a Linux 2.1 implementációban, mivel a congestion avoidance nyugtákkal vezérelt a ritkán érkező nyugták okozzák a lassú növekedést A buffer tartalmának lassú növekedése miatt a veszteségek sokkal ritkábbak 32 16

17 180 ms környéke 33 Magyarázatok 135ms ms 153ms ms 156ms ms ms A börszt utolsó csomagja elveszett Küldő fogadja az ACK-okat (az elveszett csomag előtti csomagokét) és újabb börsztöt küld az ACK-ra válaszként Még egy csomag elveszik A küldő kap egy ACK-t és 3 duplikált ACK-t A küldő fast retransmitot hajt végre a duplikált ACK-k hatására A küldő folytatja a csomagok küldését, megteheti, mert a fogadó meghirdetett ablakméretét még nem töltötte ki Küldő megkapja a nyugtákat, melyek a 2. csomagvesztés óta érkezett csomagokat nyugtázza. Kap még duplikált nyugtákat is, de nem hajt végre gyors újraküldést már korábban végrehajtotta 34 17

18 300 ms környéke 35 Magyarázatok 360ms 385ms A küldő időzítője lejár (kb 200 ms elteltével), és újraküldi a második elveszett csomagot Slow start kezdődik Az első vesztést a duplikált ACK-k jelezték, míg a második vesztést a küldő időzítőjének lejárása jelezte Az időzítés után slow start kezdődött, bár hamar congestion avoidance állapotba ment át

19 1560 ms környéke 37 Magyarázatok 1525ms 1561ms ms 1545ms 1558ms Egy csomag elveszett, buffer túlcsordulás miatt az egyik börszt végén A küldő folytatja a küldést A küldő gyors újraküldést hajt végre a harmadik egyforma ACK hatására A fogadó fogadja az újraküldött csomagot és a korábban érkezőket is A küldő folytatja a küldést, a congestion window méretét csökkentette, ami látszik a kisebb sorhosszakból is Egy csomag elvesztése hatékonyan kezelhető a fast retransmit algoritmussal A fast retransmit után viszont nem slow start következik, de a cwnd értéke csökkentésre kerül 38 19

20 No. Algo. Sender Traffic # conn. Receiver Kbytes/sec # ovfl None SunOS 5.6 one Linux (gw) ms 40-50ms 60ms 80ms ms ms 145ms ms 180ms 210ms Slow start kezdődik Normális adatátvitel Magyarázatok Sortúlcsordulás, csomagok vesznek el A küldő fast retransmitot hajt végre 3 duplikált ACK után Küldő megkapja az újraküldött csomagra a nyugtát, rögtön továbbítja a következő csomagot. Egy csomag elveszik a buffer túlcsordulása miatt A küldő újraküld minden csomagot, ahogy fogadja a nyugtákat az előzőkről A küldő prhuzamosan újraküld és küld csomagokat, ahogy a cwndje engedi, a cwnd lecsökkent az ablakméret felére A küldő fogadja az összes újraküldött és újonnan küldött csomagra a nyugtákat, ezek a nyugták egyszerre több csomagot nyugtáznak, így a küldő több csomagot is küldhet egyszerre A küldő duplikált ACK-kat kap és újraküldi az elveszett csomagot 40 20

21 lab Szimultán kapcsolatok Távközlési és Médiainformatikai Tanszék Budapesti Műszaki és Gazdaságtudományi Egyetem No. Algo. Sender Traffic # conn. Receiver Kbytes/sec # ovfl. 553 none Linux 2.1 many Linux (gw)

22 Megjegyzések Túlcsordulások gyakoriak, ilyenkor a sorban eldobások történnek, de ezután az hamarosan újra megtelik és újabb eldobás következik A zöld, piros és kék kapcsolatok 3 mp-cel később indulnak, bár maguk a kapcsolatok hamarabb indultak, de a SYN csomagok elvesztek: újraküldési lehetőség csak az időzítés lejárata után volt lehetséges. Ez nagy teljesítmény csökkenést eredményezett 3mp előtt nem történt adatátvitel 700ms és 1300ms, 6 csomagvesztés történt, mind a 6 ugyanattól a kapcsolattól (világoskék), mely sokkal alacsonyabb sávszélességet kapott a feketénél az első mp-ben ms 44 22

23 Megjegyzések 0-40ms 50ms 98ms 105ms 140ms ms 145ms 171ms ms 190ms 210ms 215ms Fekete kapcsolat slow start fázisban van. A küldő ki tudja használni a fogadó teljes advertised window, mert az útválasztó mind a 18 csomagot el tudja tárolni Világoskék indítja a kapcsolatot A zöld indítja a kapcsolatot, de a SYN csomag elveszik a túlcsordulás miatt Egy fekete csomag is elveszik A fekete küldő kap 3 duplikált ACK-t és újraküld A router a fekete csomagokat továbbítja sorhossz csökken a fogadó duplikált ACKokat küld mert egy csomag hiányzik Piros kapcsolat felépítés de a SYN elveszik A fekete fogadó fogadja az újraküldött csomag nyugtáját így egy teljes ablaknyi adatot küldhet ez megtölti a router sort úgy, hogy a börszt utolsó csomagját el is dobja A buffer megtelik miközben a világoskék kapcsolat slow startban van Kék kapcsolat SYN csomaggal indít el is veszik Világoskék küldő újraküldi az eldobott csomagot Fekete küldő fast retransmitot végez 45 Összegzés A fekete kapcsolat magához ragadta a sávszélesség nagy részét, mert ez kezdte az átvitelt elsőnek. A világoskék kapcsolat nem tud magához ragadni annyi sávszélességet, mint a fekete: később indult már a slow start fázisban is köszönhetően a fekete kapcsolat csomagjainak a telített sorok miatt gyakran szenvedett csomagvesztést 46 23

24 No. Algo. Sender Traffic # conn. Receiver Kbytes/sec # ovfl. 686 none Linux 2.1 five.1024.delay1s 5 Linux (gw)

25 Magyarázatok -4150ms ms ms ms 4315ms A piros kapcsolat javítja a vesztéseket A piros kapcsolat slow start fázisban van és fokozatosan növeli a cwnd méretét így nő a sorhossz a routerben is A kék kapcsolat slow-starttal kezd cwnd mérete exponenciálisan növekszik A kék kapcsolat csomagbörsztöket küld a slow-start fázisban is ezek elvesznek, mert a sorban sok más csomag is sorakozott a piros kapcsolatból A kék adó fast retransmitot végez a 3 duplikált ACK hatására Egy új kapcsolat kezdetekor a cwnd mérete gyorsan növekszik slow start miatt Egy új kapcsolat esetén nagyobb az esélye, hogy a sor túlcsordul mert az már tele van más csomagokkal Nagyobb a valószínűsége a vesztéseknek, több újraküldés és időzítés lejárata kisebb teljesítmény 49 No. Algo. Sender Traffic # conn. Receiver Kbytes/sec # ovfl. 589 None Linux 2.1 many Linux (gw)

26 Megjegyzések Az összes kapcsolatnak sok a vesztése A sorhossz csökken a csomageldobások után, de hamar megtelik ez a Reno congestion avoidance megvalósításának jellemzője A sorhossz gyorsan változik, mert a nyugták sok csomagot nyugtáznak folyamatosan, melyre válaszképpen a küldők csomagbörszöket tesznek a hálózatra 51 lab TCP Vegas kód a küldőben Távközlési és Médiainformatikai Tanszék Budapesti Műszaki és Gazdaságtudományi Egyetem 26

27 No. Algo. Sender Traffic # conn. Receiver Kbytes/sec # ovfl. 826 none Vegas Linux 2.1 one Linux (gw) 0 53 Megjegyzések A küldő sebessége egységes a vizsgálat alatt A küldő elkerülte a routerbeli torlódást (mely Reno esetében viszont előfordult volna). A sorhossz 0 (ez lehetséges, még akkor is ha egy vagy két csomag a kártya bufferében van) 54 27

28 55 Megjegyzések A slow start véget ér csomagvesztés nélkül, ebben az esetben a TCP Vegas elkerüli a routerbeli torlódást a szűk sávszélességű link előtti csomópontban A congestion window nem haladja meg a 4-es értéket, ahogy az látszik a csomagok és a nyugták sorszámából is 56 28

29 No. Algo. Sender Traffic # conn. Receiver Kbytes/sec # ovfl. 814 none Vegas Linux 2.1 one Linux (gw)

30 Megjegyzések A teljesítmény lcsökkent kb a felére a Linux 2.1 fogadójában! ( ról Kbytes/sec-ra) A sorhossz 0 és 2 között mozog A küldő csomagbörsztöket küld az ACK-k megérekzésekor. Ezek a börsztök legfeljebb 4-ig növekednek a Vegas küldő 4-nél maximalizálta a congestion window méretét A küldő megvárja az ACK-t, majd kiküld 4 csomagot, mivel az ACK-k kb 10ms-ként érkeznek, a küldő kb 4 csomag/10 ms-mal továbbít, mely igen alacsony sebesség Példa bemutatja, hogy a Linux 2.1 Vegas kódja nem igazán tudja kezelni a Linux 2.0 ritka nyugtáit 59 No. Algo. Sender Traffic # conn. Receiver Kbytes/sec # ovfl. 835 none Vegas Linux 2.1 five.1024.delay1s 5 Linux (gw)

31 Megjegyzések Egy kapcsolattal a buffer hossza 0 Egy kapcsolat hozzáadásával a sorhossz 4 csomaggal hosszabb lesz A TCP Vegas küldő esetén, a sorhossz kb. arányos az aktív kapcsolatok számával 61 No. Algo. Sender Traffic # conn. Receiver Kbytes/sec # ovfl. 825 none Vegas Linux 2.1 five.1024.delay1s 5 Linux (gw)

32 Megjegyzések A teljesítmény ismét alacsonyabb, mint a Linux 2.1 fogadó esetében ( ről Kbytes/sec-ra esett), de a csökkenés nem olyan nagy mértékű A sorhossz nagyon gyorsan ingadozik, mert egy ACK nyugtáz több csomagot, így a küldő kis csomagbörsztöket küldhet. 4500ms-nál, a gyors sorhossz változás túlcsordulást eredményezett 63 32