TEZĂ DE DOCTORAT - acs.pub.roacs.pub.ro/system/files/REZUMAT_teza_doctorat_Dan_Schrager.pdf ·...

FONDUL SOCIAL EUROPEAN

Investeşte în oameni!

Programul Operaţional Sectorial pentru Dezvoltarea Resurselor Umane 2007 – 2013

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 ................................................................................................................. 4

1.1. MOTIVAREA CERCETĂRII .................................................................................... 4

1.2. OBIECTIVELE CERCETĂRII .................................................................................. 5

2. STUDIU COMPARATIV AL TEHNICILOR ŞI APLICAŢIILOR DE TRANSFER DE

DATE ÎN REŢEA ....................................................................................................................... 7

2.1. TRANSFERURILE DE DATE ŞI MEDIUL GRID ................................................... 7

2.1.1. Serviciul FTS ....................................................................................................... 7

2.2. SISTEMUL PROTOCOALELOR DE COMUNICAŢIE ÎN REŢEA ....................... 8

2.2.1. Protocolul TCP..................................................................................................... 8

2.2.2. Performanţele TCP............................................................................................... 9

2.2.3. Performanţa conexiunilor TCP multiple .............................................................. 9

2.3. DIVERSE IMPLEMENTĂRI ALE TCP .................................................................. 10

2.3.1. TCP Sack ........................................................................................................... 10

2.3.2. TCP Vegas ......................................................................................................... 10

2.3.3. HighSpeed TCP ................................................................................................. 11

2.3.4. Fast TCP............................................................................................................. 11

2.3.5. MPTCP .............................................................................................................. 11

2.3.6. MulTCP.............................................................................................................. 12

2.4. MANAGEMENTUL ACTIV AL COZILOR DIN RUTERE (AQM) ..................... 12

2.4.1. Algoritmul RED ................................................................................................. 12

2.4.2. Algoritmul BLUE .............................................................................................. 12

2.4.3. Algoritmul SFB .................................................................................................. 13

2.5. PROTOCOALE NON-TCP ...................................................................................... 13

2.5.1. XCP .................................................................................................................... 13

2.5.2. SCTP .................................................................................................................. 13

2.5.3. DCCP ................................................................................................................. 14

2.6. APLICAŢII DE TRANSFER RAPID....................................................................... 14

2.6.1. XFTP .................................................................................................................. 14

2.6.2. Psockets.............................................................................................................. 15

2.6.3. Globus GridFTP ................................................................................................. 15

2.6.4. RBUDP .............................................................................................................. 15

2.6.5. SABUL .............................................................................................................. 16

2.6.6. GridFTP Overlay ............................................................................................... 16

2.7. SUMAR ..................................................................................................................... 16


3

3. ARHITECTURA SISTEMULUI DE TRANSFER DE DATE ........................................ 17

3.1. ARHITECTURĂ ....................................................................................................... 17

3.2. CAPABILITĂŢI CLIENT-SERVER SUPLIMENTARE ........................................ 19

3.3. MODELUL COZILOR DE TIP FORK-JOIN .......................................................... 19

3.3.1. Performanţa sistemului ...................................................................................... 20

3.4. SUMAR ..................................................................................................................... 21

4. ALGORITMI EFICIENŢI DE TRANSMISIE PARALELĂ ........................................... 21

4.1. CARACTERISTICI ALE ALGORITMILOR DE TRANSFER .............................. 21

4.1.1. Importanţa suportului pentru multi-path ............................................................ 21

4.1.2. Specificaţii pentru multi-path ............................................................................ 22

4.2. FAZELE ALGORITMULUI DE TRANSFER......................................................... 22

4.2.1. Transmisia fără ponderare .................................................................................. 22

4.2.2. Controlul transmisiei cu ponderare ................................................................... 23

4.2.3. Strategii de optimizare a ponderării transmisiei ................................................ 25

4.2.4. Pseudocodul algoritmului de transmisie (cu ponderare opţională) .................... 25

4.3. SUMAR ..................................................................................................................... 26

5. METODOLOGIE DE VALIDARE ŞI REZULTATE EXPERIMENTALE .................... 27

5.1. CONSIDERAŢII METODOLOGICE ...................................................................... 27

5.1.1. Platforme de test ................................................................................................ 28

5.2. PERFORMANŢA ÎN FLUX CONTINUU ŞI CEA ORIENTATĂ FIŞIER ............ 29

5.2.1. Cazul transferurilor de directoare ...................................................................... 30

5.3. PERFORMANŢELE TRANSMISIEI ÎN FLUX CONTINUU ................................ 30

5.3.1. Experimente în regim static ............................................................................... 31

5.3.2. Experimente în regim dinamic ........................................................................... 33

5.3.3. Cazul transferurilor de tip split-TCP.................................................................. 34

5.4. ANALIZA REZULTATELOR EXPERIMENTALE ............................................... 35

5.4.1. Consideraţii cantitative ...................................................................................... 35

5.4.2. Analiza regimului ponderat şi neponderat ......................................................... 35

5.5. SUMAR ..................................................................................................................... 37

6. CONCLUZII ŞI DIRECŢII DE CERCETARE VIITOARE ............................................ 37

6.1. CONTRIBUŢIILE TEZEI ........................................................................................ 38

6.2. DISEMINAREA CERCETĂRII ............................................................................... 39

6.3. DIRECŢII DE CERCETARE VIITOARE ............................................................... 39

BIBLIOGRAFIE - SELECTIVĂ .............................................................................................. 40


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].

1.1. 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.


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 client-

server complete, gata de utilizat în producţia în medii grid.

1.2. OBIECTIVELE CERCETĂRII

Conform tezei mele:

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.


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.


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.

2.1.1. 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.


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.

2.2. 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.

2.2.1. 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


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.

2.2.2. 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.

2.2.3. 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. 2.4.

Î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


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.

2.3. 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.

2.3.1. 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.

2.3.2. 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.


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.

