VRP : un protocole avec une tolérance de perte ajustable pour des hautes performances sur réseau longue distance

HAL Id: inria-00000128

https://hal.inria.fr/inria-00000128

Submitted on 24 Jun 2005

HAL is a multi-disciplinary open access

archive for the deposit and dissemination of

sci-entific research documents, whether they are

pub-lished or not. The documents may come from

teaching and research institutions in France or

abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est

destinée au dépôt et à la diffusion de documents

scientifiques de niveau recherche, publiés ou non,

émanant des établissements d’enseignement et de

recherche français ou étrangers, des laboratoires

publics ou privés.

Alexandre Denis

To cite this version:

Alexandre Denis. VRP : un protocole avec une tolérance de perte ajustable pour des hautes

perfor-mances sur réseau longue distance. Actes des Rencontres francophones du parallélisme (RenPar 12),

Jun 2000, Besançon/France, pp.27-32. �inria-00000128�

VRP : un proto ole ave une toleran e de perte ajustable pour des hautes performan es sur reseau longue distan e

AlexandreDenis LIP,ENSLyon, 46alleed'Italie

69364LyonCedex07,Fran e.

Internet: Alexandre.Denisens-lyon.fr.

Resume

Lesappli ationsmultimediaontengeneralle hoixpourleurs ommuni ationsentreTCP,ablemais souvent trop lent, et UDP, rapide mais sans ontr^ole sur la abilite. Robin Kravets a propose une alternativebaseesurunetoleran edeperteajustable. Nousproposonsdans epapierdesameliorations duprin ipe,laspe i ationd'unproto oleappeleVRP,etuneimplementationauseindel'environnement demeta- omputing Globus. Notrebut est une augmentationdudebitsur leslongues distan esqui ont typiquementuntauxdeperteeleve.

Mots- les: proto olereseau,toleran edeperte,meta- omputing,reseaulongue distan e,TCP.

Motivations

L'emergen edumeta- omputingrelan el'inter^etpourles ommuni ationslonguedistan esurInternet. Dans l'environnement de meta- omputing Globus [4℄, les ommuni ations sont assurees parle module Nexus [3℄. Pourles ommuni ationssur Internet, Nexus aessentiellement le hoix entre TCP et UDP, touslesdeuxbasessurIP.Leproto oleTCP establemaisfaitpayersaabiliteauprixd'une ertaine lenteur.Leproto oleUDPproposeunservi evraimentminimal,sansau un ontr^olesurlaabilite.Les appli ations hoisissentengeneralTCP a ausedestropfaiblesservi esoertsparUDP.Cependantil existe desappli ations qui preferentun ompromisentre laabiliteet lavitesse.Le proto ole RTP [8℄ realiseun ompromisde egenre,maisest axeverslestransfertstempsreel.Ilsesou iedes ontraintes detempsplut^ot quedelaabilite.

L'obje tif quenous visonsest une ameliorationdes performan essurdes onnexionsInternetgrande distan e qui ont typiquement un tauxde perteelevequand le reseau est harge.La solution doit^etre adapteeauprin ipe\besteort"quiregneen oreenma^tresurInternet.Lanotiondeservi egarantiest en orepeupresentedanslemondeInternet etdemandedeplusdelourdesmodi ationsdes infrastru -turesexistantes,routeursenparti ulier.Nousnouspla onsdansle adredesystemesdemeta- omputing ommeGlobusquimettentl'a entsurlaportabiliteetl'utilisation dumaterielexistantsans modi a-tion.

Dans epapier,nousproposonsunproto oleappeleVRP,VariableReliabilityProto ol,implemente au-dessusd'UDP,don portablesurtouteslesma hinesd'Internet.Ilestimplementeenespa eutilisateur, iln'estdon pasne essairedemodierlesystemed'exploitation.Ceproto oleestissud'ideesemisespar Robin Kravetset al.dans[6℄.Notre ontributionest uneameliorationdesprin ipes,une spe i ation omplete du proto ole et une implementation au sein de l'environnement de meta- omputing Globus. Nous aborderons le prin ipe general de VRP dans une premiere partie. Nous examinerons ensuite les prin ipauxalgorithmesmisenuvre.Nousexposeronset ommenteronsennlesperforman esobtenues. 1. Prin ipegeneral de VRP

Toleran e de pertereglable

pro-glissantequi retransmetlespaquetsIP au asou ilsseraientperdus.SurInternet,lespertesdepaquets IP sontde deux types. Quand lesrouteurs n'ont pas letemps de traiter unpaquet, ils le suppriment. Celasetraduitpardespertesisolees.Quandlama hinequire oitestsaturee,ous'ilyaune ongestion dans un routeur, alors les pertes sont en rafales (burst ). Dans e as, de nombreux paquets su essifs sont perdus. Dans le as d'un reseau tres hargequi perd beau oup de paquets IP, le me anisme de retransmissionsystematiquede TCP est trespenalisant.Uneappli ation quitransmet parexempledes imagespreferesouventameliorerledebit(lenombred'imagesparse ondes),m^emesi e butest atteint au detriment de la qualite. Elle est pr^ete aa epter des pertes, qui se traduiront selon le as pardes lignesoudesimagesmanquantes.L'appli ationdoit ependantgarderunmoyende ontr^olesur espertes pourqu'elles restenttolerables. Le proto ole VRP met ala disposition de l'appli ationles parametres suivants:

