nagysebességű internet hálózatok

RMKI szeminárium 2004 június 14. Nagy sebességű Internet hálózatok

1

Nagysebességű Internet Hálózatok

Telbisz Ferenc

Hogyan lehet kihasználni egy Gbit/s sebességű adatcsatorna kapacitását?


2

Tartalomjegyzék

• Az alapvető Internet protokollok fejlődése• Problémák a TCP protokollal• Új TCP protokoll javaslatok• Új UDP protokoll javaslatok• Egyéb javaslatok• Mérések• Hazai fejlesztési tervek• Zárszó


3

Az Internet protokollok• Az internet réteges szerkezetű

– OSI 7 réteg– Internet 5 réteg

Adatkapcsolati réteg( media control is )

Fizikai réteg

Hálózati réteg

Szállítási réteg

Alkalmazások

Sodrott érpárKoax. kábel

Üvegszál(D)WDM

Rádió

HDLC PPP Ethernet ATM FDDI

Telnet FTP SMTP IMAP POP3 HTTP

TCP UDP

IP

Az internet máig a TCP/IP protokoll

"stack"-en alapszik


4

Az Internet protokollok• 3. Hálózati réteg: IP

Feladata: a csomagok továbbítása a célállomásraKapcsolat nélküli protokoll semmit sem tud garantálni

(kivéve hibamentes csomagátvitel)• 4. Szállítási réteg: TCP

Feladata: hibamentes kommunikáció (end-to-end)Funkciók:

– fragmentálás/defragmentálás (bitfolyam tördelése csomagokra)– sorrendhelyesség– adatvesztés nélkül– hibajavítás (ismétlés)– torlódásvezérlés és torlódásvédelem

Felhasználói program kapcsolat: portok

4. Szállítási réteg: UDP: funkció nélküli protokoll !Feladata: közvetlen IP hozzáférés az alkalmazások számáraFelhasználói program kapcsolat: portok


5

Az IP protokoll változásai• Az IP protokoll fejlődése:

– Útválasztó (routing) protokollok fejlődése: RIP, BGP, IS-IS, OSPF, …

– QoS (Quality of Service) fejlődése: DiffServ (Differentiated Services)

IP headerben 6 bit: osztály (prioritás) jelzésre (IPv4, IPv6)Az egyes osztályok kezelése eltérő:

– prioritás– allokált sávszélesség

. . .Eredmény: VoIP (Voice over IP), ...

– MPLS: kapcsolástechnika (switching) használata ( "jó" ATM )• routing: célcím kikeresése táblázatból• kapcsolás: csomagban levő címke használata táblázat indexként


6

MAC header


7

Az IP protokoll változásai• Az IP protokoll fejlődése:

– Útválasztó (routing) protokollok fejlődése: RIP, BGP, IS-IS, OSPF, …

– QoS fejlődése: DiffServ (Differentiated Services)IP headerben 6 bit: osztály (prioritás) jelzésre (IPv4, IPv6)Az egyes osztályok kezelése eltérőEredmény: VoIP (Voice over IP), ...

– MPLS: kapcsolástechnika (switching) használata ( "jó" ATM )• Routing: célcím kikeresése táblázatból• kapcsolás: csomagban levő címke használata táblázat indexként

Eredmény: Traffic Engineering, Virtual Private Networks (VPN),

. . . .• Az IP összhangban van a korszerű követelményekkel:

• adatátviteli technikák,• az Internet mérete és forgalma


8

A TCP protokoll változása • A TCP az elmúlt 20 évben lényegében nem változott

Túlélte az Internet robbanásszerű fejlődést, a lassú vonalakatInkább más szállítási protokolokkal foglakoztak, pl. RTP

• A TCP torlódásvezérlése– a csomagvesztésen alapul– jól követte az Internet fejlődését:

méret, sebesség, terhelés, konnektivitás: több nagyságrendű változás

– jól működött a kis sebességű hálózatoknál,megakadályozta/csökkentette a nagy torlódások

kialakulását,– mai általános használathoz jól illeszkedik:

nagyon sok párhuzamos átvitel, mérsékelt sebességa web "emberi fogyasztásra" készült (emberi sebesség)


9

A TCP protokoll változása • A jelenlegi TCP (Reno) nem hatékony

– a nagy sávszélességű és nagy késleltetésű (a sávszélesség X késleltetés nagy) high bandwidth-delay product

– és kis csomagvesztésű hálózatokbanCsomagvesztés oka lehet:

– adathibák ma: 10- 5 (csomagszinten)– torlódás ma: olcsó memória buffer igen nagy lehet

• Problémák jelenkeznek:– Nagy adatmennyiség mozgatásánál (terabyte, petabyte) :

