UNIVERSITATEA POLITEHNICA DIN BUCUREŞTI Facultatea de Automatică şi Calculatoare Departamentul Calculatoare TEZĂ DE DOCTORAT REZUMAT

Transcription

1 FONDUL SOCIAL EUROPEAN Investeşte în oameni! Programul Operaţional Sectorial pentru Dezvoltarea Resurselor Umane Proiect POSDRU/107/1.5/S/76813 Burse doctorale: investitii in cercetare-inovare-dezvoltare pentru viitor (DocInvest) UNIVERSITATEA POLITEHNICA DIN BUCUREŞTI Facultatea de Automatică şi Calculatoare Departamentul Calculatoare TEZĂ DE DOCTORAT REZUMAT Transferul rapid, în paralel, al datelor în reţele WAN Fast Parallel Data Streaming Transfers in WAN Networks Autor: Ing. Dan Schrager Conducător de doctorat: Prof.dr.ing. Valentin Cristea Bucureşti, 2013

2 CUPRINS 1. INTRODUCERE MOTIVAREA CERCETĂRII OBIECTIVELE CERCETĂRII STUDIU COMPARATIV AL TEHNICILOR ŞI APLICAŢIILOR DE TRANSFER DE DATE ÎN REŢEA TRANSFERURILE DE DATE ŞI MEDIUL GRID Serviciul FTS SISTEMUL PROTOCOALELOR DE COMUNICAŢIE ÎN REŢEA Protocolul TCP Performanţele TCP Performanţa conexiunilor TCP multiple DIVERSE IMPLEMENTĂRI ALE TCP TCP Sack TCP Vegas HighSpeed TCP Fast TCP MPTCP MulTCP MANAGEMENTUL ACTIV AL COZILOR DIN RUTERE (AQM) Algoritmul RED Algoritmul BLUE Algoritmul SFB PROTOCOALE NON-TCP XCP SCTP DCCP APLICAŢII DE TRANSFER RAPID XFTP Psockets Globus GridFTP RBUDP SABUL GridFTP Overlay SUMAR

3 3. ARHITECTURA SISTEMULUI DE TRANSFER DE DATE ARHITECTURĂ CAPABILITĂŢI CLIENT-SERVER SUPLIMENTARE MODELUL COZILOR DE TIP FORK-JOIN Performanţa sistemului SUMAR ALGORITMI EFICIENŢI DE TRANSMISIE PARALELĂ CARACTERISTICI ALE ALGORITMILOR DE TRANSFER Importanţa suportului pentru multi-path Specificaţii pentru multi-path FAZELE ALGORITMULUI DE TRANSFER Transmisia fără ponderare Controlul transmisiei cu ponderare Strategii de optimizare a ponderării transmisiei Pseudocodul algoritmului de transmisie (cu ponderare opţională) SUMAR METODOLOGIE DE VALIDARE ŞI REZULTATE EXPERIMENTALE CONSIDERAŢII METODOLOGICE Platforme de test PERFORMANŢA ÎN FLUX CONTINUU ŞI CEA ORIENTATĂ FIŞIER Cazul transferurilor de directoare PERFORMANŢELE TRANSMISIEI ÎN FLUX CONTINUU Experimente în regim static Experimente în regim dinamic Cazul transferurilor de tip split-tcp ANALIZA REZULTATELOR EXPERIMENTALE Consideraţii cantitative Analiza regimului ponderat şi neponderat SUMAR CONCLUZII ŞI DIRECŢII DE CERCETARE VIITOARE CONTRIBUŢIILE TEZEI DISEMINAREA CERCETĂRII DIRECŢII DE CERCETARE VIITOARE BIBLIOGRAFIE - SELECTIVĂ

4 1. INTRODUCERE În contextul actual al dezvoltării grid şi cloud computing cercetarea ştiinţifică se bazează pe partajarea datelor şi a resurselor distribuite între domenii administrative separate de distanţe geografice considerabile. De aceea, capacitatea de a transfera cantitaţi mari de date în reţele de tip WAN este o cerinţa importantă pentru aplicaţii de tip HPC. De exemplu, experimentul Atlas [1] transferă 10 PB de date anual. Cercetarea de la Virgo [2] stocheaza sute de TB de date anual, transferate in reţele cu latenţa scăzută. În alte domenii ştiinţifice, ca de pildă vizualizarea in timp real a datelor instrumentate de la distantă sau realizarea de transmisii video sau videoconferinţe de definiţie foarte înaltă, reţele optice de cercetare (e.g. GLIF [3] sau OptIPuter [4]) sunt folosite pentru transferuri în flux de date cu viteză superioară. TCP [5] este protocolul cel mai folosit în Internet deoarece asigură un serviciu important şi anume transferul garantat al datelor sub formă de fluxuri continui de octeţi. TCP nu impune restricţii de implementare, aşa încît funcţionează atît in reţele obişnuite (Ethernet) cît şi avînd HBDP şi BER mari. Succesul TCP se datorează algoritmilor săi de control al congestiei în reţea. Aceştia controlează faza iniţială a transmisiei, de slow-start, în care capacitatea reţelei este evaluată rapid prin dublarea ferestrei de congestie (cwnd) la fiecare RTT, cît şi faza următoare, de creştere liniară a cwnd cu cîte un pachet la fiecare RTT. Conform studiilor din [6], performanţa TCP este invers proporţională cu RTT şi dependentă într-o măsură foarte mare de rata de pierdere a pachetelor, ceea ce face dificilă utilizarea întregii laţimi de banda disponibile în reţele moderne (e.g. cu tehnologie bazată pe fibră optică). Optimizarea transferurilor unor volume de date foarte mari în scopul atingerii unei eficienţe mărite a condus la crearea de noi variaţii ale TCP (e.g. SACK [7], Vegas [8], HighSpeed [9], FAST [10], MulTCP [11], MPTCP [12]) care adresează unele dintre limitările sale iniţiale, cauzate de algoritmul său de evitare a congestiei in reţea. Controlul congestiei la nivelul infrastructurii de reţea a condus la elaborarea unor algoritmi care să asigure managementul activ al cozilor din rutere (e.g. RED [13], BLUE [14], SFB [15]) în sensul înlocuirii simplei abandonări a pachetelor (drop-tail) cu marcarea acestora în mod probabilistic înainte ca să fie depaşită capacitatea maximă a cozilor. Dintre protocoalele de transport non-tcp, XCP [16] necesită modificări ale ruterelor din reţea, iar alte protocoale, precum SCTP [17] sau DCCP [18] au fost dezvoltate pentru uzul aplicaţiilor pentru care transmisia garantată a TCP nu este neapărat necesară (e.g. telefonie mobilă, multimedia, jocuri video interactive). La nivel de aplicaţie există numeroase soluţii de îmbunătaţire a performanţelor transferurilor în reţea. Dintre acestea, unele folosesc UDP pentru transferul propriu-zis al datelor şi TCP pentru canalul de control (e.g. RBUDP [19], SABUL [20]). Altele se bazează pe implementarea paralelismului la nivel de reţea prin folosirea de conexiuni TCP multiple în acelaşi timp (e.g. XFTP [21], Psockets [22], GridFTP [23]). O altă tehnică (split-tcp, în [24]) este aceea a împărţirii unei conexiuni TCP în două sau mai multe segmente în serie, fiecare optimizînd local parametrul RTT, dat fiind faptul că fluxurile TCP cu RTT mare sunt dezavantajate în competiţia contra conexiunilor cu RTT mic [25] MOTIVAREA CERCETĂRII Aşa cum rezultă din studiul prezentat în capitolul 2, soluţiile de transfer existente prezintă atît avantaje cît şi un număr de limitări intrinsece. 4

5 Schimbările aduse protocolului TCP au de obicei o durată de standardizare îndelungată. În cazul TCP Sack au trecut opt ani între momentul cînd a fost propus pentru prima dată şi adoptarea în forma sa definitivă. MPTCP este dezvoltat în continuare încă din anul 2009 sub forma unei implementări în nucleul sistemului de operare Linux. Astfel de abordări, pe lîngă durata mare de definitivare, au evidente dificultăţi de diseminare în reţea pentru că necesită actualizări ale sistemului de operare. Coabitarea diverselor variante îmbunătaţite ale TCP cu TCP clasic este şi ea uneori problematică. De exemplu, TCP Vegas, din cauză că are o abordare conservativă în utilizarea resurselor comune din reţea [26], este mai rar folosit în Internet. Alte soluţii, precum HighSpeed TCP sau FAST TCP, din cauza agresivităţii în reţelele HBDP, produc o partajare neechitabilă a resurselor necesare aplicaţiilor care folosesc conexiuni TCP (paralele) în medii grid pentru transferul unor seturi de date mari. Protocoalele de tip non-tcp precum XCP necesită modificări ale felului în care congestia din reţea este suportată la nivel de rutere intermediare şi schimbări de protocol atît la nivel de transmiţător cît şi de receptor. Asemenea cerinţe sunt dificil de implementat şi costisitoare, constituind un obstacol pentru diseminare, cu excepţia reţelelor ştiinţifice dedicate sau capabile de QoS. Alte protocoale noi, ca SCTP şi DCCP, necesită aplicaţii noi sau cel puţin rescrise pentru a fi utilizate. În plus, maşinile intermediare din reţea (e.g. NAT) au dificultăţi de acceptare a protocoalelor noi care pot fi astfel blocate. Cu toate că au o şansă mai bună de diseminare, bibliotecile de funcţii de reţea trebuiesc să fie incluse în noi aplicaţii, iar aplicaţiile de reţea deja existente sunt uneori prea specializate şi de obicei orientate doar către transferul de fişiere de dimensiuni cunoscute. Existenţa limitărilor menţionate mai sus a motivat cercetarea din această dizertaţie cu scopul de a se prezenta o abordare care să aducă o serie de avantaje principale, şi anume: O arhitectură flexibilă: o capabilă de transferul rapid, în paralel, al datelor în modul streaming la nivel de octet. o care extinde paradigma programării cu pipes în reţea ce interconectează la distanţă procese de tip producător /consumator de date. Decuplarea algoritmilor de transfer rapid de detaliile de acces la date, care să permită atît transferul fişierelor obişnuite cît şi al datelor de dimensiuni nedeterminate. Reutilizarea aplicaţiilor de acces la sisteme de stocare specializate sau a comenzilor de sistem locale, eliminîndu-se dependenţa de aplicaţii de transfer monolitice. Suport pentru multi-path şi split-tcp la nivel de aplicaţie. Uşurinţă a diseminării - prin implementare sub forma unei aplicaţii de reţea de tip clientserver complete, gata de utilizat în producţia în medii grid. Conform tezei mele: 1.2. OBIECTIVELE CERCETĂRII Este posibil şi recomandabil a se realiza o implementare a paradigmei de programare cu pipes extinsă de la nivelul local al sistemului de operare la nivel de Internet, asigurîndu-se totodată transferul rapid, în paralel, al datelor în reţea. Obiectivele cercetării care vor valida această teză sunt cuprinse în următorii paşi: Realizarea unui studiu comparativ al principalelor tehnici şi aplicaţii de transfer a datelor în retea care reflectă stadiul actual al cunoaşterii în domeniu (cuprins în capitolul 2). Acesta motivează interesul existent pentru transferul rapid al datelor prin prezentarea unui studiu de caz (proiectul Atlas) în contextul dezvoltării continui a mediilor grid. 5