2.3.3. 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.

2.3.4. 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.

2.3.5. 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 2009.

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


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].

2.3.6. 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.

2.4. 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.

2.4.1. 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ă.

2.4.2. 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


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.

2.4.3. 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 1.

2.5. 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.

2.5.1. 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.

2.5.2. 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ă.


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.

2.5.3. 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.

2.6. 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ă.

2.6.1. 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


15

utilizare de 90% a capacităţii unei linii T1 (via satelit, cu o viteză de pînă la 1.544 Mbps), faţă

de numai 24% în cazul FTP.

2.6.2. 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]).

2.6.3. 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.

2.6.4. 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 propriu-

zise 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 slow-

start 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.


16

Rezultatele experimentale demonstrează că RBUDP poate transfera cantităţi mari de

date cu viteză apropiată de capacitatea maximă de transmisie a reţelei.

2.6.5. 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.

2.6.6. 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.

2.7. 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


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 aplicaţii)

NU DA - -

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 (QoS/dedicate)

NU NU NU -

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


18

transmisie per proces.

Fig. 3.1. 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).


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ţă.

3.3. 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


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ă.

3.3.1. 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.


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

4.1.1. 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


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îndu-

se 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.

4.1.2. 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-integral-

derivativ) [74] [75].

4.2. FAZELE ALGORITMULUI DE TRANSFER

4.2.1. 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


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.

4.2.2. 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


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). Într-

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


25

Fig. 4.1. Controlul proporţional, P-only, al transmisiei ponderate

4.2.3. 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ă.

4.2.4. 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


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


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 5.3.

5.1. 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


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, disc-

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

5.1.1. 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.

Fig. 5.1. Transfer disc-la-disc, într-o reţea Starlight de 10 Gbps


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. 5.2. Striping şi streaming în

paralel, reţea de 100 Mbps


paralel, reţea de 1 Gbps


paralel, reţea de 8 Gbps


30

5.2.1. 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.

5.3. 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.

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

Fig. 5.5. Topologie cu 3 canale virtuale independente într-o reţea IPoIB de 8 Gbps


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ă.

5.3.1. 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 2.2.3.

Î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. 5.7. Trei canale,

30+20+10 Mbps

Fig. 5.6. Două canale,

20+10 Mbps


32


3+2+1 Gbps


2+1 Gbps


300+200+100 Mbps


200+100 Mbps


33

5.3.2. Experimente în regim dinamic

Am fost de asemenea interesat şi de testarea în regim dinamic a algoritmilor de

transfer în flux continuu. Astfel, fără a întrerupe transmisia de date, am mărit şi micşorat

alternativ, la fiecare 20 de secunde, rata de transfer a conexiunilor individuale prin asocierea

acestora la canale cu debit diferit. Acest interval de timp a fost ales suficient de mare raportat

la durata tranziţiei între regimurile de funcţionare stabilă, egală cu aproximativ 4 secunde (în

cazul modului ponderat), pentru a se putea ilustra în mod concludent caracterul stabil al

transmisiei (ponderate) în regim dinamic, cu ajutorul metodelor de monitorizare menţionate.

Figura 5.12 prezintă traficul de reţea monitorizat cu System Monitoring, surprinzînd

transmisia fără (stînga) şi respectiv cu ponderare (dreapta) a 4 conexiuni TCP concurente,

două alocate unui canal de 10 Mbps şi alte două alocate alternativ, unui canal de 20 Mbps şi

respectiv de 30 Mbps, în reţeaua de 100 Mbps.

În reţeaua de 1 Gbps, traficul de reţea monitorizat tot cu System Monitoring,

reprezentînd transmisia fără (stînga) şi cu ponderare (dreapta) a 8 conexiuni TCP paralele, 4

alocate unui canal de 100 Mbps şi alte 4 alocate alternativ, unui canal de 200 Mbps şi

respectiv de 300 Mbps, este infăţişat în figura 5.13.

În reţeaua de 8 Gbps, instrumentarea s-a făcut cu programul pmr, intercalat în

sistemul de transmisie printr-un pipe (local), colectîndu-se valorilor ratei de transmisie

raportate de acesta o dată per secundă. Figura 5.14 arată rata de transfer atît a transmisiei fără

cît şi cu ponderare, a 12 conexiuni TCP simultane, 6 alocate unui canal de 1 Gbps şi celelalte

6 alocate alternativ, unui canal de 2 Gbps şi respectiv de 3 Gbps.

Fig. 5.12. Patru conexiuni TCP, 10+20|30 Mbps

Fig. 5.13. Opt conexiuni TCP, 100+200|300 Mbps

Fig. 5.14. Douăsprezece conexiuni TCP, 1+2|3 Gbps


34

5.3.3. Cazul transferurilor de tip split-TCP

Pentru a verifica abilitatea aplicaţiei de a efectua transferuri de date în flux continuu,

de tip split-TCP, în care un transfer direct între două calculatoare este înlocuit cu o cale

formată din două sau mai multe segmente distincte, separate de calculatoare intermediare cu

rol de releu de transmisie, a fost constituită o reţea de test specială, cu topologia reprezentată

în figura 5.15. Astfel, între calculatorul sursă S şi destinaţia D se află atît o cale directă, cu o

rată de transfer maximă de 25 Mbps, cît şi o cale compusă din două segmente, primul de la S

la R (un calculator releu) avînd o rată de transfer maximă de 65 Mbps şi cel de-al doilea, de la

R la D, cu rata maximă de 1 Gbps.

Testarea s-a făcut în regim de transferuri memorie-la-memorie, cu durata de 60 de

secunde, variindu-se numărul de conexiuni TCP paralele între 1 şi 8, iar rata de transfer

medie obţinută în fiecare caz este prezentată în figura 5.16, care conţine şi rata transmisiei

între S şi R, pentru comparaţie. Procesele implicate în transferul de date sunt:

