Nagysebességő Internet Hálózatok

Nagysebességő Internet Hálózatok Hogyan lehet kihasználni egy Gbit/s sebességő adatcsatorna kapacitását? Telbisz Ferenc

RMKI szeminárium 2004 június 14.

Nagy sebességő Internet hálózatok

1

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ó



2

Az Internet protokollok • Az internet réteges szerkezető – OSI 7 réteg – Internet 5 réteg Alkalmazások

Telnet

TCP

Szállítási réteg Hálózati réteg Adatkapcsolati réteg ( media control is ) Fizikai réteg

FTP

SMTP

UDP

IP HDLC

PPP

Sodrott érpár


Koax. kábel

IMAP

POP3

HTTP

Az internet máig a TCP/IP protokoll "stack"-en alapszik Ethernet

ATM

Üvegszál (D)WDM


FDDI Rádió

3

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

IP

Feladata: a csomagok továbbítása a célállomásra Kapcsolat 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ára Felhasználói program kapcsolat: portok RMKI szeminárium 2004 június 14.


4

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



5

MAC header



6

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 RMKI szeminárium 2004 június 14.


7

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ú vonalakat Inká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ég a web "emberi fogyasztásra" készült (emberi sebesség)



8

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ózatokban Csomagveszté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?



9

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 RMKI szeminárium 2004 június 14.


10

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



11

TCP torlódásvezérlés Nagy "congestion window" fenntartása nem megy: Sally Floyd (ICIR)

– 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).

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 RMKI szeminárium 2004 június 14.


12

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ása b. operációs rendszer kernel módosítása c. 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") RMKI szeminárium 2004 június 14.


13

Lehetıségek az új protokollokra • TCP alapú módszerek • UDP alapú módszerek • Egyéb módszerek



14

TCP protokoll javaslatok • Javaslatok a módosításra: – Fast TCP California Institute of Technology URL: http://netlab.caltech.edu/FAST/ – HighSpeed TCP ICIR (ICSI Center for Internet Research), Berkeley URL: http://www.icir.org/floyd/hstcp.html

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

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

.....



15

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



16

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



17

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 cwnd := 0.875 * cwnd

ha nyugta érkezett ha csomagvesztés van

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

• Implementáció: Linux



18

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 !



19

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:



20

Mérések

Fast TCP

Throughput Average = 233.2 Mbps

Std Dev = 82.1 Mbps

Reno TCP


Std Dev = 69.9 Mbps

RTT

RTT Average = 230 ms

Std Dev = 9 ms



21

Mérések

High Speed TCP Throughput Average = 252.5 Mbps

Std Dev = 70.9 Mbps

Reno TCP


Std Dev = 52.4 Mbps

RTT

RTT Average = 229.8 ms

Std Dev = 9.8 ms



22

Mérések

Scalable TCP


Std Dev = 64.6 Mbps

Reno TCP


Std Dev = 16.2 Mbps

RTT

RTT Average = 229.2 ms

Std Dev = 10.4 ms



23

TCP javaslatok összehasonlítása

Mathieu Goutelle et al.:A Survey of Transport Protocols other than Standard TCP (2004.) RMKI szeminárium 2004 június 14.


24

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

.....



25

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 RMKI szeminárium 2004 június 14.


26

UDT Implementáció: Teljesítmény



27

UDT Implementáció Intra-protocol Fairness

Nagyobb léptékben



28

UDT Implementáció TCP Friendliness



29

UDP javaslatok összehasonlítása

Mathieu Goutelle et al.:A Survey of Transport Protocols other than Standard TCP (2004.) RMKI szeminárium 2004 június 14.


30

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



31

Hazai fejlesztési tervek Egyetemkö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. RMKI szeminárium 2004 június 14.


32

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



33

Epilógus • •

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

• 40 router-en keresztül • 4.226 Gbit/sec (26m 28s) • software: ttcp (test TCP) RMKI szeminárium 2004 június 14.

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


34

Köszönöm a figyelmet



35

Nagysebességő Internet Hálózatok

Recommend Documents