6 La nivelul de transport al protocoalelor de reţea se prezintă protocolul TCP, deoarece este cel mai folosit la transmiterea sigură a datelor în reţele variate, împreună cu performanţele sale determinate de algoritmii săi de control al congestiei, precum şi metoda de mărire a ratei sale de transfer globale prin folosirea de conexiuni multiple în paralel. Interesul pentru TCP justifică includerea analizei unei serii de variante ale sale care vizează îmbunătăţirea algoritmilor de congestie. Controlul congestiei în reţea este studiat şi la nivelul ruterelor prin includerea de algoritmi de management activ al cozilor din rutere. O altă clasă de protocoale de transport non-tcp este de asemenea studiată, acestea răspunzînd mai bine nevoilor unor aplicaţii specifice (e.g. VoIP, multimedia, jocuri video). Grupul larg al aplicaţiilor şi bibliotecilor de funcţii de transfer în reţea al fişierelor este de asemenea prezentat. Crearea unei arhitecturi care să suporte un sistem de prelucrare paralelă a datelor de transferat în reţea, bazat pe modelul teoretic al cozilor sincronizate de tip fork-join, combinat cu utilizarea interfeţei de comunicare interprocesuale de tip pipe de la nivelul local al sistemului de operare (descrisă in capitolul 3). Această arhitectură implementează conceptul general de pipes extinse cu o transmisie rapidă bazată pe multiple conexiuni TCP simultane în reţea. Problema transmisiei în flux continuu (streaming) sincronizat este rezolvată prin folosirea memoriei partajate între un proces (părinte) de control şi multiple procese (fii), cîte unul per conexiune, ce asigură paralelismul în reţea. Arhitectura adoptată realizează separarea între detaliile accesului la date (de exemplu, memorate pe sisteme de stocare specializate) şi algoritmii de transfer eficient a datelor în reţea, asigurîndu-se astfel un control centralizat al ratei de transmisie. De asemenea, o serie de caracteristici, importante pentru modelul de tip client-server de acces la date, sunt suportate, referitoare, între altele, la aspecte legate de autentificarea utilizatorilor, securitatea controlului şi opţional cifrarea datelor, traversarea cu uşurinţă a maşinilor intermediare de tip firewall sau NAT. Conceperea unor algoritmi eficienţi de transmisie paralelă prin streaming la nivel de octet (prezentaţi în capitolul 4). Eficienţa se referă la eliminarea completă a reordonărilor la recepţie şi la o soluţie de alocare statică a memoriei (partajate) folosită la alocarea zonelor tampon de transmisie în reţea. De asemenea, graţie controlului centralizat al transmisiei, este posibil şi suportul la nivel de aplicaţie pentru multi-path, important pentru maşinile cu adrese multiple de IP, multihomed, interconectate pe căi multiple în reţea (e.g. aflate în centre de calcul moderne cu redundanţă de reţea sau smartphones). Astfel, a fost proiectat un algoritm de transmisie cu ponderare capabil să optimizeze rata de transfer globală atît în condiţii statice cît şi dinamice de trafic, de debit inegal per conexiune TCP, conceput ca un sistem automat de control proporţional şi integral (PI). Elaborarea unei metodologii de validare experimentală a flexibilităţii arhitecturii adoptate şi a eficienţei şi consistenţei algoritmilor de transfer în reţele cu rată de transmisie de până la 8 Gbps (conţinută în capitolul 5). Aceasta se bazează pe folosirea unei aplicaţii client-server complete, ce implementează arhitectura şi algoritmii corespunzători. Analiza rezultatelor experimentale demonstrează că transferul prin streaming este la fel de rapid ca transferul de tip file striping, permiţîndu-se efectuarea cu simplitate a unei varietaţi de operaţii de transmisie altfel dificil de paralelizat la nivel de reţea, de exemplu sincronizări de directoare (cu tar), transferuri de regiuni de fişiere sau reluarea transferurilor din punctul de întrerupere (cu dd), transferuri de tip split-tcp, etc, indiferent daca dimensiunea datelor de transmis este cunoscută aprioric sau nu. Corectitudinea algoritmului ponderat a fost de asemenea evaluată în raport de abilitatea sa de a utiliza lăţimea de banda disponibilă a transmisiei pe căi paralele, în mod cumulativ. Prezentarea concluziilor tezei (în capitolul 6). Se concluzionează asupra contribuţiilor acestei teze şi se sugerează direcţii de cercetare viitoare în domeniul transferului de date în reţea. 6

7 2. STUDIU COMPARATIV AL TEHNICILOR ŞI APLICAŢIILOR DE TRANSFER DE DATE ÎN REŢEA 2.1. TRANSFERURILE DE DATE ŞI MEDIUL GRID Mediile grid sunt importante în contextul realizării de transferuri de date pe scară largă. Definit în general ca un sistem distribuit de elemente de calcul (CE) şi elemente de stocare a datelor (SE) conectate de o reţea de viteză mare, conceptul de grid provine din extinderea în mod natural a grupurilor (cluster) de calculatoare existente la începutul anilor '90 (e.g. SHIFT de la CERN) în ideea de a avea cluster-e conectate via Internet. Arhitectura grid a fost definită pentru prima oară în [27] în anul 1998, unde accesul la o vastă putere de calcul este asemănat cu uşurinţa accesului la reţeaua electrică (power grid) sau la o reţea de telefonie. În practică, utilizatorii care rulează aplicaţii în grid interacţionează cu un software intermediar (middleware) care controlează accesul şi buna funcţionare a mediilor grid. Unul din primii furnizori de middleware a fost proiectul GLOBUS care distribuie un set complet de componenete (toolkit) GT4 [28]. Alte grupuri redistribuie acest middleware pentru a uşura operaţiile de instalare a noi locaţii grid (e.g. cu PACMAN [29]). Unul din proiectele cele mai reprezentative pentru fizica particulelor este Atlas. Atlas este un detector de particule general care face parte din LHC (Large Hadron Collider) de la CERN. În condiţii de funcţionare normală, detectorul produce date pe o scară foarte largă, de la 80 TB/s la frecvenţa de 40 Mhz (date primare) şi pînă la numai 400 MB/s la frecvenţa de 200 Hz, în urma mai multor filtrări succesive [30]. Împreună cu datele obţinute prin simulare Monte Carlo şi cele necesare calibrării detectorului, totalul datelor produse anual de Atlas este de ordinul ~10 PB. Achiziţionarea unui astfel de volum de date necesită un model ierarhic, structurat pe mai multe nivele (tiers), bazat pe grid, care să aducă împreună resursele instituţiilor participante (~175 în anul 2011), separate de distanţe geografice mari, dar interconectate cu reţele rapide. Verificarea modelului s-a făcut prin executarea mai multor teste (challenges) - dintre care Atlas DC1 este unul la care am contribuit personal [31] [32]. Problema managementului datelor este rezolvată la nivel de grid middleware cu ajutorul unor servicii de transfer generalizate care în particular folosesc aplicaţii performante pentru transmisia datelor la distantă (e.g. GridFTP, prezentat pe larg în secţiunea 2.6.3). Un astfel de serviciu este prezentat in secţiunea următoare Serviciul FTS FTS [33] (File Transfer Service) este un serviciu de transfer al datelor definit de arhitectura glite, actualmente parte a EMI [34] (European Middleware Initiative). Serviciul este responsabil de transferul seturilor de date între diversele centre, permiţînd controlul resurselor de reţea în scopul efectuării de transferuri de fişiere cu locaţie precizată la nivel fizic şi opţional de fişiere logice (LFN, Logical File Name) catalogabile. Din punct de vedere conceptual, FTS controlează un set de canale configurabile între nodurile din reţea. Fiecare canal este unidirecţional aşa încît este posibil ca instanţe diferite ale FTS să controleze fiecare dintre cele două sensuri ale unui canal. Arhitectura FTS este modulară avînd o serie de componente extensibile. Astfel, clienţii (aplicaţii care efectuează transferuri de date) accesează via protocolul SOAP un serviciu Web de tip Tomcat (compliant WSDL), putîndu-se construi clienţi diferiţi. Acesta interfaţează o bază de date (MySQL sau Oracle) care conţine schema FTS. Iar agenţii FTS efectuează transferurile de fişiere propriu-zise (via canalele FTS) în acord cu setările din baza de date. 7

8 In concluzie, din prezentarea de mai sus a mediilor grid din punct de vedere al complexităţii şi amplorii transferurilor de date necesare, rezultă aşadar importanţa adoptării unor mecanisme perfecţionate de transmisie care să permită transferarea cu eficienţă, într-un timp cît mai scurt, a datelor în reţea SISTEMUL PROTOCOALELOR DE COMUNICAŢIE ÎN REŢEA Protocoalele standardizează felul în care datele sunt reprezentate atunci cînd sunt transferate intre maşinile conectate la o reţea [35]. Ele adresează probleme complexe legate de erori hardware, congestie în reţea, pierdere ori întîrziere de pachete (termen folosit în sens larg, ca unitate primară de transfer în reţea), date corupte, date duplicate sau sosite într-o ordine aleatorie, etc. Din punct de vedere logic, protocoalele sunt implementate pe mai multe nivele suprapuse de software, fiecare tratînd probleme specifice. Comunicaţia la fiecare nivel de protocol se bazează pe principiul că obiectele transmise sunt identice cu acelea primite. În practică, tehnica folosită de protocoalele de comunicaţie se bazează pe multiplexare şi demultiplexare. Funcţionalitatea inclusă la fiecare nivel face obiectul unor modele standardizate. Astfel, modelul ISO/OSI [36] este format din 7 nivele (Physical Hardware, Data Link, Network, Transport, Session, Presentation, Application). Cercetarea în domeniul TCP/IP a condus la un al doilea model, mai simplu dar mai des folosit, conţinînd doar 4 nivele logice (plus nivelul hardware), şi anume: Aplicaţie, Transport, Internet şi Interfaţa de reţea. Între cele două modele există diferenţe conceptuale. Astfel, modelul ISO implementează detecţia erorilor de transmisie la fiecare nivel, în mod independent, în timp ce modelul TCP/IP asigură fiabilitatea de tip end-to-end, cu majoritatea verificărilor grupate într-un singur nivel, cel de transport Protocolul TCP TCP [5], [37] este protocolul care standardizează felul în care se realizează transmisia fiabilă a fluxurilor de date în Internet, fiind o parte constitutiva a modelului TCP/IP. TCP asigură o conexiune bidirecţională, permiţînd schimbul eficient de date indiferent de caracteristicile reţelelor de transport. Deoarece TCP este implementat de obicei la nivelul sistemului de operare, el poate fi folosit de orice aplicaţie printr-o interfaţă de acces uniformă. TCP divide datele în segmente (înglobate în datagrame IP) şi menţine o fereastră de transmisie specializată, la nivel de octet. Dimensiunea ferestrei variază în timp, funcţie de spaţiul disponibil la recepţie, informarea făcîndu-se prin segmentele de confirmare. În acest mod este controlat în mod eficient debitul transmisiei. Confirmările TCP sunt de tip cumulativ, în sensul că precizează următorul octet pe care receptorul se aşteaptă să-l primească. Această strategie nu ţine seama de ordinea, posibil aleatorie, a segmentelor primite şi poate conduce la o retransmisie ineficientă, fie excesivă, fie redusă la retransmisia simplă, ceea ce anulează avantajul ferestrei de transmisie. O posibilă corecţie este algoritmul de retransmisie rapidă, care declanşează retransmisia înainte de timeout a segmentului următor unuia pentru care s-au primit deja multiple confirmări (patru cel puţin). Mecanismele de transmisie precedente nu sunt suficiente deoarece nu se ţine cont de congestia în reţea, cauzată de maşini intermediare (gateways) ce nu pot face faţă traficului impus. De aceea TCP consideră că majoritatea pierderilor sunt datorate congestiei şi introduce un nou parametru şi anume fereastra de congestie (cwnd), independent de capacitatea existentă la recepţie, care limitează superior ferestra de transmisie admisibilă. Algoritmul AIMD înjumătăţeşte fereastra de congestie (pîna la unu) la pierderea unui 8