cat /dev/zero | Client(S) | ... | Server(D) | cat >/dev/null ; transfer direct.

cat /dev/zero | Client(S) | ... | Server(R) | Client(R) | ... | Server(D) | cat >/dev/null ;

transfer via R.

unde pipe-ul extins în reţea este reprezentat cu simbolul ”| ... |”, iar pipe-ul normal (local, la

nivelul sistemului de operare) cu simbolul ”|”. Se observă ca releul R execută atît procesul

server de conectare cu S, cît şi un proces client, de conectare cu D, comunicarea

interprocesuala a datelor făcîndu-se cu un pipe normal.

Fig. 5.15. Topologie de reţea de tip split-TCP

Fig. 5.16. Transferuri directe şi split-TCP


35

5.4. ANALIZA REZULTATELOR EXPERIMENTALE

Analiza rezultatelor unui număr variat de experimente efectuate în reţele reale

demonstrează abilitatea algoritmilor de transfer în paralel de a realiza transmisii de date în

flux continuu, cu viteză ridicată, în condiţiile existenţei constrîngerilor de sincronizare şi

validează modelele teoretice care stau la baza utilizării căilor multiple, de viteză inegală, în

condiţii atît statice cît şi dinamice.

5.4.1. Consideraţii cantitative

Din punct de vedere cantitativ algoritmii de transmisie în flux continuu apar a fi la fel

de rapizi ca şi cei bazaţi pe file striping atunci cînd conexiunile TCP concurente urmează căi

identice sau cel puţin cu aceeaşi rată de transfer maximă. În acest caz sincronizarea fluxului

la nivelul zonelor tampon nu introduce întîrzieri notabile deoarece timpii de golire ai zonelor

sunt practic egali.

Aceasta rezultă din figurile 5.2, 5.3 şi 5.4 în care rata medie de transfer creşte

aproximativ liniar cu numărul de conexiuni TCP paralele pînă la atingerea unei valori de

saturaţie de aproximativ 90% din laţimea de bandă disponibilă, în concordanţă cu

peformanţele teoretice ale protocolului TCP, pentru ambii algoritmi la fel şi în toate cele trei

tipuri de reţele considerate.

La o examinare mai atentă, în cazul reţelelor rapide, de 1 Gbps şi 8 Gbps, pentru care

fiecare microsecundă contează, transmisia de tip file striping apare să aibă un avantaj iniţial

(pentru mai puţine conexiuni simultane) faţă de cea în flux continuu. Aceasta se explică prin

faptul că există operaţii suplimentare de sincronizare ce nu pot fi excluse la transmisia în flux

continuu, dar absente în cazul transmisiei de tip file striping. Cu toate acestea, cînd parametrii

de transmisie sunt corect configuraţi (e.g. zone tampon de dimensiuni sporite) şi pentru un

număr mai mare de conexiuni simultane, rata medie de transfer devine sensibil egală, astfel

încît penalitatea introdusă de sincronizare devine neglijabilă.

Diferenţe semnificative apar atunci cînd operaţiile de transfer nu sunt continui, aşa

cum am constat la sincronizarea în reţea a directoarelor cu multe fişiere mici. În aceste cazuri,

numărul de conexiuni concurente nu a contat practic, ci numai gradul mare de fragmentare al

transmisiei TCP, în special pentru multele fişiere mici, transferate pe rînd prin file striping,

ceea ce explică durata totală mult mai mare decît pentru tar/un-tar.

De asemenea, cazul split-TCP experimentat demonstrează avantajul ce se poate

obţine, sub aspectul unei rate de transfer superioare, atunci cînd există mecanisme de

înlocuire a unui transfer direct cu altul via unul sau mai multe relee intermediare. Calea

optimă este cea al cărei segment cel mai lent are o rată de transfer maximă în raport cu

celelalte căi posibile. Astfel, din figura 5.16 rezultă că transferul S->R->D atinge o rată medie

de transfer de care este de aproape trei ori mai mare decît rata medie a

transferului direct, S->D, de numai . În fapt, viteza S->R->D este aproximativ

egală cu viteza S->R ( ), ceea ce arată şi overhead-ul redus introdus de releul R

(segmentl R->S fiind de 1 Gbps, deci cu întîrzieri de propagare neglijabile).

5.4.2. Analiza regimului ponderat şi neponderat

Rezultatele cele mai semnificative privesc comparaţia între algoritmii de flux

continuu cu şi fără ponderarea transmisiei, ce folosesc canale cu rată de transfer diferită. Din

analiza regimului static cît şi mai ales a celui dinamic rezultă că algoritmii cu ponderare

folosesc în măsură mai mare debitul existent şi că au capacitate superioară de adaptabilitate

dinamică la schimbările de debit de reţea.


36

Analiza regimului static

În cazul reţelei de 100 Mbps: datele prezentate în figura 5.6 arată că pentru două

canale (de 20 şi 10 Mbps) rata medie de transfer este cu 18.1% mai mare în cazul ponderării,

cu un maxim de +33.8% pentru 4 conexiuni concurente. Gradul de utilizare a debitului total

disponibil, de 30 Mbps, este în medie doar de 70.1% fără ponderare şi de 82.9% cu

ponderare.

Pentru trei canale (de 30, 20 şi 10 Mbps), datele prezentate în figura 5.7 arată ca rata

medie de transfer este cu 34.5% mai mare în cazul ponderării, cu un maxim de +66.9%

pentru 3 conexiuni paralele. De asemenea, gradul de utilizare a debitului total disponibil, de

60 Mbps, este în medie de 56.6% fără ponderare şi de 76.3% cu ponderare.

În cazul reţelei de 1 Gbps: datele prezentate în figura 5.8 arată că pentru două canale

(de 200 şi 100 Mbps) rata medie de transfer este cu 16.6% mai mare în cazul ponderării, cu

un maxim de +32.7% pentru 4 conexiuni concurente. Gradul de utilizare a debitului total