{ letauxdepertemaximaltolerable,exprimesousformed'unpour entage.

{ la longueur maximale de perte onse utive, qui indique les plus grandes rafales autorisees. On ontr^oleainsilagranularitedespertes.Si onreprendl'exempled'uneappli ationquitransmetdes images, e parametrepermet de ma^triserle nombremaximal de lignes manquantes onse utives d'uneimageand'ee tueruneinterpolationpourretrouverdesdonneesmanquantes.

{ les donnees ritiques, qui sont des parties de messages qui ne peuvent ^etre perdues sous au un pretexte.C'est le as des en-t^etes ou d'autres donnees de ontr^ole,que l'on trouveau milieu de donnees qui peuvent ^etre perdues. Peu importe e que sont les autres parametres, les donnees marquees omme ritiquesn'ontpasledroitd'^etreperdues.Ceparametren'etaitpaspresentdans [6℄et aeteajoutepourqueleproto olesoit utilisable.

VRP garantitque les parametres fournis par l'appli ation sont respe tes.On remarquera que e sont desmaxima,lespertespeuvent^etreenpratiquebienmoindresque e quiestautorise.Ilestinteressant denoter quesil'on rel^a hetousles parametres(toutespertesautorisees),onretrouveles spe i ations duproto oleUDP. Si au ontraire tout est marque omme ritique ou sil'on pre ise untauxde perte maximalde0%,onretrouveTCP.

En apsulation

Aladieren edeTCP,notreproto olen'estpasbasesurun uxd'o tetsmaissurl'envoidemessages | desuniteslogiques de niveau appli ation | qui sontde oupesen paquets par leproto ole. Tout le ontr^oledelaabiliteestfaitauniveaude es paquets.Cependantl'appli ationn'ayantpasasavoir e quisepasseauniveauduproto ole|enparti ulier,ellen'apasa onna^trelatailledespaquets|,elle fournittoussesparametresindependammentdel'implementationduproto ole.Ainsi:

{ letauxdepertemaximaltolerableestdonneenpour entage,quiesttraduitennombredepaquets parfen^etre;

{ la taille maximaledeperte onse utiveest donneeen o tets,VRP traduit ennombrede paquets onse utifs;

{ lesdonnees ritiquessontdonneeseno tets,VRP se hargedetraduireenpaquets ritiques. Ces parametressontveriessur despaquets omplets.VRP est don plus restri tifque lesparametres donnes par l'utilisateur. Si par exemple une zone de donnees est marquee omme ritique au niveau appli ation,alors tous lespaquets qui en ontiennent une partie sont ritiques. On est ainsi assuredu respe tdesparametres.Dem^eme,l'algorithmeutiliseassureque ontr^olerletauxmaximaldepertesur lalargeurd'unefen^etreglissanteimpliqueque etauxest respe teglobalementsurlemessage omplet. Feedba k

Lorsqu'ilyadespertes,l'appli ationre eptri eestprevenuedeszonesdedonneesperdues.Ellepeut don hoisirdes'adapteren onsequen eettenterunere uperationpartielle,parexemplepar interpola-tions'ils'agitd'images.

Elle peut egalement hoisir de ne pas pr^eter attention aux pertes, et faire omme si tout avait ete re u.Eneet,ellere oitdesmessagesquiontexa tementlam^emetailleque equiaeteenvoye,quelles que soientles pertes.Les zones perduessont simplement omblees ave des zeros. Lemessage est re u virtuellementsansperte. Onseramenedans e asaune toleran ed'erreursalapla ed'unetoleran e

de dupli ation. L'ordrede re eptiondes messagesn'estpas onserve; les messagespeuvent sedoubler. Onmet enpla edes me anismes qui ontr^olentqu'au un messagen'estduplique.Au un messagen'est normalement perdu. Dans le as ou on n'arrive pas a joindre le re epteur, l'appli ationemettri e est prevenuequelemessagen'estpasarriveadestination.Onfournitegalementles hiresdespertesreelles 

al'appli ationemettri epourqu'ellepuisseeventuellements'adapteraux onditionsdetra .

2. Algorithmesmisen uvre

2.1. Fen^etreglissanteettoleran e de perte

Leproto oleVRP sebasesurunme anismedefen^etreglissantealamanieredeTCP [1℄.L'emetteur envoielespaquetsdansl'ordreetattendlesa usesdere eption(notesACKdanslasuite).Ces a quitte-mentssont umulatifs, 'est-a-direqu'ilsinformentdelare eptiond'unpaquetetdetouslespaquetsqui lepre edent.Pour haquepaquettransmis,l'emetteurde len heuntemporisateur.S'ilarriveaexpiration avantlare eption del'a quittement, onsuppose quele paquet aeteperdu. Dans e as, onre-emetle paquet orrespondant.Dupointdevuedel'emetteur,latransmissionestdon per ue ommeable.

Latoleran edeperteestgereedu ^otedure epteur.Lorsqu'ildete teunpaquetmanquant,lere epteur examinel'historiquedesdernierespertes.Il ontr^olesilaperteestpermiseparlesparametresfournispar l'appli ation.Silaperteestautorisee,ilenvoieuna quittementexa tement ommesilepaquetavaitete re u.

2.2. NACK, SACKet anti ipation

Le me anisme presente i-dessus est orre t, mais peut ^etre optimise. Pour ameliorer la vitesse de rea tion aux pertes, on ajoute un systeme d'a quittements negatifs (notes NACK) emis des que le re epteurdete teuneperte.



Aleurre eption,l'emetteurre-emetimmediatementlepaquet orrespondant. Au vu dunombre de paquets retransmisinutilement, il aegalementsemblene essaire d'ajouterdes a quittementsindividuelspourlespaquets,enplusdesa quittements umulatifs,semblablesauxSACK introduits dans TCP [7℄. Ces a quittementssele tifs permettent d'a quitter tousles paquets re us qui suiventunpaquetperdu. L'utilisation onjointe desSACKet desNACKest don tout-a-faitnaturelle. Ellepermetunere uperationdeperteplusrapideetevitelestransmissionsinutiles.

Notre but est d'avoirlemoins deruptures possibledans le ux. Si unpaquet est perdu alorsqu'un NACKesten ours (ie.unNACKaeteenvoye,lepaquet orrespondantn'apasen oreetere u),il est possiblede ne pas rester bloque. Il suÆt d'anti iper e qui va sepasser. Comme lemontre lagure 1 (enhaut),uneappro heraisonnableestd'attendrequetoutrentredansl'ordreavantd'analyserlaperte suivante.Cependant,onpeutimagineruns enario omme eluidelagure1(enbas)oul'onasimplement anti ipel'arriveedupaquetnumero4.Puisquelapertedupaquetnumero4n'apaseteautoriseeetqu'un NACK aete envoye,alors e paquet arrivera ne essairement. Ce paquet etant virtuellement arrive, le re epteur peut ontinuer a traiter la suite en onnaissan e de ause, et autoriser la perte du paquet

1

2

3

4

5

6

7

8

9

10

reçu

ACK

NACK

5

8

9

SACK

ACK standard

Exemple avec SACK et anticipation

3

4

ACK

reçu

1

2

6

7

NACK

Exemple sans SACK ni anticipation

10

✘

✘

✘

✔

✔

✔

✘

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✔

✘

numero6.Ilenvoiedon des a quittementssele tifsSACK(notes

✘

2.3. Transmissiond'un message

Dans un environnement de meta- omputing, la toleran e aux pannes est un aspe t essentiel. C'est pourquoinousproposonsqueVRP soitunproto olenon- onne te, 'est-a-diresansetat.



Aladieren e de TCP, si par exemple le re epteur oupe la liaison puis la retablit, l'emetteur n'a pas besoin de reinitialiser la liaison. Bien s^ur, pendant la transmission d'un message, une onnexion existe. Il peut m^emeyavoirplusieurs onnexions simultaneessiplusieursmessagessonttransmissimultanement.

Le proto ole propose dans [6℄ est onne te, simplement pour disposer d'un ordre sequentiel sur les messages.Cettemethodepermetdegerer orre tementlandesmessages.

Nousadoptons une solutiondierente,plusrobuste.Quand ilre oituna quittementpourle dernier paquet d'un message, l'emetteur est s^ur que le message omplet aetere u. Il detruit alors toutes les stru tures destinees a l'envoi du message. Le re epteur ne peut pas agir de maniere symetrique. Si l'a quittement du dernier paquet se perd, l'emetteur ne serait jamais prevenu que le message a ete re u.Lere epteurattend don quel'emetteurluisignale qu'ilabien re ulederniera quittementpour luiaussidetruirelesstru tures orrespondantes.

Cettenoti ationdesu esdetransmission,lesordresd'initialisationdemessage,lesspe i ationsdes parametresde toleran edeperte et les a quittements sonttransmis dans despaquets de ontr^ole.Ces paquets de ontr^ole ontune stru turemodulaireet exible abase de balises.Leur stru tureexa te est de ritedans[2℄.Lere epteura quittelespaquetsde ontr^ole qu'ilre oitdel'emetteur,onestdon s^ur qu'ilsarrivent.Par ontredansl'autre sens, espaquets negenerentpasd'a quittement(enparti ulier, on n'a quitte pas les ACK!) Pour gerer le as dudernier message, et pour ameliorer la toleran e aux pannes,lere epteurmesurelesperiodesd'ina tivite,quisetraduisentparl'absen edere eptiond'ACK denumerodesequen esuperieuraudernierACKre u.En asd'ina tivitetroplongue,il onsidereque la onnexionaeterompuepouruneraisonquel onque|problememateriel, rash, ongestionseveredu reseau,et . |et il notiel'appli ationquele messagen'a pasetetransmisave su es.Un me anisme symetrique estmisenpla e du ^otedure epteur.

2.4. Reglages Temporisation

Le hoix de la temporisation est determinant pourdiminuer le temps de rea tion auxpertes.  Etant donnequeletempsquis'e ouleentrel'envoid'unpaquetetlare eptiondel'a quittement orrespondant est tres variable, il est ne essaire d'utiliser un algorithme adaptatif. Plut^ot que de se lan er dans le developpement d'un nouvel algorithme, on se base sur la methode lassique de Ja obson [5℄ utilisee dansTCP.

Onappro heletempsd'aller-retourmoyenal'aided'unltrepasse-basdutypeR TT =
R TT+(1 )
M ouR TT estl'approximationdutemps d'aller-retour,M estletemps d'aller-retourmesure,et  estunparametredelissage.Onappro hel'e artmoyenparD=
D+(1 )
jR TT Mj.On hoisit alorstimeout=R TT+4D.Lefa teur4peutsemblerarbitraire:ilaetedetermineexperimentalement pourque seulement 1% desexpirations de temporisateur orrespondent ades paquets qui ne sont pas perdus.Commelemontrelagure2,letimeout hoisisuitletempsd'aller-retourdetrespres.Ilyapeu d'expirationspourrien,maisondete tetrest^otlespaquetsperdus.

Taille de fen^etre

La taille de lafen^etrerepresentele nombre maximumde paquets non-a quittes a haqueinstant, et in ue sur lesperforman es duproto ole. Ilest essentiel d'avoirune fen^etre suÆsamment large surdes reseauxdetypesWANoulalaten eesttypiquementelevee.L'emetteurrisqueeneetdepassersontemps 

aattendrelesa quittements.Sielleesttropgrande,l'in onvenientmajeurestledebordementdestampons dure epteurqui entra^nedenombreusespertesenrafales. Deplus, pourdes raisonsd'implementation, enombredoit^etreunepuissan eexa tede2.

Desmesuressurdierentesliaisons,ave desma hinestresdierentes(PC,SunUltraSpar ,SGIOrigin 2000),etave des onditionsdetra dierentes ontmontreque eparametren'avaitpasunein uen e

50000

100000

150000

200000

250000

300000

350000

400000

450000

500000

0

500

1000

1500

2000

2500

3000

microsecondes

numero de paquet

timeout

RTT moyen

RTT mesure

Fig.2:Exemple d'evolutiondutimeout

0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

2048

4096

6144

8192

10240

12288

14336

16384

debit (Mbit/s)

taille des paquets (octets)

LAN

WAN

Fig.3:Ledebitenfon tiondelatailledespaquets

paquets parfen^etre,onnote uneaugmentationdutauxdeperte.Nous hoisissonsune taillepardefaut de64, et leproto olelaisse tout dem^emelapossibiliteal'utilisateurd'imposerune autre valeurs'ille desire.Iln'apassemblene essairedemettre enpla e unetaillevariableave unalgorithmeadaptatif.

Taille des paquets

TrouverlabonnetailledepaquetestdiÆ ile.Ilfautseposerlabonnequestion:qu'est- equelabonne tailledepaquet?Est- e ellequiobtientledebitlepluseleveou ellequiminimiselespertes?Lagure 3montrelesresultatsd'unben hmarkrealisesurLANetsurWAN.Ilest lairquesurleWAN,labonne taille est 2ko.Surd'autresexemples,lemeilleur resultatest obtenu pour1ko.Au-delade es valeurs, lespertesaugmententenormement.Pourrester ompetitif surLAN,nous hoisissonsunetaille de 2ko pardefaut.L'utilisateurpeutfor ersaproprevaleurpouruneutilisationspe ique.

Pourunedes riptionte hniqueplus ompleteduproto oleVRP,ainsiqu'unaper udel'implementation quienaetefaitedansGlobus,onsepourrasereferera[2℄.

3. Performan es

Nous nous interessons prin ipalement aux performan es sur les longues distan es. Les mesures de performan essontdiÆ iles arealiser ar les onditionssontextr^emement variables. Nousdonnons des hires qui representent des moyennes. La liaison Internet entre Chi ago et Los Angeles nous sert de referen e,enutilisantl'implementationquiaetefaitedansGlobus.Noustransmettonsdesmessagesde

mesureeestd'environ10%.Nousatteignonsundebitmoyende1,2Mbit/save TCP etenviron6Mbit/s ave VRP,soitunrapportde5.M^emedans lepire des asobserves,VRP esten ore2foisplusrapide queTCP.Destestsrealisessuruneliaisontransatlantiquemettenteneviden eunrapportd'a eleration de 3 de VRP par rapport aTCP. Surun reseau lo al, omme prevu,VRP n'est pas plus rapideque TCP.Ilestm^emelegerementpluslent,ave undebitinferieurde5%a eluideTCP.

Nousexpliquonsladieren edeperforman eparunestrategie ompletementdierentepourle ontr^ole de uxetle ontr^olede ongestion.Le ontr^olede uxdeTCP estpre iset omplexe.Il her heaevitera toutprixtoutdebordementdetampon.Le ontr^olede uxdeVRPestmoinsstri t.Ilexploitelefaitqu'un paquetperdudetempsaautreesta eptable.Le ontr^olede ongestiondeTCP estpessimiste.Ilralentit 

alamoindrealerte.Iln'yapasdevrai ontr^olede ongestiondansVRP.En asde ongestiondureseau, le tauxde perte augmente et l'appli ation est prevenue. Libre aelle de s'adapter. M^eme sans ontr^ole de ongestion,VRP n'aggravepasles ongestions: s'il est ne essaired'ee tuer desretransmissionsde paquets,plusles retransmissions sontnombreuses, plusletemporisateuraugmente.VRP ralentit don delui-m^eme.

4. Con lusion

Nous avons dans e papier proposedes ameliorations pour le proto ole VRP an de le rendre uti-lisable en pratique. Nous avons de plus fournides spe i ationsa unniveau d'abstra tion assezhaut, de maniere a e que les appli ations l'utilisent sans se sou ier de l'implementation. Nous avons de rit et justie les me anismes utilises pour l'implementer. VRP est maintenant plus tolerant aux pannes. Pourl'implementation dans Globus, nous l'avonsegalementrendu ompatible ave lesenvironnements multi-threads.

Les resultatssonten ourageantset a lahauteur de nosesperan es.VRP aete on upour la trans-mission de gros volumes de donnees sur de longues distan es. Quand on l'utilise dans es onditions, les performan es sontex ellentes. Les problemesde ongestion semblent ^etre le seul point deli at.Les premierstestsn'indiquentpasdeproblemeparti ulier.Nousn'avons ependantpasrealisedetestatres grandee helle,ave denombreuses onnexionssimultanees.Ilest possibledefaireevoluerVRP versun proto oleadaptatifquiresoudrait esdiÆ ultes:l'appli ationspe ieunintervallepourletauxdeperte maximaltolerable,le proto ole hoisitlui-m^emelemeilleurpointdefon tionnementdans et intervalle suivantles onditionsdetra .

Leproto oleVRP que nousavonspresenteest une alternativeauxsolutionsbasees surla qualitede servi e. Il peut utiliser les infrastru tures existantes, 'est la son prin ipal atout. Son implementation dansGlobusautorisemaintenantlatransmissiondedonneesmultimediademanieresatisfaisantedansle adredumeta omputing.

Bibliographie

1. David D. Clark. Window and a knowledgement strategy inTCP. Internet requestfor omment 813, july 1982.

2. Alexandre Denis. Variable Reliability Proto ol : A proto ol with a tunable loss tole-ran e for high performan e over a WAN. Te hni al report, LIP, ENS Lyon, mars 2000. ftp ://ftp.ens-lyon.fr/pub/LIP/Rapp orts /RR/ RR200 0/RR 2000- 11.p s.Z.

3. IanFoster,JonathanGeisler,CarlKesselman,andStevenTue ke. Managingmultiple ommuni ationmethods inhigh-performan enetworked omputingsystems.JournalofParallelandDistributedComputing,40(1):35{ 48,1997.

4. TheGlobusproje t. http://www.globus.org/.

5. VanJa obson. Congestionavoidan eand ontrol. InSymposiumpro eedingsonCommuni ationsar hite tures andproto ols,pages314{329,Stanford,CA,august1988.

6. Robin Kravets,Ken Calvert, P. Krishnan, and KarstenS hwan. Adaptivevariation ofreliability. In Pro- eedings of the Seventh IFIP Conferen e on High Performan e Networking (HPN'97). Georgia Instituteof Te hnology,april1997.

7. M. Mathis,J.Mahdavi,S.Floyd,and A.Romanow. TCP Sele tiveA knowledgmentOptions. Request for omment2018,o tober1996.