9 segment (pachet) şi în acelaşi timp măreşte exponenţial (dublează) timeout-ul segmentelor de transmis. La încheierea congestiei, ori la deschiderea unei noi conexiuni, pentru a se evita instabilitatea cauzată de mărirea prea rapidă a ratei de transmisie, se aplică algoritmul Slow- Start, aditiv, care setează fereastra de congestie la un segment şi apoi o măreşte cu cîte un segment pentru fiecare confirmare primită. Această creştere este limitată de parametrul ssthresh (valoare de prag, de obicei jumătate din valoarea iniţială), care odată atins marchează intrarea în faza de evitare a congestiei, în care incrementarea se face numai dacă toate segmentele din fereastră au fost deja confirmate Performanţele TCP Deşi capabil să se adapteze unui domeniu larg de tipuri de reţele, TCP atinge un debit de transfer maxim determinat de algoritmii săi de evitare a congestiei. Conform studiilor din [6] acesta (notat BW) este aproximat de ecuaţia: (2.1) unde p este rata de pierdere a pachetelor, iar C este o constantă dependentă de parametrii algoritmului TCP. Conform studiului din [38], influenţa termenilor din ecuaţia (2.1) este diferită. Astfel, MSS are valorile cele mai statice pentru o conexiune TCP dată, fiind calculabil în baza MTU (care reprezintă dimensiunea maximă a unui pachet transmisibil fără fragmentare pe parcurs). Valorile obişnuite ale MTU sunt egale cu 1500 octeţi, dar există şi cazuri de reţele Ethernet cu valori de pînă la 9000 octeţi (jumbo frame), ceea ce poate mări BW de pînă la 6 ori. RTT este mai dinamic decît MSS dar mai puţin variabil decît p, fiind limitat inferior de viteza de propagare a luminii şi putînd creşte din cauza prezenţei ruterelor intermediare sau din cauza efectelor produse de prelucrările specifice din cozile de aşteptare sau congestia din reţea. Rata de pierdere a pachetelor p are variabilitatea cea mai mare, avînd două cauze principale de producere: congestia normală din reţea şi un set complex de cauze aleatorii, independente de traficul din reţea, reprezentînd erori hardware şi software se pot produce la nivel de calculatoare sau la nivelul ruterelor din reţea. În afara erorilor mai sus mentionaţe, există o rată de eroare intrinsecă fiecărui mediu de transmisie BER, cu valori maxime admisibile standardizate de IEEE pentru fiecare tip de reţea. De exemplu, într-o reţea cu BW = 1 Gbps, MSS = 1500, RTT = 100 ms, C = 1.2 (TCP clasic), substituind în ecuaţia (2.1), rezultă un p de ordinul, ceea ce corespunde unui BER de ordinul, dificil de atins chiar şi pentru fibre optice. Rezultă deci că efectele produse de p din motive aleatorii, nedatorate congestiei, sunt în măsură să afecteze în mod negativ performanţele conexiunilor TCP individuale, ţinîndu-se cont de caracteristicile algoritmului AIMD care înjumătăţeşte cwnd şi deci micşorează rata de transfer atunci cînd pachetele sunt pierdute Performanţa conexiunilor TCP multiple O soluţie la problema descrisă mai sus o reprezintă folosirea mai multor conexiuni TCP simultane, soluţie adoptată de mai multe din aplicaţiile de transfer descrise în secţiunea nr În mod colectiv, N conexiuni în paralel se comportă asemănător unei conexiuni cu MSS de N ori mai mare, cel puţin în faza de slow-start. Aceasta rezultă din însumarea ecuaţiei (2.1) pentru fiecare din conexiunile i participante, cu. Considerînd parametrii MSS şi RTT aceiaşi pentru fiecare dintre conexiunile realizate între aceleaşi două calculatoare şi estimînd că în absenţa congestiei chiar şi rata de pierdere a pachetelor este 9

10 distribuită uniform între conexiuni (fenomen favorizat de metodele moderne de management al cozilor din rutere, exemplificate în secţiunea 2.5), deci, rata de transfer globală devine: (2.2) Alt mod de a interpreta ecuaţia (2.2) se referă la competiţia între conexiuni cu RTT mare, specifice reţelelor HBDP şi conexiunile locale cu RTT mic; simplificînd cu N atît la numărător cît şi la numitor, devine evident că ansamblul conexiunilor TCP paralele se comportă ca avînd un RTT de N ori mai mic. Segmente care nu sunt pierdute din cauza congestiei, dar care tot produc diminuarea ratei de transfer, deoarece semnalizează înjumătaţirea cwnd, nu afectează toate cele N conexiuni în acelaşi timp, aşa încît scăderea debitului este mai mică în cazul transmisiei paralele. Din experimentele efectuate în [38] mai rezultă că rata globală de transfer creşte liniar cu numărul de conexiuni TCP simultane, pînă cînd se atinge un regim de saturaţie, cînd reţeaua nu mai are capacitate disponibilă de transfer. Mărirea mai departe a numărului de conexiuni poate produce efecte nedorite, de diminuare a debitului total din cauza congestiei excesive DIVERSE IMPLEMENTĂRI ALE TCP Cercetarea în acest domeniu a vizat îmbunătăţirea mecanismelor de retransmisie şi de control a congestiei în TCP clasic, reprezentat în principal de TCP Tahoe (implementat de BSD 4.3 [39] în 1988) şi TCP Reno (care cuprinde în plus şi algoritmul Fast Recovery implementat de BSD 4.3 în anul 1990). Schimbările privesc de obicei pe transmiţătorul datelor, pentru a se păstra compatibilitatea cu TCP. Implementările sunt realizate în sistemul de operare şi de aceea prezintă dificultăţi de diseminare TCP Sack TCP SACK este descris în forma sa definitivă în RFC 2018 [7] din anul 1996, însă a fost propus pentru prima dată încă din anul 1988 în RFC 1072 [40]. Mecanismul de confirmări selective al SACK este o strategie care corectează comportamentul TCP în cazul pierderilor multiple de segmente de date. Din punct de vedere tehnic sunt folosite două opţiuni TCP noi, Sack-Permitted şi Sack propriu-zisă. Comportamentul TCP SACK în cazul congestiei este dezbatut în [41], rezultînd că sporeşte într-adevăr semnificativ performanţele transferului de date, în special în cazul reţelelor WAN foarte încărcate sau chiar şi în absenţa congestiei, în situaţia mai multor erori grupate TCP Vegas TCP Vegas [8] este o implementare alternativă a TCP care nu îi schimbă specificaţiile generale, avînd avantajul de a modifica numai modul în care datele sunt transmise (nu şi recepţia, ca în cazul TCP SACK). Comparativ cu TCP Reno, debitul transferurilor de date este mărit cu 37% pînă la 71%, iar retransmisia segmentelor pierdute este redusă cu o cincime şi chiar pînă la o jumătate. 10

11 TCP Vegas foloseşte trei tehnici distincte pentru a obţine rezultatele menţionate mai sus: un nou mecanism de efectuare a retransmisiilor mai devreme, la momentul oportun; un mecanism de detectare proactivă a congestiei; un mecanism Slow-Start modificat. Cu toate că TCP Vegas a demonstrat o viteză superioară şi stabilă, fără a afecta latenţa sau a concura inechitabil alte conexiuni, este mai rar folosit în Internet, tocmai din cauza abordării conservative în ceea ce priveşte utilizarea resurselor de reţea, aşa cum se arată şi în studiul comparativ [26] cu TCP Reno HighSpeed TCP HighSpeed TCP [9] este o modificare experimentală a mecanismului de control a congestiei al TCP pentru conexiuni cu fereastră de congestie mare. Obiectivul principal este obţinerea unui debit de transfer mărit în condiţiile în care rata de pierdere a pachetelor nu este excepţional de redusă. Tehnica folosită de HighSpeed TCP presupune modificarea formulei de calcul a cwnd funcţie de rata de pierdere a pachetelor ( ) aşa cum rezultă din algoritmul AIMD al TCP. Se folosesc trei parametri, Low_Window, High_Window şi High_P, precum şi Low_P care conduc la o formulă logaritmică, în cazul unui debit estimat de 10 Gbps, cu valori tabelate din motive practice. Din punct de vedere al performanţei, HighSpeed TCP este superior lui TCP Reno/Tahoe insă inferior lui TCP Vegas. Aşa cum se arată în [42], aceasta se datorează lipsei unei estimări corecte a debitului disponibil (folosită de Vegas), ceea ce produce mărirea sau micşorarea cwnd într-un mod arbitrar în cazul HighSpeed TCP Fast TCP FAST TCP [10] este o implementare actualmente comerciala a unui mecanism de congestie bazat pe estimarea întîrzierilor din cozile de aşteptare (din rutere) de pe parcursul unei conexiuni TCP. Se adresează reţelelor de tip HBDP cu latenţă ridicată şi are ca obiectiv atenuarea dificultaţilor pe care TCP le are la funcţionarea în reţele cu cwnd mare. Tehnica folosită de FAST TCP îmbină estimarea continuă a întîrzierilor din cozi cu detecţia pierderilor de pachete în vederea asigurării unui număr constant de pachete în cozile din reţea. Spre deosebire de TCP Vegas, care ajustează rata de transfer în paşi egali, FAST TCP realizează ajustări variabile ale ratei de transfer, mai mari, respectiv mai mici, proporţional cu distanţa faţă de situaţia de echilibru. Comparativ cu TCP Vegas, HighSpeed TCP şi TCP Reno, FAST TCP este superior în ceea ce priveşte debitul atins, concurenţa echitabilă, stabilitatea şi viteza de reacţie la schimbarea condiţiilor de trafic în reţea. Cu toate acestea şi FAST TCP este presupus a prezenta ca şi TCP Vegas aceleaşi probleme de coabitare în reţele în care TCP Reno este prevalent MPTCP MPTCP (Multipath TCP) este o extensie a TCP capabilă să folosească simultan trasee diferite în reţea pentru interconectarea calculatoarelor cu interfeţe de reţea multiple şi adrese de reţea (IP) diferite. La ora actuală (2013) este prezentat într-un document IETF [12] avansat, fiind dezvoltat încă din anul Tehnica folosită de MPTCP este transparentă pentru aplicaţiile de reţea deoarece este implementat sub forma unei noi biblioteci de sockets la nivelul sistemului de operare. Aşa cum se arată în [43] protocolul MPTCP este implementat cu ajutorul a noi opţiuni TCP în scopul asigurării traversării nestînjenite a unei diversităţi de maşini intermediare din reţea, de 11

12 tip NAT, PEP, firewall, IDS, etc. Transmisia datelor se poate face pe oricare dintre conexiunile participante, iar implementarea minimizează necesarul de memorie şi procesare prin aplicarea unor strategii de retransmisie oportunistică, de penalizare a căilor mai lente şi de autoconfigurare a mărimii buffer-elor de reţea. Performanţa MPTCP a fost studiată în laborator în medii wireless cu aplicaţii folosind protocolul HTTP, obţinîndu-se rezultate bune comparativ cu TCP Reno în [44] MulTCP MulTCP [11] reprezintă o modificare a algoritmului de control a congestiei care conduce la simularea unei colecţii de mai multe conexiuni virtuale TCP. Acest comportament este benefic şi în cazul reţelelor de tip HBDP. Tehnica folosită de MulTCP se bazează pe introducerea unui factor N în scopul obţinerii unui debit de transfer echivalent cu acela a N conexiuni simultane. Parametrizarea funcţie de N se aplică la toate fazele prin care trece o conexiune TCP, prin modificarea corespunzătoare a parametrilor cwnd si ssthresh. Performanţele atinse de MulTCP au fost estimate prin simulare şi rezultatele demonstrează echivalenţa sa cu N conexiuni paralele de tip TCP SACK MANAGEMENTUL ACTIV AL COZILOR DIN RUTERE (AQM) O altă metodă de a controla congestia din reţea este implicarea activă a ruterelor în controlul acesteia. În mod tradiţional, ruterele folosesc o politică de tip drop-tail în managementul cozilor de pachete asociate cu interfeţele de reţea deservite, în sensul că pachetele care depăşesc capacitatea existentă a cozilor sunt abandonate. În locul acestei politici se pot aplica scheme bazate pe marcarea sau abandonarea pachetelor în mod probabilistic, înainte de a se atige capacitatea maximă a cozilor. Marcarea pachetelor se face cu ajutorul unei extensii a protocolului IP (sau TCP), ECN, standardizată de RFC 3168 [45], în care un bit CE (Congestion Experienced) este actualizat în antetul pachetelor IP atunci cînd congestia iminentă este detectată de rutere Algoritmul RED Algoritmul RED [13] (Random Early Detection) aplică o politică de detecţie a congestiei incipiente prin notificarea mai devreme a surselor, ceea ce le permite să-şi reducă rata de transmisie înainte ca să fie depăşite cozile din reţea şi pachetele să fie pierdute. Tehnica folosită de RED se bazează pe păstrarea unei lungimi medii a cozii calculată dupa o formulă EWMA (Exponential Weighted Moving Average) ce este utilizată pentru detectarea congestiei. Algoritmul are ca obiective principale minimizarea pierderii pachetelor şi a întîrzierilor din rutere, evitarea sincronizării globale a surselor, menţinerea unui grad mare de utilizare a debitului disponibil şi evitarea dezavantajării surselor cu transmisie bruscă Algoritmul BLUE Algoritmul BLUE [14] foloseşte o schemă de management automatizată, care nu necesită parametri de reglaj şi care funcţionează mai bine decit RED chiar şi cu tampoane mai mici. Tehnica BLUE se bazează în mod direct pe pierderea pachetelor şi pe gradul de utilizare al reţelei, spre deosebire de schemele bazate pe gradul de ocupare al cozilor din 12