disponibil, de 300 Mbps , este în medie de doar 68.5% fără ponderare şi de 79.9% cu

ponderare.

Pentru trei canale (de 300, 200 şi 100 Mbps), datele prezentate în figura 5.9 arată că

rata medie de transfer este cu 31.8% mai mare în cazul ponderării, cu un maxim de +64.5%

pentru 6 conexiuni paralele. Totodată, gradul de utilizare a debitului total disponibil, de 600

Mbps, este în medie de 54.5% fără ponderare si de 71.8% cu ponderare.

În cazul reţelei de 8 Gbps: datele prezentate în figura 5.10 arată că pentru două

canale (de 2 şi 1 Gbps) rata medie de transfer este cu 19.4% mai mare în cazul ponderării, cu

un maxim de +39.1% pentru 8 conexiuni paralele. Gradul de utilizare a debitului total

disponibil, de 3 Gbps , este în medie de doar 70.3% fără ponderare şi de 84% cu ponderare.

Pentru trei canale (de 3, 2 şi 1 Gbps), datele prezentate în figura 5.11 arată că rata

medie de transfer este cu 27.2% mai mare în cazul ponderării, cu un maxim de +50.5%

pentru 18 conexiuni paralele. Totodată, gradul de utilizare a debitului total disponibil, de 6

Gbps, este în medie de 53.4% fără ponderare şi de 67.9% cu ponderare.

Din punct de vedere calitativ merită subliniat faptul că se poate observa o distincţie

clară între nivelul ratelor de transfer atinse de algoritmul cu ponderare faţă de cel fără

ponderare atunci cînd se ia în considerare distribuţia mai mult sau mai puţin favorabilă a

conexiunilor la canalele existente. În timp ce primul menţine o rată de transfer ridicată şi

aproximativ constantă (cu o tendinţă firească de creştere uşoară pentru mai multe conexiuni

simultane) cel din urmă este afectat vizibil de o distribuţie nefavorabilă, aşa cum se poate

remarca din alura ratei medii de transfer, în formă de dinţi de fierăstrău, aparentă în toate

cazurile experimentate în regim static.

Analiza regimului dinamic

În absenţa ponderării, rata de transfer rămîne aproximativ constantă: în jurul valorii de

20 Mbps în reţeaua de 100 Mbps, conform figurii 5.12; în jurul valorii de 200 Mbps în

reţeaua de 1 Gbps, conform figurii 5.13; şi în jurul valorii de 1.95 Gbps în reţeaua de 8 Gbps,

conform figurii 5.14.

Aceste valori corespund ratei medii de transfer a conexiunii celei mai lente

multiplicată cu numărul de conexiuni participante la transfer, în concordanţă cu prevederile

teoretice din formula (3.1) de mai înainte:

.

.

În contrast, algoritmul de transfer cu ponderare este sensibil la variaţiile debitului total

disponibil, de ±33% la fiecare 20 de secunde, observîndu-se, în mod corespunzător, două

nivele distincte ale ratei de transfer cu o scurtă perioadă de tranziţie de secunde:

în figura 5.12, pentru reţeaua de 100 Mbps, cele două nivele sunt unul de ~28 Mbps şi


37

celălalt de ~37 Mbps.

în figura 5.13, pentru reţeaua de 1 Gbps, cele două nivele sunt de aproape 300 Mbps

şi respectiv 400 Mbps.

în figura 5.14, pentru reţeaua de 8 Gbps, cele două nivele sunt de ~2.62 Gbps şi

respectiv ~3.48 Gbps, ambele reprezentînd din debitul total disponibil al canalelor

utilizate.

Aceste valori reprezintă o bună aproximaţie a sumei debitelor maxime ale canalelor

folosite pentru transfer, conform formulei (3.4) de mai sus.

5.5. SUMAR

Acest capitol a fost dedicat prezentării şi analizării unei serii de experimente care să

valideze arhitectura sistemului şi algoritmii de transfer cu viteză a datelor în reţea proiectaţi.

Astfel, metodologia adoptată s-a bazat pe folosirea unei aplicaţii de tip client-server

construită conform arhitecturii descrisă pe larg în capitolul 3 şi care implementează

principalii algoritmi de transfer (descrişi în capitolul 4) împreună cu o instrumentare comună

care a facilitat evaluarea lor comparativă.

Testarea a avut loc prin experimente desfăşurate în reţele reale, avînd o capacitate de

transmisie de 100 Mbps, 1 Gbps şi 8 Gbps, pentru a se putea verifica consistenţa algoritmilor

de transfer în condiţii cît mai variate cu putinţă.

Din compararea algoritmilor de streaming cu aceia de file striping, ambii executaţi în

paralel, cu multiple conexiuni TCP simultane, a rezultat că efectul constrîngerilor de

sincronizare a fluxului de date este nesemnificativ, astfel încît atît transferul datelor de

dimensiuni necunoscute cît şi al fişierelor se poate face la fel de bine numai prin streaming.

Aceasta reprezintă un avantaj, pus în evidenţă în cazul unor operaţii de salvare sau

sincronizare a directoarelor, efectuat cu viteză sporită prin tar/un-tar.

De asemenea, a fost verificat şi mecanismul ce permite efectuarea de transferuri de

date de tip split-TCP, rezultînd că propagarea datelor de-a lungul mai multor calculatoare cu

rol de releu de transmisie se face cu operaţii suplimentare neglijabile şi într-un mod recursiv,

alternîndu-se interconectările prin pipes locale cu acelea prin pipes extinse, iar rezultatele pot

fi remarcabile în privinţa vitezei de transfer atinse, faţă de aceea a unor căi directe dar mai

lente.

Suportul pentru transmisia pe căi multiple, de tip multi-path, a fost determinat printr-o

serie de experimente efectuate atît în regim static cît şi dinamic. A rezultat o bună

concordanţă cu estimările ratei de transfer globale prevăzută de modelul teoretic al cozilor de

