DÃ©partement RÃ©seau, SÃ©curitÃ© et MultimÃ©dia Rapport d'ActivitÃ©s 2008

More documents

Recommendations

Info

Loss Synchronization and Router Buffer Sizing with High-SpeedVersions of TCPResearch Staff : David Ros – Ph.D. Student : Sofiane HassayounKeywords : TCP, congestion control, high-speed networksApplications : high-speed networks, Grid networkingIntroductionThe Transmission Control Protocol (TCP) [1-2]is the most widely used transport protocol inIP networks. Indeed, many measurementstudies show that more than 90% of theInternet traffic is carried by TCP. TCP is theprotocol of choice of most data applications(web, e-mail, file transfer, …), and it is evenused for multimedia applications like audio andvideo streaming.In order to react to packet losses, TCPperforms congestion control; that is, a TCPsender cuts its data sending rate (at least) byhalf whenever it detects that packets are lost.The goal of this rate-control mechanism is tohelp in alleviating network congestion (which isimplicitly assumed as being the cause ofpacket loss). In the absence of losses, thesender steadily increases its rate: the goal inthis case is to use as much availablebandwidth as possible.In very high-speed networks, drastic ratereductions—which are inherent of thecongestion control mechanisms—often result inpoor performance. This is because TCPsenders cannot fully utilize the link capacityand, moreover, after a loss is detected theymay take a long time before reaching again ahigh sending rate.In recent years, a good deal of research workhas thus been devoted to studying andimproving the performance of TCP over veryhigh-speed links. Several variants of theprotocol have been proposed in order to adaptTCP’s congestion control mechanisms to Gb/sspeeds and beyond.RealizationDrop synchronization between TCP flowshappens whenever two or more flowsexperience packet loss in a short time interval.Such phenomenon has been the object ofseveral studies and proposals because of itspotential performance implications. Indeed,perfectly-synchronized losses among flowswould result in TCP senders reducing theirwindow in unison; hence, in poor throughputand low link utilization. In practice, however,such highly-correlated loss patterns are rarelyobserved in the Internet. Factors likefluctuations in round-trip times (RTTs) andhigh levels of statistical multiplexing tend tobreak the synchronization among flows.Nonetheless, given that previous studies onsynchronization have focused on “low-speed”TCP, one may wonder whether packet dropsmay become more correlated when high-speedvariants of TCP are used. Indeed, it has beenconjectured [3] that a higher synchronizationmight be a side effect of the increasedaggressiveness of the congestion controlalgorithms in those variants.We have thus performed a preliminary study ofthe relation between drop synchronization andbuffer sizes, when high-speed TCPs are used.By means of ns-2 simulations, the dependenceof synchronization on the TCP version wasexplored. We used finely-tuned simulationscenarios, designed to avoid synchronizationas much as possible; the idea was to capturedrop correlations induced mainly by theversion of TCP in use.One of our main motivations for looking intothis problem was that, contrary to the commoncase in the general Internet, Grid networks areprone to synchronization. Moreover, the factthat such networks are prime candidates fordeploying high-speed versions of TCP, makesthe subject of the study yet more compelling.We evaluated three high-speed protocols:HSTCP, H-TCP and BIC (the latter has beenadopted in the standard Linux kernel); SACKTCP was used as a sort of “low-speedbenchmark”. In order to assess the impact ofthe bottleneck buffer size, we explored a widerange of buffers, going from very small ones(50 packets) to very large ones (150,000packets).The figure below shows the CDF (cumulativedistribution function) of the so-called global8 Extract of Pracom’s Annual Report 2008
synchronization rate R, measuring theproportion of flows that experience packetdrops in a loss event. The figure compares thebehavior of HSTCP with that of SACK, when alarge buffer is used. Similar trends wereobtained with the other two high-speedprotocols. In the simulations, 40 flows arecompeting for bandwidth in the bottleneck; forinstance, R = 1/40 (i.e., the lowest value of Rin the curves) corresponds to one flowsuffering packet drops in a loss event.ConclusionOur preliminary findings suggest that highspeedversions of TCP do yield higher levels ofsynchronization. However, in spite of a strongcorrelation of packet drops among flows, wefound that such TCP versions can achieve bothhigh goodput and link utilization, as long asenough buffering is provided.References[1] D. Ros. TCP : performance et évolution duprotocole (in French). In: Techniques del'Ingénieur, vol. TEA3, no. TE7572, 2006.[2] D. Ros. TCP : impact des caractéristiquesdes liaisons (in French). In: Techniques del'Ingénieur, vol. TEA3, no. TE7573, 2007.Curves in this figure are to be interpreted asfollows: a CDF value of y corresponds to theprobability that at most x = R*100% of theflows lose packets in every loss event. Hence,a high value of CDF for a low value of R meansthat drops are not strongly correlated betweenflows (i.e., in many cases, just a few flows losepackets in a loss event). Note that this is thecase of SACK TCP, since in ≈ 40% of the lossevents there is only one flow (R = 1/40) thatloses packets.[3] S. Floyd and E. Kohler (eds.). “Tools forthe evaluation of simulation and testbedscenarios,” Internet Draft draft-irtf-tmrg-tools,work in progress, February 2008. Available at:http://tools.ietf.org/html/draft-irtf-tmrg-tools[4] S. Hassayoun and D. Ros. LossSynchronization and Router Buffer Sizing withHigh-Speed Versions of TCP. In Proceedings ofthe IEEE INFOCOM High-Speed NetworksWorkshop (HSN 2008), Phoenix (AZ), USA,April 2008.Conversely, a low CDF value for a high valueof R implies a strong drop synchronizationbetween different flows—that is, in most casesmany flows suffer “simultaneous” loses. Thiscorresponds to the case of HSTCP, becauseonly ≈ 10% of the loss events concerned lessthan 60% (R = 0.6) of the flows; in otherwords, in ≈ 90% of the cases more than 60%of the flows experienced packet loss in a shorttime interval.This work [4] earned the Best Paper Award ofthe HSN 2008 Workshop of the IEEE INFOCOMconference.Pracom’s Annual Report 2008 9
Page 2 and 3: Présentation générale...........
Page 4 and 5: Activités d’enseignementLe dépa
Page 6 and 7: Activités de rechercheLe départem
Page 8 and 9: Notre implication dans les organism
Page 10 and 11: le cadre du projet NextTV4all où l
Page 12 and 13: cloisonnement par domaine tels qu
Page 14 and 15: - le GIS ITS (Intelligent Transport
Page 16 and 17: Twente aux Pays Bas, Université de
Page 18 and 19: Liste des doctorants présents en 2
Page 20 and 21: Annexe 2 : liste des publicationsAr
Page 22 and 23: COMA-BREBEL Céline, CUPPENS Nora,
Page 24 and 25: PHAN LE Cam Tu, CUPPENS Frédéric,
Page 26 and 27: Annexe 3 : description détaillée
Page 28 and 29: Access Control ....................
Page 30 and 31: schemes specifically suitable for l
Page 32 and 33: An easy-to-use solution for IPv6 co
Page 36 and 37: Sensor NetworksRandom Walk Techniqu
Page 38 and 39: Suppressing Neighbor Discovery in W
Page 40 and 41: Media and NetworksIP-based transmis
Page 42 and 43: One of the most difficult aspects o
Page 44 and 45: Another direction is the associatio
Page 46 and 47: classes. In our simple study case,
Page 48 and 49: Management of Multiple Access Netwo
Page 50 and 51: Adaptation of Multimedia Flows in a
Page 52 and 53: Optimized mobility management in he
Page 54 and 55: ecause it offers a generic framewor
Page 56 and 57: Future workOur next step is to fina
Page 58 and 59: Security Analysis and ValidationAna
Page 60 and 61: RealizationFigure 1 shows a classif
Page 62 and 63: Policy AdministrationResearch Staff
Page 64 and 65: execution in a distributed manner.
Page 66 and 67: Intrusion DetectionDetection and co
Page 68 and 69: eported alerts have to be managed b
Page 70 and 71: inside the corresponding detection
Page 72 and 73: function has a limitation that it d
Page 74 and 75: 1) Normal Node behavior simulation:
Page 76 and 77: negotiation. These strategies speci
Page 78 and 79: A Fast Adaptative Secure Technology
Page 80 and 81: estricted to the organization to wh
Page 82 and 83: ights and external identities, and
Page 84 and 85:
Peer 2 peerP2PIm@gesResearch Staff
Page 86 and 87:
Managing a Peer-to-Peer Storage Sys
Page 88 and 89:
Applications of networks to transpo
Page 90 and 91:
Adaptive Application Support in Mob
Page 92 and 93:
Wireless Mesh NetworksResearch Staf
Page 94 and 95:
TestbedsA showroom for practical IP
Page 96 and 97:
egistrar and proxies, video streami
show all

DÃ©partement RÃ©seau, SÃ©curitÃ© et MultimÃ©dia Rapport d'ActivitÃ©s 2008

Create successful ePaper yourself

Delete template?

Save as template?