13 rutere. Algoritmul BLUE păstrează o unică probabilitate,, utilizată pentru marcarea (sau abandonarea) pachetelor. Algoritmul BLUE a fost comparat prin simulare cu RED (în [14]) obţinîndu-se performanţe superioare sau cel puţin egale sub toate aspectele Algoritmul SFB Algoritmul SFB [15] (Stochastic Fair BLUE) reprezintă o variantă îmbunătăţită a algoritmului BLUE prin adăugarea unui filtru Bloom [46] care permite controlul echităţii utilizării reţelei de către fluxurile individuale folosindu-se resurse de stare puţine şi zone tampon minime. Filtrul Bloom este utilizat la contabilizarea distribuţiei pachetelor la N x L containere (bins) cu ajutorul a L functii hash aplicate antetelor IP ale acestora. Ca urmare, un flux care ignoră starea congestiei din reţea produce convergenţa rapidă a la valoarea 1 pentru toate cele L containere unde a fost distribuit, în timp ce o conexiune TCP are şansa de a fi distribuită şi în alte containere cu probabilitate mai mică decit PROTOCOALE NON-TCP Protocoalele non-tcp îşi aduc o contribuţie pozitivă la rezolvarea problemelor legate de îmbunătăţirea răspunsului TCP la congestie sau la rezolvarea unor probleme specifice nivelului de transport din reţea. În general însă, prezintă şi ele dificultăţi de diseminare, aşa cum se va vedea în continuare XCP XCP [16] (explicit Control Protocol) este un protocol nou care controlează congestia mai bine decît protocolul TCP şi asigură eficienţa, echitatea şi stabilitatea transmisiei în reţele HBDP. Acest protocol introduce şi un concept nou, acela al separării controlului eficienţei de cel al echităţii transmisiei. Noul protocol generalizează bitul ECN de la nivelul ruterelor prin includerea unui antet de congestie în fiecare pachet transmis în reţea. Ruterele calculează eficienţa în baza unei formule MIMD cu (doi) parametri invarianţi la numărul şi debitul relativ al fluxurilor participante, determinaţi pe criterii de asigurare a stabilităţii. Controlul echităţii este bazat pe un algoritm AIMD, cu excesul de debit disponibil împărţit egal între fluxuri, iar scăderea debitului fiecărui flux este proporţională cu debitul său curent; în plus se asigură convergenţa rapidă prin tehnica de realocare/amestecare a debitului între fluxuri. Comparativ cu TCP, XCP este stabil şi eficient independent de debit, RTT şi numărul de fluxuri. Rezultatele simulării demonstrează că XCP este mai performat decît TCP atît în reţele normale cît şi mai ales HBDP. XCP are şanse de răspîndire doar în reţele dedicate cercetării ştiinţifice şi mai puţin în Internet în general şi aceasta din cauza costurilor de implementare prohibitive SCTP SCTP [17] (Stream Control Transmission Protocol) este un protocol definit pentru prima oară în RFC 2960 [47] în anul 2000 şi definitivat în anul 2007 prin RFC 4960 [48]. El a fost dezvoltat iniţial cu scopul de a se permite funcţionarea protocoalelor de telecomunicaţie, în special pentru aplicaţii VoIP, de transfer a vocii în reţele IP. Îmbină caracteristici ale UDP, în sensul că este orientat spre transmisia de mesaje (chunks), dar se aseamănă şi cu TCP prin aceea că transmisia mesajelor este garantată. 13

14 Comparativ cu TCP, SCTP foloseşte un algoritm de retransmisie bazat pe confirmări selective, asemănător lui TCP SACK, iar mecanismele sale de mărire a cwnd în funcţie de numărul de octeţi recepţionaţi (nu funcţie de numărul de confirmări, precum la TCP) îi îmbunătăţesc precizia controlului congestiei [49]. În experimentele iniţiale SCTP a demonstrat o bună coabitare cu traficul TCP fără a se inregistra degradări ale performanţelor din cauza noului protocol. În [50] sunt evaluate prin simulare strategii de retransmisie ale SCTP-CMT [51], concluzionîndu-se că este important să se ţină seama de rata de pierdere a mesajelor în alegerea căii optime pentru retransmisie. Cu toate acestea şi protocolul SCTP are probleme de diseminare din cauză că necesită aplicaţii noi sau cel puţin rescrise care să-l poată folosi şi fiindcă traficul SCTP poate fi blocat de maşini intermediare de tip NAT DCCP DCCP [18] (Datagram Congestion Control Protocol) este un protocol nou la nivelul de transport al reţelei, de tip unicast, care asigură controlul congestiei dar fără o transmisie garantată a datelor. A fost proiectat pentru a răspunde mai bine nevoilor unor clase de aplicaţii specifice, de exemplu de telefonie pe Internet, de transmisie multimedia sau jocuri video interactive. Pentru acestea retransmisiile de tip TCP sunt în majoritatea cazurilor inadecvate, utilizatorii preferînd o transmisie la timp uneia complete. DCCP este construit pe baza protocolului UDP căruia îi adaugă o serie de trăsături similare cu TCP: un sistem de numerotare secvenţială a mesajelor; un mecanism de control al conexiunilor, bazat pe conceptul de semi-conexiune; mecanisme de control a congestiei, modularizate (e.g. CCID 2 [52], agresiv şi CCID 3 [53], adaptiv). Performanţele DCCP au fost studiate în [54] prin compararea cu UDP şi TCP în cazul unei aplicaţii CBR (Constant Bit Rate), rezultînd că DCCP combină o rată de pierdere a pachetelor redusă cu o rată bună de transmitere a pachetelor importante. În raport cu SCTP, DCCP este presupus a obţine rezultate mai bune deoarece nu este afectat de apariţia de întîrzieri arbitrare ce pot fi cauzate de transmisia garantată a SCTP APLICAŢII DE TRANSFER RAPID La nivelul aplicaţiilor de reţea există o multitudine de soluţii, bazate pe tehnici de folosire a conexiunilor TCP în paralel, pe UDP pentru transferul datelor sau pe tehnici de împărţire în mai multe porţiuni succesive a unei conexiuni TCP pe criterii de îmbunătăţire a ratei de transfer globale. Diseminarea acestora este facilă deoarece avem de-a face cu software situat în afara sistemului de operare, aspect care a stat şi la baza abordării din această teză XFTP XFTP [21] este o aplicaţie de tip client-server care extinde protocolul FTP descris în RFC 959 [55] cu o implementare multisocket. Extensia de protocol se referă numai la modul activ al FTP (comenzile MULT şi MPRT) si este implementată prin folosirea a n conexiuni simultane, multiplexate asincron, cu zone tampon pentru evitarea blocajelor, într-un singur proces. Fişierele transferate sunt împărţite în m părţi egale (de cîte 8K, cu ), fiecare fiind transmisă împreună cu numărul său de ordine printr-una din conexiunile disponibile şi apoi reordonată la sosire. În ciuda inconvenientelor legate de folosirea unui grad mai redus de paralelism (un singur proces) şi a necesităţii de a se efectua reordonări la recepţie, XFTP a reuşit să obţină o 14

15 utilizare de 90% a capacităţii unei linii T1 (via satelit, cu o viteză de pînă la Mbps), faţă de numai 24% în cazul FTP Psockets PSockets [22] este o bibliotecă de funcţii scrisă în C++ care ajută aplicaţiile să obţină o utilizare optimală a reţelei fără a trebui să ajusteze fereastra de transmisie, descrisă de RFC 1323 [56]. Tehnica folosită se bazează pe împărţirea egală a datelor într-un număr de părţi determinat de numărul de conexiuni deschise simultan şi transmiterea acestora în mod asincron, în paralel. Biblioteca Psockets ascunde detaliile legate de numărul de sockets efectiv întrebuinţaţi şi felul în care datele sunt segmentate şi apoi reconstituite la recepţie. În acest fel se elimină inconvenientul reordonării la recepţie, existent în cazul metodei folosite de XFTP. De notat că ideea unei transmisii fără reordonare a fost adoptată de asemenea în prezenta teză. PSockets este uşor de folosit de către aplicaţiile interesate în obţinerea unor debite de transfer cît mai mari deoarece oferă funcţii cu o interfaţă (API) identică (e.g. send, receive) cu aceea a bibliotecii de reţea obişnuite (Berkeley sockets [39]) Globus GridFTP Globus GridFTP [23] este o aplicaţie client-server pentru transferul de fişiere proiectată special pentru mediile Grid, făcînd parte din GT4. Ea răspunde principalei cerinţe de asigurare a transferului unor seturi de date masive, sub formă de fişiere, între servere aflate într-o reţea WAN ce acoperă distanţe geografice considerabile. Protocolul GridFTP [57] este bazat pe FTP şi extensiile sale standardizate de IETF, pe RFC 2228 [58] pentru securitate şi RFC 2389 [59] pentru negociere, la care se adaugă o serie de comenzi noi şi opţiuni aferente. Ca urmare, protocolul GridFTP are capabilităţi extinse: transfer simultan între mai multe servere, folosirea de conexiuni în paralel, transfere parţiale de fişiere (regiuni), negociere automată a parametrilor de transfer (fereastră, tampon) şi repornirea şi recuperarea transferurilor întrerupte de erori fatale de reţea. Arhitectura GridFTP este modularizată, fiind compusă din module independente: interpretorul de protocol (PI) de la nivelul serverului şi cel de client; procesul de transfer de date DTP, format din trei module succesive, de acces la date, de procesare a datelor şi de scriere/citire a datelor în reţea. Comparativ cu alte servere FTP, GridFTP obţine performanţe bune atît în privinţa vitezei de transfer cît şi a scalabilităţii în cazul servirii mai multor clienţi cvasi simultan RBUDP RBUDP [19] (Reliable Blast UDP) este o aplicaţie de transfer a datelor în reţele de mare capacitate, dedicate sau capabile de QoS (e.g. reţele optice). Transferul datelor propriuzise se face cu UDP, iar traficul de control este semnalizat cu TCP. Astfel, într-o primă fază, datele de transferat sunt transmise cu datagrame UDP şi o viteză specificată de utilizator, aleasă aşa încît să nu depăşească capacitatea maximă a reţelei. Receptorul păstrează evidenţa pachetelor pierdute (sub formă de hartă de biţi, bitmap) pe care apoi o comunică, via TCP, transmiţătorului. Acesta retransmite numai pachetele UDP pierdute şi întreg procesul se repetă pînă la eliminarea tuturor pierderilor. Se observă aşadar că RBUDP nu foloseşte mecanisme de control a congestiei şi nici vreun algoritm de tip slowstart precum TCP. Totodată acesta grupează toate confirmările la încheierea secvenţei de transmisie UDP, eliminîndu-se astfel confirmările de pe parcurs, consumatoare de timp. 15