tip fork-join, aflat la baza arhitecturii de sistem adoptate. De asemenea, răspunsul la variaţii

dinamice ale ratelor de transfer ale conexiunilor individuale a demonstrat corectitudinea

conceperii algoritmului de transmisie cu ponderare ca un sistem de control de tip PID.

6. CONCLUZII ŞI DIRECŢII DE CERCETARE VIITOARE

Prezenta teză tratează problema transferurilor de date în reţea, importantă în contextul

sistemelor de calcul de tip grid şi cloud computing. Este prezentat un model eficient de


38

transmisie a datelor cu viteză, folosindu-se multiple conexiuni TCP în paralel şi în acelaşi

timp generalizat şi simplificat prin utilizarea conceptului de pipes extinse.

Astfel, capitolul 2 al tezei este dedicat studierii stadiului actual al cunoaşterii în

domeniul transferurilor de date în reţea. Se prezintă cazul complex al proiectului Atlas pentru

a se ilustra necesitatea utilizării unor sisteme de transmisie care să facă faţă volumului imens

de date ce trebuie replicate între centre de cercetare ştiinţifică, în medii grid.

La baza transmisiei sigure a datelor în reţea se află protocolul TCP, analizat în

contextul modelului TCP/IP, sub aspectul performanţelor obţinute şi al justificării

întrebuinţării conexiunilor TCP simultane pentru mărirea ratei de transfer globale.

Se realizează de asemenea un studiu comparativ: al principalelor variante ale TCP

care vizează îmbunătăţirea algoritmilor săi de control al congestiei; al metodelor de

management activ al ruterelor din reţea; al unor protocoale non TCP care răspund mai bine

cerinţelor unor aplicaţii specializate; şi al clasei largi de aplicaţii şi biblioteci de funcţii de

transfer în reţea.

Au rezultat o serie de limitări ale soluţiilor existente, referitoare, între altele, la durata

mare a standardizării modificărilor de protocol, la dificultatea şi costul diseminării

protocoalelor noi, non TCP, dar şi avantaje, valorificate în prezenta teză, ca de exemplu

uşurinţa diseminării în cazul aplicaţiilor de transfer situate în afara nivelului de transport

(care este de obicei implementat în nucleul sistemului de operare).

Ca urmare, arhitectura sistemului adoptat, de transfer a datelor în reţea, este bazată pe

o aplicaţie de tip client-server, specializată în transmisia cu viteză sub formă de streaming în

paralel, la nivel de octet. Aşa cum se arată în capitolul 3, se obţine o rată de transfer

performantă prin utilizarea modelului de prelucrare paralelă al cozilor de tip fork-join,

sincronizate, ce permit prin ponderarea transmisiei şi suportul pentru multi-path la nivel de

aplicaţie.

Deoarece interfaţa aplicatiei cu sistemul de operare este de tip pipe, paradigma

programării cu pipes este generalizată de la nivelul local la acela al Internetului, în sens larg,

cumulîndu-se avantajul reutilizării comenzilor şi al aplicaţiilor de acces la sisteme de stocare

specializate cu transmisia cu o rată de transfer maximizată a datelor în reţea.

Viteza sporită de transfer, în modul streaming, a aplicaţiei se datorează conceperii

unor algoritmi de transmisie eficienţi, descrişi în capitolul 4. Aceştia realizează o sincronizare

eficientă a fluxurilor individuale atît în regim neponderat, cînd toate conexiunile TCP

paralele urmează căi identice, cît şi în regim ponderat, necesar pentru optimizarea ratei

globale a transmisiei de tip multi-path.

Algoritmul de transmisie ponderată este proiectat ca un sistem de control automat al

ratei de transfer globale, de tip proporţional şi integral, ceea ce asigură o rată maximă, în

condiţiile existenţei unei variaţii dinamice a lăţimii de bandă disponibile pentru conexiunile

TCP individuale (e.g. în centre de calcul moderne care au căi multiple între oricare dintre

nodurile din reţea).

Consistenţa şi eficienţa algoritmilor de transfer, cît şi flexibilitatea arhitecturii

adoptate au fost verificate printr-o serie de experimente de transfer a datelor desfăşurate în

cele mai variate platforme de test disponibile, avînd rate de transmisie maxime cuprinse între

100 Mbps, 1 Gbps şi 8 Gbps.

Din analiza rezultatelor experimentale, prezentată în capitolul 5, se poate determina că

suportul pentru multi-path este eficace atît în regim static cît şi dinamic, în bună concordanţă

cu estimările teoretice din secţiunea 3.4.1, iar regimul de streaming este la fel de rapid

precum cel de tip file striping, avînd în plus avantajul implementării modelului de transfer

prin pipes extinse în reţea.

6.1. CONTRIBUŢIILE TEZEI

Principalele contribuţii ale acestei teze sunt următoarele:


39

Un studiu comparativ al tehnicilor şi aplicaţiilor de transfer de date în reţea care a

analizat atît avantajele cît şi dezavantajele metodelor actuale de transmisie rapidă a datelor în

reţea, servind ca punct de plecare al prezentei cercetări în domeniu.

O arhitectură de sistem de transfer a datelor bazată pe conceptul îmbinării vitezei

sporite de transmisie în reţea, prin utilizarea de mai multe conexiuni TCP simultane, cu

generalizarea paradigmei de programare prin pipes extinse.

Un set de algoritmi eficienţi de transmisie a datelor în flux continuu (streaming) şi de

transfer a datelor pe căi diferite, avînd viteze individuale inegale (multi-path), care

optimizează rata globală de transport a datelor la nivel de aplicaţie.

O evaluare comprehensivă a consistenţei şi eficienţei algoritmilor de transfer în reţele

reale şi de test şi a validităţii arhitecturii de sistem adoptate.

O aplicaţie de transfer a datelor în reţea completă, care implementează arhitectura şi

algoritmii proiectaţi împreună cu o serie de caracteristici specifice modelului client-server,