HEP, Csillagászat, Földtudományok, Bioinformatika, …– GRID számításoknál

• Mi okozza a problémát a TCP-nél?


10

TCP torlódásvezérlés– Congestion window: az "úton levő" csomagok száma (cwnd)– Visszaszabályozás: a csomagvesztés (nyugták) alapján:– Slow start (lassú indulás):

Induláskor: cwnd = 1 Byte-ban: cwnd x ( maximális szegmens méret )

általában 1500 byte– Növelése, ha minden rendben (nyugta érkezik):

– Exponential backoff: ha torlódás van (csomagvesztés):

AIMD algoritmus: Additive Increase, Multiplicative Decrease


11

Tipikus torlódási ablak méret változás


12

TCP torlódásvezérlés

– Standard TCP kapcsolatnál:• 1500 Byte-os csomagok,• 100 ms round-trip idő,• stacionárius átvitel 10 Gbps-nál

– szükséges lenne a "cső" kitöltéséhez:• átlagos "congestion window": 83,333 segmens,• ez legföljebb egy csomag eldobása 5 000 000 000 csomagonként

(legföljebb egy csomag eldobása 100 percenként).

Nagy "congestion window" fenntartása nem megy:

Sally Floyd (ICIR)

Nem reális követelmény !– Ugyanilyen követelmény 100 Mbps-nél ("cső" kitöltéséhez):

• a csomageldobási arány: 1 csomag 500 000 -ből(egy csomag eldobása percenként)

Egy kapcsolaton elérhető max. sebesség: ~ 200 Mbps


13

Szempontok az új protokollhoz– Teljesítmény

• alacsony sebességnél és kis RTT-nél legyen hasonló a hagyományoshoz– Torlódásvezérlés

• Nyilvános Interneten legyen hatékony torlódásvezérlés• Privát hálózaton kell-e ez ?

– Legyen TCP barát (TCP kompatibilitás)• torlódás esetén ne vegye el a sávszélességet a TCP-től

– Protokollon belüli "tisztességesség"– Bevezetés, telepítés egyszerűsége:

a. felhasználói könyvtár módosításab. operációs rendszer kernel módosításac. router-ek módosítása

– Analitikus modell• a viselkedés ellenőrzése• fejlesztők segítsége

– Univerzális használhatóság ? ("One size fits all")


14

Lehetőségek az új protokollokra

• TCP alapú módszerek• UDP alapú módszerek• Egyéb módszerek


15

TCP protokoll javaslatok• Javaslatok a módosításra:

– Fast TCPCalifornia Institute of TechnologyURL: http://netlab.caltech.edu/FAST/

– HighSpeed TCPICIR (ICSI Center for Internet Research), BerkeleyURL: http://www.icir.org/floyd/hstcp.html

– Scalable TCPCambridge University, Engineering Department (CERN)URL: http://www-lce.eng.cam.ac.uk/~ctk21/scalable/

– XCP (eXplicit Congestion control Protocol)MIT's Lab for Computer ScienceURL: http://www.ana.lcs.mit.edu/dina/XCP/

. . . . .


16

Fast TCP– Fejleszti: California Institute of Technology – Flow control: sorbanállási késleltetés (RTT) + csomagvesztés – Csak a küldőnél kell implementálni

AIMD


17

HighSpeed TCP• Fejlesztő: ICIR (ICSI Center for Internet Research)

• Non-profit kutató intézet, Berkeley• Eredeti alapító AT&T, most:

ICSI (International Computer Science Institute) Független nonprofit kutató intézet Kapcsolat: Computer Science Division,

University of California at Berkeley

• Működés: TCP congestion window (cwnd): a hálózatban úton levő csomagok

száma – AIMD: átlagos cwnd = 1.2 / sqrt (P) p: packet loss– A cwnd másképpen: AIMD helyett 3 paraméteres algoritmus, – Ez gyakorlatilag több párhuzamos adatfolyam emulálása

• Implementáció: Linux


18

Scalable TCP• Fejlesztő: Laboratory for Communication Engineering,

Cambridge University, Engineering Department (Tom Kelly, CERN IT division)

• Működés:– egyszerű módosítás a hagyományos TCP torlódás vezérlésében:

cwnd := cwnd + 0.01 ha nyugta érkezettcwnd := 0.875 * cwnd ha csomagvesztés van

– gyorsabban növel, csomagvesztésnél kevésbbé csökkent

• Implementáció: Linux


19

XCP• Fejlesztő: MIT's Lab for Computer Science• Működés:

– Az Explicit Congestion Notification (ECN) módszer általánosítása– Csomagokhoz congestion header hozzáadása:

pontos információ a torlódás állapotáról– Congestion header-ben a küldő fél sávszélességet igényelhet– Közbenső router-ek ezt felülbírál(hat)ják