16 Rezultatele experimentale demonstrează că RBUDP poate transfera cantităţi mari de date cu viteză apropiată de capacitatea maximă de transmisie a reţelei SABUL SABUL [20] (Simple Available Bandwidth Utilization Library) este o bibliotecă C++ disponibilă în sursă, cu funcţii de reţea pentru aplicaţii de transfer performante, în medii Grid. Datele sunt transferate via UDP, iar controlul transmisiei se face via TCP. SABUL implementează un algoritm de control a congestiei, funcţie de rata de transfer şi un mecanism de transmisie sigură a datelor. Tehnica folosită de SABUL se bazează pe un algoritm de tip AIMD de control al ratei de transfer prin recalcularea, o dată la fiecare 10 ms, a intervalului de timp între două transmisii consecutive de pachete de date. În plus, rata de transfer este limitată de o fereastră virtuală de transmisie, a cărei valoare maximă trebuie să fie setată de către aplicaţie. Comparativ cu RBUDP, SABUL obţine rezultate performante nu numai în reţele private ci şi în cele publice, deoarece nu limitează în mod drastic capacitatea traficului TCP de a folosi reţeaua în mod normal. Rezultatele obţinute prin simulare şi experimente în reţele reale arată că SABUL este echitabil în raport cu alte fluxuri coexistente, în sensul atingerii unor viteze egale de transfer, indiferent de viteza iniţială a fiecăruia GridFTP Overlay În [24] se prezintă un număr de componente care îmbunătăţesc capacitatea de transfer a GridFTP prin folosirea de multiple conexiuni în serie, segmentate (de tip split-tcp), în locul unei singure conexiuni directe. Arhitectura acestui sistem include mai multe servere de tip GT4. Astfel, un modul Split-DSI îndeplineşte funcţia de releu de transmisie la nivelul unui server intermediar GridFTP. Un serviciu BTC raportează debitele de transfer, înregistrate în cursul transferurilor GridFTP obişnuite, către serviciul MDS4 [60]. În final, serviciul Split-Choice sugerează unui client servere intermediare GridFTP prin adăugarea acestora la URL-ul iniţial al transferului. În acest mod conectarea se face mai întîi la un server intermediar, implementîndu-se efectiv conexiuni de tip split-tcp. Rezultatele experimentale au arătat imbunătăţiri ale debitului global de transfer de pînă la 500%, cu o medie de 125%, comparativ cu transferurile GridFTP directe SUMAR Acest capitol a făcut o prezentare cuprinzătoare a rezultatelor cercetării în domeniul transferului de date în reţea, desigur fără a se putea prezenta totalitatea acestora, din cauza volumului imens existent. În tabela 2.1 se prezintă modelul bazat pe mecanismul de pipelines rapide, alături de tehnicile şi aplicaţiile prezentate mai sus, în raport cu principalele criterii de comparaţie care au stat la baza alegerii soluţiei adoptate. Din punct de vedere al capacităţii de a folosi în mod eficient căi multiple în reţea, avînd eventual şi capacitate de transfer diferită, aplicaţia proiectată, bazată pe pipelines extinse, se aseamănă cu MPTCP, care însă fiind implementat la nivelul sistemului de operare (Linux), suferă, asemeni majorităţii extensiilor aduse protocolului TCP, dificultăţi de diseminare şi standardizare. Comparativ cu grupul de aplicaţii sau biblioteci de funcţii de transfer în reţea, care folosesc conexiuni TCP multiple în paralel, grup din care face parte, soluţia concepută este 16

17 orientată către transferul în flux continuu de date (streaming) şi ca urmare nu este limitată la transferul fişierelor de dimensiuni determinate. Tabela 2.1. Comparaţie sinoptică între metodele de transfer în reţea Uşurinţa diseminării Reutilizare aplicaţii/comenzi Suport pentru Multi-Path Suport pentru Split-TCP Transfer în flux de date TCP Sack DA (opţiune) NU NU - - TCP Vegas NU (kernel) NU NU - - HighSpeed TCP NU (kernel) NU NU - - Fast TCP NU (comercial) NU NU - - MPTCP NU (kernel) NU DA - - MulTCP NU NU NU - - XCP NU (rutere) NU NU - - SCTP NU(rescriere NU DA - - aplicaţii) DCCP NU(aplicaţii noi) NU NU - NU(doar mesaje) XFTP DA NU NU NU NU Psockets DA (bibliotecă) - NU NU - Globus GridFTP DA (grid) NU NU NU NU RBUDP NU NU NU NU - (QoS/dedicate) SABUL DA (bibliotecă) - NU NU - GridFTP Overlay DA NU NU DA NU Pipelines extinse DA (client/server) DA DA DA DA 3. ARHITECTURA SISTEMULUI DE TRANSFER DE DATE 3.1. ARHITECTURĂ În figura 3.1 se prezintă arhitectura sistemului de streaming în paralel, cu o structură simetrică, specifică modelului client-server de transfer în reţea. Atît la nivel de client cît şi de server sunt prezente următoarele componente: un proces părinte specializat în citirea, respectiv scrierea dintr-un pipe prin care se accesează exclusiv input-ul sau output-ul proceselor externe producătoare sau consumatoare de date. un număr de N procese fii, specializate în scrierea, respectiv citirea datelor din reţea sub formă de conexiuni TCP, cîte una per proces. un segment de memorie partajată între procese, care asigură sincronizarea, tratarea şi raportarea erorilor şi care conţine şi toate zonele tampon pentru transferul datelor între pipe şi reţea; de asemenea, conţine şi structuri de date care servesc la raportarea timpilor de 17

18 transmisie per proces. Fig Arhitectura sistemului de streaming în paralel Procesul părinte implementează algoritmii principali de control al transmisiei de date, prin ponderarea numărului de octeţi alocaţi pentru scriere fiecărui proces fiu, în funcţie de viteza sa de transmisie curentă. Procesele fii calculează şi raportează lăţimea de bandă a transmisiei de care sunt capabili sub forma timpului, exprimat în microsecunde, necesar golirii zonei tampon alocate. Un model orientat spre transferul de fişiere, în care un număr de procese simultane independente accesează atît reţeaua cît şi direct fişierul de transmis (file striping), este comparabil cu arhitectura de tip streaming în paralel, rezultînd superioritatea celei din urmă, pentru următoarele considerente: interfaţa cu sistemul de operare este de tip pipeline, ceea ce conferă generalitate în privinţa selecţiei sursei sau a destinaţiei transferului de date. Astfel, oricare procese producătoare sau consumatoare de date pot fi interconectate cu rapiditate şi la distanţă, indiferent dacă sunt comenzi de sistem sau aplicaţii specializate în accesul la sistemul local de stocare a datelor sau aplicaţii HPC care generează date în cantităţi neprecizate; modelul bazat pe striping este limitat la accesul fişierelor de dimensiuni cunoscute. există o separare completă între accesul la date şi algoritmii de transmisie a acestora cu viteza în reţea, algoritmii fiind încapsulaţi într-o aplicaţie de transfer performantă. Aceasta reprezintă un avantaj deoarece aceeaşi aplicaţie eficientă poate fi folosită la transferul datelor în reţea indiferent de complexitatea detaliilor de acces la date, în vreme ce aplicaţiile bazate pe striping devin monolitice şi necesită înglobarea cunoştinţelor necesare accesului nemijlocit la fişierele de transmis aflate eventual în sisteme de stocare nestandard (e.g. sisteme de memorare pe bandă magnetică care presupun operaţii pregătitoare pentru acces). controlul transmisiei de date este centralizat şi permite întrebuinţarea eficace a căilor multiple în reţea sau/şi de capacitate diferită (multi-path), la nivel de aplicaţie, prin adaptarea dinamică la variaţiile ratelor de transfer individuale. Desigur că aceasta nu este posibil pentru modelul bazat pe striping deoarece acolo procesele de transmisie în reţea sunt necorelate. Arhitectura adoptată realizează de asemenea o combinare efectivă între modul de comunicaţie bazat pe pipes şi transmisia paralelă a datelor în reţea ceea ce îi conferă avantajele ambelor metode: reutilizare, eleganţă (prin adoptarea paradigmei de programare cu pipes sub sistemul de operare Unix) şi rapiditate a transmisiei în reţea (cu multiple conexiuni TCP simultane). 18

19 3.2. CAPABILITĂŢI CLIENT-SERVER SUPLIMENTARE Avînd în vedere faptul că algoritmii de transfer consideraţi sunt incluşi într-o aplicaţie cu arhitectură client-server, o serie de aspecte specifice au fost luate în considerare, cu scopul de a se crea o aplicaţie robustă care să răspundă cerinţelor moderne de transfer a datelor în reţea. Aceasta a servit, pe de o parte, aplicării unei metodologii experimentale realiste, iar pe de altă parte a răspuns şi cerinţelor concrete ale primilor utilizatori ai acestui sistem de transfer în medii grid. Astfel: Protocolul de control al transferului este de tip binar. De asemenea, este şi criptat RSA ceea ce ii conferă un grad mare de securitate. Autentificarea corectă a utilizatorilor a fost extinsă cu un modul similar celui folosit de ssh, care foloseşte aceleaşi chei publice şi private, în vederea autentificării fără introducerea de parole, ceea ce simplifică exploatarea în regim de loturi de prelucrare, fără intervenţie umană. Autentificarea în medii grid este de asemenea posibilă atunci cînd serverul este iniţiat de către client la distanţă, cu o versiune a ssh capabilă de autentificare GSI (GSI- OpenSSH [61]) sau prin utilizarea unei versiuni compilate cu un modul GSI opţional. Sub aspectul securităţii este de menţionat şi faptul că datele transferate pot fi la rîndul lor cifrate, în mod opţional, prin codificare RC4. Traversarea facilă a reţelelor protejate de firewalls sau maşini NAT se poate face prin conectarea tuturor conexiunilor TCP paralele de date la un singur port, aflat în regim de ascultare. Numărul de port al destinaţiei poate fi acelaşi cu numărul portului de control al serverului. Aceasta se realizează prin comunicarea între procese cu semnale care produc suspendarea temporară a regimului de ascultare a serverului principal. Reordonarea corectă a conexiunilor acceptate, independent de IP-ul (posibil local) ori portul sursă se face printr-un schimb cifrat de mesaje. Parcurgerea comenzilor şi a opţiunilor din linia de comandă a clientului se face cu un mini-interpretor. Dintre comenzile acceptate, comanda pipe avînd ca argument aplicaţia de executat la distanţă (de către server) asigură şi suportul pentru conexiuni de tip split-tcp. De asemenea, interpretorul poate efectua şi selecţii cu expresii regulate ale mai multor fişiere sau/şi subdirectoare şi poate executa în mod recursiv (şi chiar şi cu opţiunea de excludere a fişierelor deja transferate) transmisia fisierelor dorite în modul file striping, în mod optimizat (simultan). Transferul în flux continuu (streaming la nivel de octet), efectuat totodată cu o rată a transmisiei maximizată, permite reutilizarea comenzilor Unix cu execuţie la distanţă prin includerea în mod natural în script-uri de sistem. De exemplu, comanda dd poate fi folosită pentru reluarea unui transfer întrerupt. Comanda tar poate fi folosită la sincronizarea rapidă a subdirectoarelor la distanţă MODELUL COZILOR DE TIP FORK-JOIN Aşa cum rezultă din arhitectura adoptată, aceasta este bazată pe modelul teoretic al cozilor sincronizate, cunoscute şi sub numele de cozi de tip fork-join [62]. Acest model este specific procesărilor paralele şi distribuite, de exemplu cu aplicabilitate la sisteme de discuri de tip RAID [63], sau chiar la managementul proceselor de fabricaţie sau al accesului la magazii industriale. Conform literaturii matematice de specialitate din [64], modelul fork-join, poate fi văzut ca un model simplu de cozi într-un sistem de procesare paralelă. Este format dintr-un număr N de procesoare (servere) paralele, fiecare dispunînd de o coadă proprie locală. Prelucrările de executat (job-uri) sunt formate din N proceduri (tasks) care sunt alocate cozilor diferitelor procesoare, fenomen cunoscut sub numele de faza de fork. O prelucrare 19