importante în expoatarea în regim de producţie. De amintit faptul că, între alţii, institutul

Weizmann şi proiectul VIRGO folosesc în mod curent aplicaţia pentru transferul de date.

6.2. DISEMINAREA CERCETĂRII

Rezultatele cercetării din această teză au fost diseminate sub forma următoarelor

publicaţii şi rapoarte ştiinţifice:

1. D. Schrager, “Study of Techniques and Applications for Fast Data Transfers in

HBDP Networks,” in Proceedings of 12th International Symposium on Parallel and

Distributed Computing, ISPDC2013, Bucharest, Romania, Jun. 2013.

2. D. Schrager, “New Solutions for Fast Data Transfers in HBDP Networks,” UPB

Scientific Bulletin, Series C, Electrical Engineering and Computer Science, ISSN-L 2286 -

3540, 2013.

3. D. Schrager şi F. Rădulescu, “Efficient Algorithms for Fast Data Transfers Using

Long and Large Pipes in WAN Networks,” in Proceedings of 19th International Conference

on Control Systems and Computer Science, CSCS19, Bucharest, Romania, May 2013.

4. D. Schrager şi F. Rădulescu, “An Improved Application Level Multi-Path

Streaming Algorithm for HBDP Networks,” in Proceedings of 5th International Conference

on Computational Collective Intelligence Technologies and Applications, ICCCI2013,

Craiova, Romania, Sep. 2013.

5. The ATLAS DC1 Task Force, incl. D. Schrager, “ATLAS Data Challenge 1,”

Nov. 2003.

6. Incl. D. Schrager, “Full Supersymmetry Simulation for ATLAS in DC1,” ATL-

COM-PHYS-2003-0xx, Dec. 2003.

6.3. DIRECŢII DE CERCETARE VIITOARE

Studiul în acest domeniu poate fi extins şi cu alţi algoritmi de transfer care să asigure

o stabilitate şi eficienţă îmbunătăţită, în special în cazul suportului pentru multi-path.

De asemenea, o serie de automatizări, care să asigure o transparenţă mai mare pentru

utilizatori, ar putea fi adăugate aplicaţiei de transfer, de exemplu prin proiectarea unui modul

de control al căilor multiple din reţea care să realizeze şi o selecţie implicită a adreselor de IP

disponibile la sursa şi destinaţia transferului de date.

O altă posibilitate de cercetare o reprezintă validarea modelului de transfer a datelor şi

prin efectuarea de simulări, în reţele cu o topologie şi capacitate variabilă, în scopul unei mai

bune evaluări a performanţelor transmisiilor de tip split-TCP sau multi-path.


40

Continuarea cercetării din acestă teză va fi utilă pentru toate domeniile interesate de

transmiterea unor cantităţi de date masive, cu rapiditate şi uşurinţă, în condiţiile diversificării

şi dezvoltării continui a capacităţii reţelelor în viitor.

BIBLIOGRAFIE - SELECTIVĂ

[1] “ATLAS Experiment,” [Online]. Available: http://www.atlas.ch/.

[2] “VIRGO Detector,” [Online]. Available: https://wwwcascina.virgo.infn.it/.

[3] “GLIF Facility,” [Online]. Available: http://www.glif.is/.

[4] “OptIPuter,” [Online]. Available: http://www.optiputer.net/.

[5] J. Postel, Transmission Control Protocol, RFC 793, Sep. 1981.

[6] M. Mathis, J. Semke and J. Mahdavi, “The macroscopic behavior of the TCP congestion

avoidance algorithm,” Computer Communications Review, Jul. 1997.

[7] M. Mathis, J. Mahdavi, S. Floyd and A. Romanow, TCP Selective Acknowledgment,

RFC 2018, Oct. 1996.

[8] L. Brakmo and L. Peterson, “TCP Vegas: End to End Congestion Avoidance on a

Global Internet,” IEEE Journal on Selected Areas in Communications, vol. 13, no. 8,

Oct. 1995.

[9] S. Floyd, “HighSpeed TCP for Large Congestion Windows,” RFC 3649, Dec. 2003.

[10] C. Jin, D. Wei and S. Low, “FAST TCP: Motivation, Architecture, Algorithms,

Performance,” in Proceedings of IEEE Infocom, Hong Kong, Mar. 2004.

[11] J. Crowcroft and P. Oechslin, “Differentiated End-to-End Internet Services Using a

Weighted Proportional Fair Sharing TCP,” ACM SIGCOMM Computer Communication

Review, vol. 28, no. 3, pp. 53 - 69, Jul. 1998.

[12] A. Ford, C. Raiciu, M. Handley and O. Bonaventure, “TCP Extensions for Multipath

Operation with Multiple Addresses draft-ietf-mptcp-multiaddressed-09,” IETF draft,

Jun. 2012.

[13] S. Floyd and V. Jacobson, “Random Early Detection gateways for Congestion

Avoidance,” in IEEE/ACM Transactions on Networking, Aug. 1993.

[14] W. Feng, D. Kandlur, D. Saha and K. Shin, “BLUE: A New Class of Active Queue

Management Algorithms,” University of Michigan, CSE-TR-387-99, Apr. 1999.

[15] W.-c. Feng, D. D. Kandlur, D. Saha and K. G. Shin, “Stochastic Fair Blue: A Queue

Management Algorithm for Enforcing Fairness,” in INFOCOM, Apr. 2001.

[16] D. Katabi, “Decoupling Congestion Control and Bandwidth Allocation Policy with

Application to High Bandwidth-Delay Product Networks,” Massachusetts Institute of

Technology, PhD Thesis, Mar. 2003.


41

[17] A. Jungmaier, M. Schopp and M. Tuexen, “Performance Evaluation of the Stream

Control Transmission Protocol,” in 3rd International Conference on ATM (ICATM

2000), Heidelberg, Germany, Jun, 2000.