• Router-ekben is módosítás szükséges !


20

Mérések

• TCP Stacks on production links (SLAC, Web100 projekt):Internet End-to-end Performance Monitoring

http://www-iepm.slac.stanford.edu/monitoring/bulk/tcpstacks/index.html• Single és multiple stream mérések működö hálózaton• Néhány példa: “single stream” mérések• Mérési konfiguráció a single stream méréseknél:


21

Mérések

Fast TCP Throughput Average = 233.2 Mbps Std Dev = 82.1 Mbps

Reno TCP Throughput Average = 89.4 Mbps Std Dev = 69.9 Mbps

RTT RTT Average = 230 ms Std Dev = 9 ms


22

Mérések

High Speed TCP Throughput Average = 252.5 Mbps Std Dev = 70.9 Mbps


RTT RTT Average = 229.8 ms Std Dev = 9.8 ms


23

Mérések

Scalable TCP Throughput Average = 261.5 Mbps Std Dev = 64.6 Mbps


RTT RTT Average = 229.2 ms Std Dev = 10.4 ms


24

Mathieu Goutelle et al.:A Survey of Transport Protocols other than Standard TCP (2004.)

TCP javaslatok összehasonlítása


25

UDP alapú módszerek• UDP alapú módszerek

– Előnyök: • egyszerűbb implementálni: felhasználói könyvtárak• jó hatásfok

– Hátrányok:• Nincs torlódásvezérlés (torlódásvezérlést a hálózat végzi)

– Több projekt van itt is:UDT (UDP-based Data Transport).

Reliable Blast UDP

TSUNAMI. . . . .


26

UDT (UDP-based Data Transport)• Fejlesztő: University of Illinois in Chicago• URL: http://www.lac.uic.edu/

projekt: http://www.dataspaceweb.net/sabul.htm• SABUL: Simple Available Bandwidth Utilization Library

– UDP: az adat átvitelre: sorszámozott csoamgok– TCP: kontrol információ és hibajavítás

• nyugta (ACK, NAK), RTT• elveszett csomagok ismétlése

• Flow control:– adatküldés:

• lényegében állandó "interpacket time" (rate control)• az RTT és a csomagvesztés szerint szabályozva

• Implementáció: Linux, BSD, Unix


27

UDT Implementáció: Teljesítmény


28

UDT ImplementációIntra-protocol Fairness

Nagyobbléptékben


29

UDT ImplementációTCP Friendliness


30

UDP javaslatok összehasonlítása

Mathieu Goutelle et al.:A Survey of Transport Protocols other than Standard TCP (2004.)


31

Más módszerek• DWDM optikai hálózatok

– Optikai kapcsolók– National Lambda Rail– Optikai Hálózati Protokollok

Pl.: JIT (Just in Time) protokol (MCNC – North Carolina Univ.)– Előjelzés a kapcsolóberendezésnek az adatokról– A kapcsoló elemeket konfigurálják az adatokhoz (Tell & Go)

nem Tell & Wait– Valamennyi késleltetéssel mennek az adatok– Adat lehet egy blokk vagy hosszab kapcsolat


32

Hazai fejlesztési tervekEgyetemközi Távközlési és Informatikai Központ (ETIK)

• Nagy sebességű transzport protokollok– Új TCP verziók teljesítményelemzése és összehasonlítása

• szimuláció és kísérleti hálózati mérés• vizsgálandó: throughput, link kihasználtsága, igazságosság

(fairness)– Paraméterek optimalizálása

• az egyes TCP variánsok optimális környezetének meghatározása– Szabályozáselmélet-alapú vizsgálat

• globális stabilitás vizsgálata– Állapot-alapú modellezés– Csomagsorozatok módszerének alkalmazása– Sorbaállási késleltetés mérése

• Potenciális együttműködök: ETIK, BME, KFKI RMKI, MTA SZTAKI, MATÁV, stb.


33

Zárszó• Többféle elgondolás van, egyik sem domináns• Vannak implementációk is• További vizsgálatok kellenek• Kell ez nekünk?

– "Commodity" internetnek egyenlőre valószínűleg nem– Kutatás és néhány speciális terület: biztosan kell– Egyéb, pl. orvosi alkalmazások (hype effektus)

• Epilogus: egy internet átviteli rekord


34

Epilógus

• 40 router-en keresztül• 4.226 Gbit/sec (26m 28s)• software: ttcp (test TCP)

• SUNET Internet2 Single stream Land Speed Record• From San Jose, CA, USA to Lulea*, Sweden

Hogyan is történt, mi nincs rendben ?modell, protokoll, hibaarány ?


35

Köszönöm a figyelmet

nagysebességű internet hálózatok

Documents