20 este considerată ca fiind încheiată dacă toate procedurile componente au fost la rîndul lor terminate, aceasta fiind aşa-zisă fază de join. Se observă urmatoarea analogie cu modelul teoretic fork-join: datele citite de către procesul părinte dintr-un pipeline de sistem (văzut ca un punct unic de interfaţă cu sistemul de operare) sunt împărţite, într-o ordine prestabilită (ciclică, de tip round-robin), între cele N procese fii, prin intermediul segmentului de memorie partajată şi al zonelor tampon conţinute, fiecare de dimensiune maximă B, în faza de fork. Faza de join se execută în fapt la receptorul de date, care are o structură simetrică, şi unde datele sunt recompuse, în aceeaşi ordine, din elementele lor constitutive şi apoi părăsesc sistemul prin alt pipeline, de scriere. De notat faptul că fiecare iteraţie a transmisiei în flux continuu reprezintă o prelucrare formată din N proceduri individuale, de transmisie şi recepţie a datelor în reţea, care trebuie să fie completată în întregime înainte ca urmatoarea prelucrare să fie posibilă Performanţa sistemului Performanţele atinse de sistemul de transfer de tip fork-join sunt determinate de timpul total scurs între momentul iniţial al fork-ului şi cel final, de join, sau, altfel zis, depind de rata de transmisie globală R. În mod evident, aceasta depinde de ratele de transmisie ale conexiunilor TCP individuale, corespunzătoare celor N procese fii, notate, cu. Notînd în continuare, considerînd timpii individuali de transfer, cu, şi şi ţinînd cont de constrîngerile de sincronizare impuse de transmisia ordonată în flux continuu a datelor, R este determinat de ecuaţia: (3.1) din care rezultă dependenţa de rata de transfer cea mai defavorabilă. Ecuaţia (3.1) prezintă deci o problemă în cazul ratelor de transfer inegale (cazul suportului pentru multi-path), de aceea am decis să adaptez gradul de utilizare al zonelor tampon individuale funcţie de viteza de transfer maximă măsurată, conform formulei ponderate: (3.2) Deoarece acum: (3.3) ecuaţia (3.1) devine: (3.4) ceea ce constituie o aproximare ideală a lui R ca fiind suma ratelor de transmisie individuale, cu condiţia ca timpii de transfer individuali să fie corect măsuraţi. Se observă aşadar că soluţia teoretică de îmbunătăţire a ratei de transfer globale care a fost considerată pentru suportul căilor cu rată inegală (multi-path), este de tipul rutării preferenţiale către cozile mai libere, în baza informaţiilor legate de timpii de tranziţie individuali, folosiţi pentru a estima gradul de încărcare al fiecărei conexiuni TCP componente. 20

21 3.4. SUMAR În acest capitol am prezentat arhitectura de sistem de transfer a datelor adoptată şi am arătat care sunt trăsăturile sale remarcabile ce o recomandă pentru efectuarea transmisiilor de date în paralel cu rapiditate dar şi cu uşurinţă. De exemplu, generalitatea prin utilizarea de pipes extinse, încapsularea algoritmilor de transfer, suportul centralizat pentru controlul ratei de transfer şi transmisia multi-path la nivel de aplicaţie. Caracteristici suplimentare, dar semnificative pentru calitatea aplicaţiei de transfer de tip client-server implementate au fost de asemenea discutate în secţiunea 3.3, cu referire, între altele, la autentificarea utilizatorilor, securitatea controlului şi a datelor, suportul pentru split- TCP, traversarea uşoară a maşinilor intermediare cu rol de firewall sau NAT. Deoarece arhitectura se bazează pe modelul cozilor de tip fork-join, o prezentare teoretică şi o justificare a performanţelor de transfer în regim de multi-path este de asemenea inclusă, rezultînd posibilitatea ponderării transmisiei în mod eficient cu scopul obţinerii unei rate de transfer globale apropiată de suma ratelor maxime de transfer ale căilor componente. Referitor la abilitatea arhitecturii considerate de a reutiliza comenzi şi aplicaţii locale de acces la sisteme de stocare specializate, este interesant de exemplificat: cazul accesului la CASTOR [65] (robotul de memorare pe bandă magnetica de la Cern), cu comanda rftar [66] (acces de tip tar) şi comanda rfcat [67] (acces de tip cat); sau controlul facil al ratei de transfer globale prin intercalarea comenzii pmr [68] cu parametrul -l ce limitează viteza de transmisie printr-un pipe la o valoare precizată în linia de comandă. 4. ALGORITMI EFICIENŢI DE TRANSMISIE PARALELĂ 4.1. CARACTERISTICI ALE ALGORITMILOR DE TRANSFER Principala cerinţă a algoritmilor de transfer consideraţi este transmisia datelor în reţea în flux continuu - streaming - dar totodată şi cu viteza ridicată. Aşa cum se poate deduce din diagrama bloc a sistemului prezentată în figura nr. 3.1 de mai sus, soluţia adoptată interconectează, la ambele extremităţi ale transferului de date, o structură de tip pipe, serială în natură, cu un ansamblu de conexiuni TCP paralele, ce conferă viteza dorită în reţea. În acest mod sistemul de comunicaţie interprocesuală prin pipes este extins de la nivel local la comunicarea de tip punct-la-punct în reţea, asigurîndu-se în acelaşi timp o rată de transfer corespunzătoare ansamblului de conexiuni TCP simultan folosite. Ca urmare, algoritmii trebuie să rezolve în mod eficient probleme legate de sincronizare, fără a se diminua semnificativ viteza maximă de transfer a datelor. Termenul de comparaţie va fi modelul simplificat, capabil doar de transferul fişierelor de dimensiuni cunoscute şi divizate în părţi egale, transmise în paralel, dar independent (file striping) Importanţa suportului pentru multi-path Tendinţa actuală de dezvoltare a Internet-ului este de proliferare a maşinilor cu adrese multiple de IP, descrise de RFC 1122 [69] ca fiind de tip multihomed, adică avînd mai multe interfeţe logice de reţea asociate cu una sau mai multe interfeţe fizice, conectate la rîndul lor la aceeaşi reţea sau la reţele diferite. De exemplu, serverele pot fi conectate la furnizori de servicii de Internet (ISP) diferiţi, dispozitive mobile ca tablete sau telefoane inteligente 21

22 (smartphone) sunt capabile de moduri de conectare radio diferite (e.g. LTE, GPRS, Bluetooth, wireless). Centrele de calcul moderne, compuse dintr-un număr considerabil de calculatoare (mii, chiar sute de mii) sunt un caz special de interconectare, care nu se încadrează în clasa multihomed, în care o singură interfaţă logica este conectată la mai multe interfeţe fizice, creîndu-se astfel multiple căi alternative între maşini ce pot mări atît rata de transfer cît şi siguranţa transmisiei. Aşa cum se arată în [70] [71], redundanţa la nivel de căi între oricare două noduri se explică prin utilizarea unei topologii ierarhice de tip arbore cu rădăcini multiple (multi-rooted tree), iar rutarea între noduri se bazează pe algoritmul ECMP, descris de RFC 2992 [72]. Deoarece ECMP alocă în mod static (prin hashing) conexiunile la rutele disponibile, fără să ţină seama de încărcarea reţelei şi nici de ratele de transfer implicate, se pot produce coliziuni la nivel de conector (switch) de reţea şi degradări ale performanţelor de transfer. De aceea, suportul pentru utilizarea de căi multiple în reţea, cu viteze de transmisie inegale, este important fiindcă ajută la îmbunătăţirea performanţelor de transfer, redirectînduse traficul către căile cele mai libere şi pentru că reuşeşte să valorifice în mod eficient gradul mare de paralelism existent în centrele moderne de calcul Specificaţii pentru multi-path În situaţia în care există multiple canale de comunicaţie (e.g. intranet, VPN, WAN), capabile de viteze de transfer diferite şi folosite simultan prin repartizarea unui număr nenul de conexiuni TCP fiecăruia, se pune problema ponderării transmisiei datelor în vederea maximizării debitului total. În absenţa ponderării, din cauza constrîngerilor de sincronizare a fluxului, viteza globală tinde spre viteza celei mai lente conexiuni multiplicată cu numărul de conexiuni folosite, aşa cum rezultă din ecuaţia (3.1). Cu ajutorul ponderării volumului de date furnizat fiecărei conexiuni, funcţie de capacitatea sa curentă estimată, viteza globală este superioară şi se apropie mai mult de suma vitezelor maxime ale fiecărui canal participant la transfer, conform ecuaţiei (3.4). Desemnarea adreselor de IP, sursă şi destinaţie, ce urmează a fi interconectate, se poate face, la nivelul liniei de comandă (cu parametrul j care enumeră, în ordinea dorită, orice combinaţie de adrese sau nume IP) atît pentru client cît şi pentru server, cu scopul de a se controla în mod explicit selecţia altfel implicită a acestora (conform algoritmului descris de RFC 3484 [73] cu privire la alegerea adreselor IP implicite). În acest fel asocierea conexiunilor TCP la canalele existente este determinată exclusiv în baza adreselor IP. De asemenea, mai trebuie precizat că algoritmul cu ponderare a transmisiei proiectat are o trăsătură importantă, şi anume se adaptează la modificarea dinamică a debitelor de transfer per canal, fiind conceput ca un sistem de control de tip PID (proporţional-integralderivativ) [74] [75] FAZELE ALGORITMULUI DE TRANSFER Transmisia fără ponderare Transmisia în flux continuu (streaming), fără ponderare, este formată dintr-un ciclu infinit de scriere/citire în/din reţea, încheiat la terminarea proceselor externe producator/consumator de date interconectate prin sistemul propus de pipes extinse (mai precis atunci cînd citirea, respectiv scrierea din/în pipe-ul local, efectuată de procesul părinte corespunzător, nu mai este posibilă) sau la întîlnirea unei erori fatale de reţea. Asigurarea unui transfer corect în reţea, în condiţii de streaming, unde mărimea datelor de transmis nu este disponibilă, se face prin adoptarea unei convenţii de transmisie cu 22

23 o ordine prestabilită, ciclică (round-robin), variind între 1 şi N (numărul total de conexiuni TCP concurente), aplicată în mod coordonat atît la transmisie cît şi la recepţie. Această soluţie este recunoscută ca fiind optimală în cazul conexiunilor TCP cu rate de transfer egale (servicii identice, descrise în [76]). În speţă, aceasta conduce la alocări statice de memorie (partajată) şi la eliminarea reordonarilor de date la recepţie. Implementarea este realizată exclusiv în cadrul procesului părinte care exercită în acest mod un control centralizat al transmisiei. Atît procesul părinte (cititor/scriitor de pipe) cît şi cei N fii ai săi (scriitori/cititori de reţea) folosesc memoria partajată (vectorul spades) în scopul sincronizării operaţiilor de scriere/citire a zonelor tampon de date (din vectorul buckets, de asemenea partajat) corespunzătoare fiecărei conexiuni TCP concurente, operaţii executate la fiecare pas al ciclului de transmisie. Sincronizarea se referă la faptul că procesul părinte nu are voie să acceseze o zonă tampon pînă cînd acesta nu a fost transferată de procesul fiu corespunzător, iar acestuia nu ii este permisă începerea transferului pînă cînd respectiva zonă nu a fost deja pregătită, scrisă sau citită, de procesul părinte. La rîndul lor, procesele fii sunt responsabile, în principal, de transmisia corectă a datelor, aplicarea opţională (on-the-fly) a compresiei sau/şi criptării datelor precum şi sesizarea şi raportatea erorilor de reţea Controlul transmisiei cu ponderare Scopul principal al operaţiilor de ponderare a gradului de umplere a zonelor tampon este acela al egalizării într-o măsură cît mai bună a timpilor de transmisie per zonă. Se evită în acest mod întîrzierile cauzate de supra alocarea conexiunilor prea lente. Prin reducerea gradului de utilizare a zonelor tampon corespunzătoare conexiunilor lente şi menţinerea la nivel maxim a celor servite de conexiuni rapide se atinge un echilibru ce maximizează rata de transfer globală. Ponderarea debitului de transfer are loc atunci cînd este folosită opţiunea mpath şi bineînţeles doar atunci cînd N este mai mare decît 1. Modificările aduse algoritmului neponderat privesc numai partea de trimitere a datelor, recepţia datelor ramînînd neschimbată. Aceasta constituie un avantaj, din punct de vedere al păstrării compatibilităţii cu versiuni mai vechi ale aplicaţiei în care nu exista suport pentru multi-path. O primă versiune Într-o primă versiune a algoritmului de transmisie cu ponderare s-a încercat identificarea conexiunilor mai lente fără măsurători ale timpilor de transfer individuali. Astfel, o conexiune corespunzătoare unei zone tampon pentru care sunt necesare încă operaţii de sincronizare a accesului este considerată prea lentă dacă cel puţin una dintre celelalte conexiuni a încheiat deja transferul datelor din zona tampon asociată; la următoarea iteraţie i se vor aloca mai puţine date de transmis. Această soluţie are inconvenientul identificării, în cazul cel mai nefavorabil, a cel mult o singură conexiune lentă per iteraţie, deoarece verificările se fac în ordine, de către procesul părinte, iar o primă conexiune prea lentă poate masca pe toate celelalte, care au răgazul necesar încheierii transmisiei. În plus, nu există nici suficiente informaţii pentru determinarea corectă a gradului de diminuare a utilizării zonelor tampon ale conexiunilor lente. De aceea, am adoptat soluţia prezentată în continuare, bazată pe un algoritm de tip PID. Algoritmul cu ponderarea transmisiei Contribuţia proceselor fii la algoritmul ponderat se rezumă numai la raportarea timpilor medii, necesari transmiterii datelor din zonele tampon. Rezultatele măsurătorilor (calculate în microsecunde cu funcţia de bibliotecă clock_gettime) sunt returnate în vectorul speeds aflat de asemenea în memoria partajată. În esenţă, ponderarea transmisiei se referă la ponderarea gradului de utilizare al zonelor tampon în conformitate cu formula (3.2) de mai înainte. De notat faptul că pentru a se 23