[18] E. Kohler, M. Handley and S. Floyd, “Designing DCCP: congestion control without

reliability,” in Proceedings of the 2006 conference on Applications, technologies,

architectures, and protocols for computer communications SIGCOMM '06, New York,

Oct. 2006. [19] E. He, J. Leigh, O. Yu and T. DeFanti, “Reliable Blast UDP : Predictable High

Performance Bulk Data Transfer,” in Proceedings of IEEE International Conference on

Cluster Computing, Beijing, China, 2002.

[20] Y. Gu and R. Grossman, “SABUL: A Transport Protocol for Grid Computing,” Journal

of Grid Computing, vol. 1, no. 4, pp. 377-386, 2003.

[21] M. Allman, S. Ostermann and H. Kruse, “Data Transfer Efficiency over Satellite

Circuits Using A Multi-Socket Extension to the File Transfer Protocol (FTP),” in

Proceedings of ACTS Results Conference, NASA Lewis Research, 1995.

[22] H. Sivakumar, S. Bailey and R. L. Grossman, “PSockets: The case for application-level

network striping for data intensive applications using high speed wide area networks,” in

Proceedings of IEEE/ACM SC2000 Conference, Dallas, TX, 2000.

[23] W. Allcock, J. Bresnahan, R. Kettimuthu, M. Link, C. Dumitrescu, I. Raicu and I.

Foster, “The Globus Striped GridFTP Framework and Server,” in SC 05: Proceedings of

the 2005 ACM/IEEE conference on Supercomputing, Seattle, WA, Nov. 2005.

[24] P. Rizk, C. Kiddle and R. Simmonds, “A GridFTP Overlay Network Service,” in

Proceedings of 7th IEEE/ACM International Conference on Grid Computing, Sep. 2006.

[25] T. V. Lakshman and U. Madhow, “The Performance of TCP/IP for Networks with High

Bandwidth-Delay Products and Random Loss,” IEEE/ACM Transactions on

Networking, vol. 5, no. 3, Jun. 1997.

[26] J. Mo, R. La, V. Anantharam and J. Walrand, “Analysis and Comparison of TCP Reno

and Vegas,” in Proceedings of INFOCOM ’99, Eighteenth Annual Joint Conference of

the IEEE Computer and Communications Societies, New York, NY, Mar. 1999.

[27] I. Foster and C. Kesselman, The Grid 2: Blueprint for a New Computing Infrastructure,

San Francisco, CA: Morgan Kaufmann Publishers Inc., 2003.

[28] I. Foster, “Globus Toolkit version 4: Software for service-oriented systems,” in

Proceedings of IFIP International Conference on Network and Parallel Computing,

Beijing, China, 2005.

[29] “PACMAN,” [Online]. Available:

http://www.globus.org/grid_software/packaging/pacman.php. [Accessed Aug. 2013].

[30] F. Luehring, Grid Computing for Atlas, Indiana University HEP Seminar, Mar. 2006.

[31] The ATLAS DC1 Task Force, incl. D. Schrager, “ATLAS Data Challenge 1,” Nov.

2003.

[32] Incl. D. Schrager, “Full Supersymmetry Simulation for ATLAS in DC1,” ATL-COM-

PHYS-2003-0xx, Dec. 2003.

[33] “File Transfer Service,” [Online]. Available: http://egee-jra1-dm.web.cern.ch/egee-jra1-

dm/FTS/. [Accessed Aug. 2013].

[34] “European Middleware Initiative,” [Online]. Available: http://www.eu-emi.eu/home.

[Accessed Aug. 2013].

[35] D. E. Comer, Internetworking with TCP/IP, Englewood Cliffs, NJ: Prentice Hall, 1991.


42

[36] H. Zimmermann, “OSI Reference Model - The ISO Model of Architecture for Open

Systems Interconnection,” IEEE Transactions on Communications, Vols. COM-28, no.

4, Apr. 1980.

[37] M. Allman, V. Paxon and W. Stevens, “TCP Congestion Control,” RFC 2581, Apr.

1999.

[38] T. J. Hacker, Improving End-to-End Reliable Transport Using Parallel Transmission

Control Protocol Sessions, PhD thesis, University of Michigan, 2004.

[39] S. J. Leffler, M. K. McKusick, M. J. Karels and J. S. Quarterman, The Design and

Implementation of the 4.3BSD UNIX Operating System, Reading, MA: Addison-

Wesley, 1989.

[40] V. Jacobson and R. Braden, “TCP Extensions for Long-Delay Paths,” RFC 1072, Oct.

1988.

[41] K. Fall and S. Floyd, “Simulation-based comparisons of Tahoe, Reno and SACK TCP,”

ACM SIGCOMM Computer Communication Review, vol. 26, no. 3, pp. 5-21, Jul. 1996.

[42] J. Xu, Performance evaluation of TCP over optical channels and heterogeneous

networks, Univ. of South Florida, MSc Thesis, Mar. 2004.

[43] S. Barre, Implementation and Assessment of Modern Host-based Multipath Solutions,

PhD Thesis, Louvain School of Engineering, Louvain-la-Neuve, Belgium, Oct. 2011.

[44] C. Raiciu, C. Paasch, S. Barre, A. Ford, M. Honda, F. Duchene, O. Bonaventure and M.

Handley, “How Hard Can It Be? Designing and Implementing a Deployable Multipath

TCP,” in Proceedings of USENIX Symposium of Networked Systems Design and

Implementation (NSDI’12), Apr. 2012.

[45] K. Ramakrishnan, S. Floyd and D. Black, “The Addition of Explicit Congestion

Notification (ECN) to IP,” RFC 3168, Sep. 2001.

[46] B. Bloom, “Space/time Trade-offs in Hash Coding with Allowable Errors,”

Communications of the ACM, vol. 13, no. 7, Jul. 1970.

[47] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M.

Kalla, L. Zhang and V. Paxson, Stream Control Transmission Protocol, RFC 2960, Oct.

2000.

[48] R. Stewart, Stream Control Transmission Protocol, RFC 4960, Sep. 2007.

[49] C. Caini, R. Firrincieli, M. Marchese, T. d. Cola, M. Luglio, C. Roseti, N. Celandroni

and F. Potorti, “Transport layer protocols and architectures for satellite networks,”

International Journal of Satellite Communications and Networking, vol. 25, no. 1, pp. 1-

26, 2007.

[50] J. R. Iyengar, P. Amer and R. Stewart, “Performance Implications of a Bounded Receive

Buffer In Concurrent Multipath Transfer,” Computer Communications, vol. 30, no. 4, p.

818–829, Feb. 2007.

[51] J. Iyengar, P. Amer and R. Stewart, “Concurrent Multipath Transfer Using SCTP

Multihoming Over Independent End-to-End Paths,” IEEE/ACM Transactions on

Networking, vol. 14, no. 5, p. 951–964, Oct. 2006.

[52] S. Floyd and E. Kohler, “Profile for Datagram Congestion Control Protocol (DCCP)

Congestion Control ID 2: TCP-like Congestion Control,” RFC 4341, Mar. 2006.

[53] S. Floyd, E. Kohler and J. Padhye, “Profile for Datagram Congestion Control Protocol

(DCCP) Congestion Control ID 3: TCP-Friendly Rate Control (TFRC),” RFC 4342,

Mar. 2006.


43

[54] J. Lai and E. Kohler, “A Congestion-Controlled Unreliable Datagram API,” [Online].

Available: http://www.read.cs.ucla.edu/dccp/nsdiabstract.pdf. [Accessed Aug. 2013].

[55] J. Postel and J. Reynolds, “FILE TRANSFER PROTOCOL (FTP),” RFC 959, Oct.

1985.

[56] V. Jacobson, R. Braden and D. Borman, “TCP Extensions for High Performance,” RFC

1323, May 1992.

[57] W. Allcock, J. Bester, J. Bresnahan, A. Chervenak, L. Liming and S. Tuecke, “GridFTP:

Protocol Extensions to FTP for the Grid,” Global Grid Forum Recommendation

Document GFD-R-P.020, 2005.

[58] M. Horowitz and S. Lunt, “FTP Security Extensions,” RFC 2228, Oct. 1997.

[59] P. Hethmon and R. Elz, “Feature negotiation mechanism for the File Transfer Protocol,”

RFC 2389, Aug. 1998.

[60] J. Schopf, M. DArcy, N. Miller, L. Pearlman and I. Kesselman, “Monitoring and

discovery in a webservices framework: Functionality and performance of the globus

toolkits mds4,” Globus, Tech. Rep. ANL/MCSP1248-04-5, 2005.

[61] “GSI-Enabled OpenSSH,” [Online]. Available: http://grid.ncsa.illinois.edu/ssh/.

[Accessed Aug 2013].

[62] L. Flatto and S. Hahn, “Two parallel queues created by arrivals with two demands,”

SIAM J. Appl. Math., vol. 44, no. 5, pp. 1041-1053, 1984.

[63] H. P. Anvin, “The mathematics of RAID-6,” 2011.

[64] O. J. Boxma, J. Koole and Z. Liu, “Queueing-theoretic solution methods for models of

parallel and distributed systems,” National Research Institute for Mathematics and

Computer Science, CWI, Amsterdam, Jul. 1994.

[65] “CASTOR,” [Online]. Available: http://castor.web.cern.ch/.

[66] D. Schrager, “rftar,” [Online]. Available:

http://castorold.web.cern.ch/castorold/DIST/CERN/savannah/CONTRIB.pkg/Dan.Schra

[email protected]/.

[67] LCG Grid Deployment Team, “rfcat,” [Online]. Available:

http://linux.die.net/man/1/rfcat.

[68] H. Orsila, “pmr,” [Online]. Available: http://zakalwe.fi/~shd/foss/pmr/.

[69] R. Braden, “Requirements for Internet Hosts -- Communication Layers,” RFC 1122,

Oct. 1989.

[70] M. Al-Fares, S. Radhakrishnan, B. Raghavan, N. Huang and A. Vahdat, “Hedera:

Dynamic flow scheduling for data center networks,” in USENIX Symposium on

Networked Systems Design and Implementation (NSDI), Apr. 2010.

[71] C. Raiciu, S. Barre, C. Pluntke, A. Greenhalgh, D.Wischik and M. Handley, “Improving

data center performance and robustness with multipath TCP,” in SIGCOMM, Toronto,

Canada, Aug. 2011.

[72] C. Hopps, “Analysis of an Equal-Cost Multi-Path Algorithm,” RFC 2992, Nov. 2000.

[73] R. Draves, “Default Address Selection for Internet Protocol version 6 (IPv6),” RFC

3484, Feb. 2003.

[74] K. J. Astrom and T. Hagglund, PID Controllers: Theory, Design, and Tuning, Instrument

Society of America, 1995.

[75] D. J. Cooper, “Practical Process Control: Proven Methods and Best Practices for

Automatic PID Control,” [Online]. Available: http://www.controlguru.com/. [Accessed

July 2013].


44

[76] J. Walrand, An Introduction to Queueing Networks, Englewood Cliffs: Prentice-Hall,

1988.

[77] D. Schrager, “bbftpPRO,” [Online]. Available: http://bbftppro.myftp.org/.

[78] “WIS,” [Online]. Available: http://www.weizmann.ac.il/particle/.

[79] “MWT2,” [Online]. Available: http://mwt2.usatlasfacility.org/.

TEZĂ DE DOCTORAT - acs.pub.roacs.pub.ro/system/files/REZUMAT_teza_doctorat_Dan_Schrager.pdf ·...

Documents

Transcript of TEZĂ DE DOCTORAT - acs.pub.roacs.pub.ro/system/files/REZUMAT_teza_doctorat_Dan_Schrager.pdf ·...