24 obţine o ponderare corectă, timpii individuali de transfer ai zonelor tampon (folosiţi la calculul noilor dimensiuni) trebuie să fie măsuraţi numai cu zone tampon egal folosite - la capacitatea lor maximă şi pe o durată de timp suficient de mare pentru a se asigura rezultate valide, în regim TCP stabil. Alterarea prin eventuală micşorare a dimensiunilor zonelor tampon lasă nemodificată alocarea iniţială a memoriei partajate (adresa de start a zonelor tampon rămîne neschimbată) şi deci nu sunt necesare coordonări suplimentare, consumatoare de timp în reţea, cu receptorul datelor. Din punct de vedere al teoriei controlului sistemelor, algoritmul de transmisie cu ponderare îmbracă forma controlului proporţional simplu (P-only), aşa cum rezultă din diagrama din figura 4.1 de mai jos. Se observă că senzorul calculează media timpilor de transmisie individuali care este comparată cu referinţa iniţială, iar dacă valoarea mediei a crescut cu mai mult de 33%, controlorul determină reevaluarea gradului de folosirea a zonelor tampon, ceea ce reglează corespunzător ratele de transfer individuale şi timpii aferenţi, asigurîndu-se astfel optimizarea continuă a performanţei globale de transfer, în condiţiile existenţei perturbaţiei reprezentată de variabilitatea ratei de transfer per conexiune. Asemeni oricărui sistem automat de control, algoritmul ponderat execută în mod repetitiv o procedură de tip măsurare-calculare-acţiune care însă conţine şi o serie de optimizări ce sporesc performanţa cît şi stabilitatea sistemului. De exemplu, pentru a se controla mai bine situaţia în care algoritmul cu ponderare este aplicat unui transfer de date cu rate egale per conexiune, s-a introdus şi calcularea dispersiei timpilor individuali de transfer în evaluarea funcţiei de eroare a sistemului de control (aşa cum se detaliază mai jos), obţinîndu-se o funcţionare asemănătoare algoritmului neponderat (cu zone tampon utilizate la maximum şi fără secvenţe de măsurare inutile). Fazele propriu-zise ale transferului ponderat sunt controlate de o variabilă de stare, lmd, care este decrementată în cadrul ciclului principal de transmisie, conform următoarelor etape succesive: pentru valori strict pozitive ale lmd, se efectuează măsurarea timpilor de transmisie individuali,, în condiţiile în care zonele tampon sunt utilizate la volumul maxim (B). Întro primă versiune, numărul de paşi dedicaţi măsurării a fost fix (şi egal cu 7); ulterior, ca urmare a extinderii experimentelor în reţele cu capacitate de transfer mărită (pînă la 8 Gbps), am adoptat un număr de paşi variabil, calculat dupa o formulă invers proporţională cu numărul de conexiuni N (cel mult 12, dar nu mai mic decît 2). pentru lmd = 0, se determină gradul de umplere al zonelor tampon, calculat proporţional cu raportul, unde pmint este timpul cel mai scurt de transmisie al unei zone tampon, iar (*pspeed) este timpul de transmisie al zonei tampon curente, în acord cu formula (3.2). Factorul 1.3 produce o uşoară supra-alocare, utilă în situaţia în care în viitor respectiva conexiune devine capabilă de debite de transfer superioare, altfel greu detectabile (din cauză de starvation). În termeni ai teoriei sistemelor, reprezintă un filtru al controlului. următorii 9 paşi ( ) sunt de aşteptare, pentru a permite protocolului TCP să atingă o stare stabilă (de evitare a congestiei). în continuare se intră într-o buclă de feedback, în care, la fiecare trei paşi ( ) se reevaluează condiţia de efectuare a unei noi reponderări a transmisiei. În versiunea sa îmbunătăţită, intrarea în bucla de feedback este evitată dacă media timpilor de transfer individuali sau dispersia acestora este mai mare decît valorile respective calculate mai înainte, la terminarea fazei de măsurare; astfel, dacă atît media cît şi dispersia au crescut (în urma ponderării dimensiunilor utile ale zonelor tampon), atunci se consideră că sunt de preferat zone tampon maxime, egale; iar dacă fie media ori dispersia sunt mărite, atunci se reia ciclul principal cu faza primă, de măsurare, direct. Ieşirea din bucla de feedback se produce atunci cînd media timpilor de transfer individuali creşte cu mai mult de 33%, moment în care se reia ciclul principal cu etapa iniţială de măsurare (cu zone tampon egale). 24

25 Fig Controlul proporţional, P-only, al transmisiei ponderate Strategii de optimizare a ponderării transmisiei Pentru a îmbunătăţi atît precizia de calcul a timpilor de transfer per conexiune, cît şi stabilitatea şi rata globală de transfer ale transmisiei, am recurs la cîteva strategii practice, rezultate în urma numeroaselor experimente efectuate. Astfel, am inclus un mecanism (simplu) de alarmă care să declanşeze reponderarea transmisiei cu scopul de a corecta cazurile mai rare în care rata de transfer globală a devenit determinată (în mod eronat) de rata de transfer a conexiunii celei mai lente. Asemenea cazuri se produc în urma unei estimări greşite a timpilor de transfer per zonă atunci cînd, de exemplu, protocolul TCP este încă în faza de slow-start. De asemenea, am renunţat, din prima versiune a algoritmilor, la scăderea mediei timpilor de transfer ca motiv de declanşare a reponderării (păstrînd numai creşterea), pentru a se îmbunătăţi stabilitatea, în sensul evitării fazelor de măsurare nenecesare. Am apreciat că scăderea mediei este de fapt un răspuns pozitiv al sistemului care nu mai are nevoie de un control suplimentar. În sensul teoriei sistemelor, am aplicat un filtru asupra funcţiei de control. Totodată am introdus o estimare continuă a referinţei din bucla de feedback, calculată ca fiind media ultimelor trei valori ale mediei timpilor de transfer individuali (în loc de valoarea fixă iniţială). Această abordare transformă sistemul de control într-unul de tip PI (proporţional-integral) în care funcţia de eroare este însumată în timp. În acest mod se corectează fluctuaţiile specifice controlului proporţional simplu, P-only, cauzate de faptul că la echilibru funcţia de eroare prezintă o valoare (offset) nenulă Pseudocodul algoritmului de transmisie (cu ponderare opţională) În implementarea propriu-zisă atît transmisia cît şi recepţia datelor sunt codificate în acelaşi ciclu, din motive de eficienţă (e.g. codul dedicat sincronizării este acelaşi, indiferent de sensul transferului). Pentru claritate, algoritmul 4.1 redă numai cazul transmisiei, cu ponderare opţională, aşa cum este executat de procesul părinte, în pseudocod. ALGORITMUL 4.1 Transmisie cu ponderare - opţională Necesită: Memorie partajată iniţializată cu N zone tampon 1: shaping = mpath && N > 1 2: lmd = 6 * 4 / requestedstreamnumber 3: loop 25

26 4: Repetă pînă la terminare date sau eroare reţea 5: for i = 0 to N - 1 do 6: Aşteaptă golirea zonei i 7: if shaping then 8: if lmd = -1 then 9: if mint = -1 then 10: Setează grad de umplere maxim 11: else 12: Calculează gradul de umplere al zonei i 13: end if 14: else if lmd >= 0 then 15: Setează grad de umplere maxim 16: end if 17: if lmd = 0 then 18: Citeşte şi calculează minimul timpului de golire al zonelor în mint 19: end if 20: if (lmd = 0) or (lmd = -12) then 21: Calculează media st şi dispersia stsq a timpilor de golire ai zonelor 22: end if 23: if (lmd > 0) or (lmd <= -9) then 24: Comandă măsurarea timpilor de transmisie 25: end if 26: end if 27: Transferă date din pipe în zona i 28: end for 29: if shaping then 30: if 0 = lmd then 31: Salvează media msig6 şi dispersia msd a timpilor măsuraţi cu zone egale 32: end if 33: if lmd = -12 then 34: Calculează media sig6 şi dispersia sd a timpilor curenţi 35: if (sig6 > msig6) and (sd > msd) then 36: Continuă cu zone egale, maxime, mint = -1 37: end if 38: if (sig6 > msig6) or (sd > msd) then 39: continue {Reponderare} 40: end if 41: if psig6 = -1then psig6 = sig6, continue {Start feedback} end if 42: if 3 * sig6 > 4 * psig6 then 43: lmd = 6 * 4 / requestedstreamnumber 44: continue {Reponderare} 45: end if 46: end if 47: --lmd, continue 48: end if 49: end loop 4.3. SUMAR Acest capitol a prezentat principalii algoritmi de transmisie a datelor în flux continuu proiectaţi. Aceştia se bazează pe folosirea de conexiuni TCP multiple, în vederea obţinerii 26

27 unei rate de transfer în reţea performante, conectate la structuri de intercomunicaţie între procese de tip pipe, la nivelul local al sistemului de operare. Trăsăturile caracteristice acestor algoritmi se referă la realizarea unei sincronizări de flux eficiente care să nu introducă întîrzieri semnificative în comparaţie cu metoda obişnuită de transfer bazată pe file striping. Suportul algoritmilor pentru multi-path este justificat în contextul existenţei maşinilor multihomed, al dispozitivelor mobile moderne cu acces radio multiplu (e.g. GPRS, wireless) sau al centrelor de calcul cu trasee multiple între nodurile componente. Au fost prezentate fazele principale ale algoritmului de transmisie ponderată, văzute prin prisma unui sistem de control de tip PID, pseudocodul algoritmului, precum şi principalele strategii de îmbunătăţire a acestuia, care l-au încadrat în clasa de algoritmi de control PI (proporţional şi integral). Parametrii de reglaj proiectaţi, în special cei privitori la bucla de feedback şi sensibilitatea acesteia la variaţiile debitului vor fi validaţi în capitolul următor dedicat experimentelor în reţea. 5. METODOLOGIE DE VALIDARE ŞI REZULTATE EXPERIMENTALE În acest capitol se validează modelul de transfer a datelor în reţea, cu viteză, prin pipes, în flux continuu (byte streaming) şi se demonstrează calităţile sale superioare, legate în special de generalitatea abordării, prin studierea comparativă cu modelul de transfer bazat pe transmisia fişierelor în paralel (file striping clasic). Pentru a demonstra că file striping se reduce de fapt la un caz particular de streaming, în care dimensiunea datelor de transmis este cunoscută în avans (egală cu mărimea fişierului de transferat) a fost necesar să verific că rata de transfer prin streaming nu este penalizată semnificativ de constrîngerile de sincronizare specifice, nici chiar în cazul unor reţele cu capacitate de transfer mai mare (de pînă la 8 Gbps) - ceea ce am realizat prin experimentele descrise în secţiunea 5.2. De asemenea, a fost important de demonstrat calitatea suportului centralizat pentru multi-path la nivel de aplicaţie, facilitat de separarea între detaliile de acces la date aflate în sisteme de stocare locale (eventual specializate, e.g. CASTOR) şi algoritmii noi, de transfer, în flux, în reţea (conform arhitecturii de sistem din capitolul 3) - ceea ce am prezentat prin experimentele din secţiunea CONSIDERAŢII METODOLOGICE Pentru a evalua performanţele algoritmilor de transfer am creat o aplicaţie (bbftppro [77]) care implementează cele trei categorii de algoritmi descrişi în capitolele anterioare, şi anume algoritmul orientat spre transferul simplu de fişiere în paralel (file striping), algoritmul simplu de transfer de date cu viteza în flux continuu (streaming) şi algoritmul cu ponderarea ratei de transmisie în flux continuu (pentru suport de multi-path). Integrarea algoritmilor în aceeaşi aplicaţie a permis configurarea cu precizie a parametrilor de reţea, în speţă a protocolului TCP, în mod identic pentru fiecare din modelele 27

28 de transfer experimentate. În plus, instrumentarea a fost de asemenea comună, ceea ce a conferit încredere în rezultatele obţinute, de măsurare a ratelor de transfer în reţea în fiecare din cazurile considerate. În această fază a cercetării am preferat să nu folosesc sisteme de simulare a reţelelor pentru validarea algoritmilor de transfer, din urmatoarele două motive principale: pentru a grăbi implementarea într-o formă direct utilizabilă, avînd în vedere faptul că tehnologia mea a fost adoptată devreme (ceea ce, la rîndul său, m-a încurajat să cercetez şi să dezvolt mai departe noii algoritmi) - de exemplu, de către departamentul de fizica particulelor de la Institutul Weizmann [78], de către cercetătorii de la experimentul VIRGO [2], de către centrul grid US Atlas MWT2 [79]. Astfel, în figura 5.1 se prezintă performanţele obţinute de către cei din urmă, pe o legatură de tip Starlight de 10 Gbps şi un transfer inter-cluster, discla-disc, între universităţile din Chicago şi Indiana (membre ale MWT2). deşi un simulator de reţea este capabil să configureze cu uşurinţă o topologie de reţea completă, prin natura sa, aşa cum rezultă din descrierea din capitolele anterioare, performanţa algoritmilor de transfer se bazează în esenţă pe elemente de sincronizare a fluxului de date şi pe ponderarea debitului transmisiei, ambele operaţii complexe, dar independente de o configuraţie concretă de reţea, fiind deci mai uşor de implementat în afara nivelului de transport (în cazul de faţă la nivel de aplicaţie). Fig Transfer disc-la-disc, într-o reţea Starlight de 10 Gbps Platforme de test Măsurătorile au fost realizate prin transferuri de date între perechi de calculatoare situate în trei categorii de reţele şi anume: o reţea MAN orăşenească, servită de un ISP cu lăţimea de bandă maximă egală cu 100 Mbps. o reţea locală ad-hoc, cu debit maxim de 1 Gbps. o reţea de tip IPoIB, cu transmisie de IP în reţea Infiniband, cu viteze de transfer maxime de pînă la 8 Gbps; nodurile acestei reţele aparţin unui cluster performant, avînd calculatoare de tip Opteron, cu 12 procesoare (cores) şi hyper-threading (cu 24 procesoare per nod) cu frecvenţa de lucru de 3GHz şi avînd fiecare 32GB de memorie internă. În acest mod am putut studia performanţele algoritmilor de transfer în condiţiile cele mai variate aflate la dispoziţie. De exemplu, am obţinut o rată de transfer în flux continuu, memorie-la-memorie, de peste 14 Gbps, folosind interfaţa de loopback a computerelor din cluster-ul performant. De asemenea, pe durata transferurilor am monitorizat reţeaua cu ajutorul programului System Monitor, atunci cind a fost posibil, iar în lipsa acestuia, s-au cules datele raportate de programul pmr, referitoare la viteza de transfer instantanee (în regim de flux continuu), în vederea prezentării de date grafice calitative în completarea celor cantitative. 28

29 5.2. PERFORMANŢA ÎN FLUX CONTINUU ŞI CEA ORIENTATĂ FIŞIER Într-o primă serie de experimente am fost interesat să constat dacă folosirea de pipes pentru transferul în flux continuu are vreun impact asupra performanţelor de transfer, în comparaţie cu transferul orientat către transmisia de fişiere prin file striping. Deoarece în file striping este obligatorie folosirea de fişiere de dimensiuni cunoscute şi pentru a elimina latenţa produsă de discurile de sistem, am întrebuinţat fişiere în memorie (de tip tmpfs) în cazul reţelelor rapide (de 1 Gbps şi 8 Gbps). În fiecare situaţie, mărimea fişierelor transmise a fost adecvată capacităţii de transport a reţelei, în sensul atingerii unui regim de transfer stabil TCP, iar numărul de conexiuni paralele a fost variat pînă la atingerea saturaţiei în reţea. Transmisia în flux continuu a fost realizată prin interconectarea cu pipes extinse la distanţă a comenzii de sistem cat. În figura 5.2 se prezintă rata de transfer medie obţinută în cazul transferurilor unui fişier de pe disc, de 300 MB, folosindu-se 1 pînă la 4 conexiuni TCP simultane, în reţeaua de 100 Mbps, în ambele moduri, atît file striping cît şi file streaming. Viteza de transfer medie a unui fişier în memorie de 400 MB, cu numărul de conexiuni TCP paralele variind între 1 şi 14, în reţeaua de 1 Gbps, este prezentată în figura 5.3 (striping şi streaming). Rezultatele transferului unui fişier în memorie de 10 GB, cu o variaţie a numărului de conexiuni TCP între 1 şi 24, în reţeaua de 8 Gbps, sunt prezentate în figura 5.4 (viteze medii, striping şi streaming). Fig Striping şi streaming în paralel, reţea de 100 Mbps Fig Striping şi streaming în paralel, reţea de 1 Gbps Fig Striping şi streaming în paralel, reţea de 8 Gbps 29

30 Cazul transferurilor de directoare O altă serie de experimente semnificative pentru posibilităţile celor două moduri de transfer au fost transferurile unor subdirectoare în întregime, cu ierarhie, număr şi dimensiuni ale fişierelor conţinute variabile. De notat faptul că metoda bazată pe file striping a beneficiat atît de o implementare internă eficientă a algoritmului de parcurgere recursivă a directoarelor, care minimizează necesarul de comunicaţii de control în reţea (e.g. pentru listări de subdirectoare), cît şi de posibilitatea combinării transferului simultan al mai multor fişiere (mai mici) în paralel. Aceasta o recomandă, desigur, ca un element de referinţă valid în comparaţia cu sistemul de transfer prin streaming. De fiecare dată, durata totală a transferurilor a fost în medie de două pînă la patru ori mai mică cînd datele au fost transferate interconectînd prin pipes extinse procese de tip tar/un-tar, faţă de modul de transfer recursiv, fişier după fişier, prin striping PERFORMANŢELE TRANSMISIEI ÎN FLUX CONTINUU În vederea evaluării performanţelor algoritmilor de transfer în flux continuu cu şi fără ponderare a debitului, a fost necesară crearea unei topologii de reţea prevăzută cu un număr de canale virtuale independente şi rate de transfer diferite, dar bazată pe utilizarea capacităţii de transfer existentă la nivelul reţelei fizice, aşa cum este exemplificat în figura 5.5. Cu toate că, din motive obiective, nu a fost posibilă adăugarea de interfeţe multiple de reţea la calculatoare prevăzute doar cu o singură placă de reţea activă (ceea ce le-ar fi conferit caracteristici multihomed veritabile), iar ruta între perechile de participanţi la transferul de date a fost în fapt fixă, acest mod de testare, bazat pe căi de transfer suprapuse dar independente sub aspectul capacităţii de transmisie, a satisfăcut condiţiile necesare unei evaluări corecte a algoritmilor consideraţi deoarece aceştia sunt, în esenţă, sensibili la rata de transfer a conexiunilor individuale. Fig Topologie cu 3 canale virtuale independente într-o reţea IPoIB de 8 Gbps Setările necesare au fost realizate cu programul de control al traficului tc, prin crearea de aliasuri cu mai multe adrese de IP distincte ce au fost apoi asociate atît în mod static cît şi în mod dinamic la canale cu rate de transfer maxime diferite. Astfel, în fiecare dintre cele trei reţele testate, am constituit un număr de cîte trei canale, avînd o rată de transfer maximă de 10, 20 şi 30 Mbps pentru reţeaua de 100 Mbps, de 100, 200 şi 300 Mbps în reţeaua de 1 Gbps şi respectiv de 1, 2 şi 3 Gbps în cea de-a treia reţea, de capacitate totală egală cu 8 Gbps. Această configuraţie a fost aleasă pe considerentul de a nu se folosi în total mai mult decît 75% din capacitatea fizică totală a reţelei, pentru a se realiza un regim de funcţionare sigură în condiţiile traficului bazat pe conexiuni TCP. Apreciez de asemenea că valorile alese pentru debitele per canal sunt şi suficient de distincte pentru a se ilustra abilitatea algoritmilor de a folosi într-o bună măsură întreaga lăţime de bandă a transmisiei, în concordanţă cu 30

31 valorile teoretice estimate de ecuaţia (3.4) de mai sus, în condiţii cît mai apropiate de un regim de funcţionare reală optimizată Experimente în regim static Transferurile au fost de tipul memorie-la-memorie şi fiecare măsurare s-a făcut pe durata a 60 de secunde, timp ales astfel încît să se poată atinge un regim TCP de echilibru stabil. Am variat numărul de canale folosite simultan (între 2 şi 3), numărul de conexiuni TCP concurente şi distribuţia acestora per canal. Astfel, în reţeaua de 100 Mbps şi cea de 1 Gbps, am alocat cîte o conexiune fiecărui canal, în mod circular, pînă cînd toate conexiunile au fost alocate. În reţeaua de 8 Gbps s-au alocat cîte două conexiuni per canal care să utilizeze debitul considerabil al acestei reţele. Fiecare testare s-a făcut fără şi cu ponderarea transmisiei. De notat faptul că distribuirea în mod circular a conexiunilor la canale a servit şi la o bună ilustrare grafică a răspunsului diferit al celor doi algoritmi respectivi. Totodată, am avut grijă ca numărul total de conexiuni TCP să nu fie nici excesiv de mare, ceea ce ar fi produs efecte negative legate de saturarea reţelei sau chiar diminuarea ratei de transfer globale din cauza declanşării congestiei în reţea, aşa cum s-a precizat în secţiunea În figura 5.6 se prezintă rata de transfer medie pentru două canale, de 20 şi 10 Mbps, cu 2 pînă la 8 conexiuni TCP paralele, în reţeaua de 100 Mbps. Figura 5.7 prezintă rata de transfer medie pentru trei canale, de 30, 20 şi 10 Mbps, cu 3 pînă la 9 conexiuni TCP paralele, în aceeaşi reţea. Cazul reţelei de 1 Gbps se prezintă în figura 5.8 cuprinzînd rata de transfer medie pentru două canale, de 200 şi 100 Mbps, cu 2 pînă la 8 conexiuni TCP concurente şi în figura 5.9, în care se arată rata de transfer medie pentru trei canale, de 300, 200 şi 100 Mbps, cu 3 pînă la 9 conexiuni TCP concurente. Rezultatele obţinute în reţeaua de 8 Gbps sunt înfăţişate în figura 5.10, în care se arată rata de transfer medie pentru două canale, de 2 şi 1 Gbps, cu 4 pînă la 24 conexiuni TCP simultane şi în figura 5.11 în care se prezintă rata de transfer medie pentru trei canale, de 3, 2 şi 1 Gbps, cu 6 pînă 24 conexiuni TCP simultane. Fig Două canale, Mbps Fig Trei canale, Mbps 31

32 Fig Două canale, Mbps Fig Trei canale, Mbps Fig Două canale, 2+1 Gbps Fig Trei canale, Gbps 32