Hanna Germundsson, Karl-Johan Lundberg. hange595@student.liu.se, karlu823@student.liu.se

7&3IULHQGO\ %DNJUXQGGHILQLWLRQRFKWLOOlPSQLQJDUL WUDQVSRUWODJUHW Hanna Germundsson, Karl-Johan Lundberg hange595@student.liu.se, karlu823@student.liu.se TDTS09, Datornät och Internetprotokoll Linköpings universitet 22 februari 2008

6DPPDQIDWWQLQJ Denna rapport har syftet att förklara och definiera TCP-friendly, även beskriva olika transportlagerprotokoll där TCP-friendly ingår. Vi har försökt att ge en objektiv syn på hur olika lösningar av TCP-friendly kan inverka på dagens dataöverföring. För att få en bättre insyn i problem som uppstår och var namnet kommer ifrån har vi valt att skriva en bakgrund som innefattar grundfakta om de vanligaste transportlagerprotokollen TCP och UDP. Andra protokoll och congestion control-mekanismer som är nämnda i rapporten är DCCP (Datagram Congestion Control Protocol), ECN (Explicit Congestion Notification), TFRC (TCP-Friendly Rate Protocol) och TCP-like. All den fakta som vi har använt oss av har varit på engelska och därför har vi även skapat en ordlista för ord som inte har någon bra svensk översättning, eller av annan anledning kan vara bra att förklara.

,QQHKnOOVI UWHFNQLQJ,QOHGQLQJ 1.1 Rapportbakgrund...1 1.2 Syfte och problemformulering...1 1.3 Metod och avgränsningar...1,qohgdqghgho 2.1 Bakgrund och definition...2 2.2 Ordlista...2 2.3 TCP... 4 2.3.1 Congestion Control...5 2.4 UDP... 5 7&3)ULHQGO\ 3.3 DCCP...6 3.4 ECN...6 3.5 TFRC...7 3.6 TCP-like...8 5HVXOWDW $QDO\VDYUHVXOWDW 6OXWVDWVHU 5HIHUHQVHU

Civilingenjörsprogrammet Informationsteknologi Handledare: Juha Takkinen,QOHGQLQJ 5DSSRUWEDNJUXQG Denna rapport är skriven i kursen TDTS09, Datornät och Internetprotokoll 6 hp, andra terminen på Utbildningsprogrammet för informationsteknologi på Linköpings universitet. Handledare är Juha Takkinen. 6\IWHRFKSUREOHPIRUPXOHULQJ Vi blev tilldelade ämnet TCP-friendly med exempel på frågeställning TCP-friendly UDP application can implement congestion control algorithms on their own. Investigate the definition of the term TCP- Friendly [1]. Vi har ut i från ovanstående frågeställning valt att utgå från syftet: Att ta reda på vad TCP-friendly är. Problemformuleringen lyder: Till vad används TCP-friendly och hur fungerar det? Vad finns det för exempel på lösningar? 0HWRGRFKDYJUlQVQLQJDU Vi har valt att använda oss mycket av tidigare skrivna rapporter och avhandlingar som ligger på Internet då vi uppfattar TCP-friendly som ganska nytt och att det inte finns så mycket omskrivet i böcker än. Även vissa RFC-dokument har varit användbara. Vad det gäller avgränsningar har vi valt att skriva relativt ytligt för att läsare av rapporten hellre ska få en övergripande förståelse än en djupare insyn. 1

%DNJUXQGRFKGHILQLWLRQHU,QOHGQLQJ Idag används två transportprotokoll mer än andra och de är TCP (Transport Control Protocol) och UDP (User Datagram Protocol) [3]. TCP är pålitligt, dvs. det kontrollerar att paketen kommer fram och används mest vid filöverföring och webbläsning medan UDP är opålitligt men snabbare och mer lämpat för filmstreaming och spel (där det inte gör så mycket om enstaka paket försvinner). TCP har stöd för flödeskontroll (möjlighet för mottagaren att sakta ner flödet) och congestion control, dvs. TCP upptäcker när nätet är överbelastat och anpassar sig efter detta. UDP har ingen av de här egenskaperna och är därför för opålitligt för filöverföring (eftersom paket försvinner) och dessutom riskerar att överbelasta nätet. Att paket försvinner när man streamar film är inget stort problem eftersom den kvalitetsminskning som sker är liten. Ett större problem är att medan TCP delar bandbredden jämnt mellan användarna och omöjliggör congestion collapse av nätet tar UDP själviskt åt sig så mycket som möjligt. Många program som använder UDP har en inbyggd congestion control. Detta heter att man skapar en TCP-friendly -anslutning [1]. Men att införa endast ett tillägg hos UDP anser många är en otillräcklig lösning på problemet kring överbelastning av nätverk och forskare har utvecklat ett nytt protokoll, Datagram Congestion Control Protocol (DCCP), som är en kompromiss mellan UDP och TCP. Det är tänkt att ersätta UDP på områden där congestion control efterfrågas på bekostnad av snabbhet och ersätta TCP på områden där man inte behöver så stor tillförlitlighet. Då kan man göra anslutningen snabbare. Internet Engineering Task Force (IETF) har specifierat två olika Congestion Control Identifiers (CCID eller congestion control-mekanismer) för DCCP som heter TCP-like och TCP-Friendly Rate Control (TFRC) [2] och dessa förtydligas i respektive kapitel senare i rapporten. 2UGOLVWD &RQJHVWLRQ&RQWURO För att undvika förstockning i och överbelastning av nätet då paket skickas använder man sig av så kallad congestion control. Det är en algoritm som bestämmer flödet för efterkommande paket beroende på föregående pakets framkomlighet [1]. 6WUHDPLQJ Då viss media visas direkt från internet är det viktigt att paketen levereras i ordning och kommer i ett jämnt flöde. Detta flöde som ska användas direkt vid ankomst kallas streaming. 2

Civilingenjörsprogrammet Informationsteknologi Handledare: Juha Takkinen )ORZFRQWURO Genom att få informationen om hur mycket utrymme som finns kvar i mottagarens buffert finns det möjlighet för sändaren att anpassa antalet paket som skickas. Då överbelastas inte mottagarens buffert och paketen tappas inte. &RQJHVWLRQFROODSVH När det inte finns någon congestion control som avgör hur mycket trafik det blir finns det risk för överbelasning och inga eller väldigt få av de paket som skickas kommer fram. Detta kallas en congestion collapse [1]. $53$1(7 Detta är föregångaren till dagens internet. ARPANET utvecklades av ARPA (Advanced Research Projects Agency) i USA. De ville skapa ett nät när man kunde kommunicera mellan olika parter och skicka information utan möjlighet för avlyssning från otillåtna parter [3]. +XYXG Då ett paket skickas behöver detta adresseras för att det ska komma till rätt mottagare. Denna adress och mer information, bl a om vad det är för sorts data, finns i paketets huvud. Paketen har oftast ett huvud för varje lager bortsett från det fysiska. 5RXQGWULSWLPH577 Detta är den tid, mätt i sekunder, som det tar för ett paket att skickas till mottagare och ACK mottagas av ursprungliga sändaren. %DQGEUHGG Bandbredd är det maximala mängden data som kan skickas under en given tid. $&.YHNWRU En ACK-vektor är en lista över skickade pakets status, dvs. om de är mottagna (status 0), mottagna och ECN-märkta (status 1) eller ej mottagna (status 3). &KHFNVXP Kontrollsumma är något som används för att kunna kontrollera att all data som skickades har mottagits; inget har lagts till eller tappats. Denna beräknas lite olika beroende på vilket protokoll som används. 3

7&3 Dagens nätverkskommunikation bygger på TCP/IP-modellen, med dess olika protokollager. För att överföra data över internet används Internet Protocol (IP) och ett transportlagerprotokoll, där de nu två största heter UDP och TCP [3]. TCP används i de flesta sammanhang då det är viktigt att alla paket (delar med information) kommer fram till mottagaren. Detta är en pålitlig överföring mellan två värdar och används främst vid WWW, filöverföring och e-post (SMTP, IMAP och POP3) [1]. Paketen som skickas innehåller en viss mängd information (data) som ska till mottagaren. Men ett TCP-paket innehåller även information om vem som har skickat det, vart det ska, vad det är för information och om det är så att detta paket hör ihop med något annat [3]. TCP är förbindelseorienterad och behöver bekräftelse på att alla paket har kommit fram. Om ingen bekräftelse mottages inom en viss tidsram skickar TCP om paketet. Då TCP även har stöd för flow control och congestion control räknas det som ett pålitligt protokoll. Att TCP är förbindelseorienterad innebär även att det krävs en trehandskakning för att ansluta och en fyrstegshandskakning för att avsluta. Detta för att allt som händer ska bekräftas av mottagare och avsändare. Även detta är en del till TCP:s pålitlighet. Då paket skickas med TCP finns ingen garanti för att de kommer att skickas i ordning. All den information som ska skickas delas upp i segment för att datan ska passa in i den maxgräns som finns på data i varje paket. Dess paket numreras sedan med ett sekvensnummer för att de ska kunna sorteras när de kommit fram [3]. Som nämnts tidigare i detta kapitel så är det inte bara data som skickas i ett paket utan även information som bl.a. sändares och mottagares portnummer, sekvensnumret på paketet, ack nummer, längden på huvudet, etc. Denna information ligget i TCP-huvudet och är minst 20 byte stort. Här finns även det som är unikt för TCP: dess flaggfält. Det finns 6 olika flaggor: ACK, FIN, URG, PSH, RST och SYN. ACK är den vanligaste och står för acknowlegement (bekräftelse). Denna bekräftar till sändaren vilket data som mottagits. FIN stänger ner en uppkoppling. SYN synkroniserar sekvensnummer i början på en uppkoppling [5]. &RQJHVWLRQFRQWURO TCP har även en congestion control-mekanism som kallas AIMD (Additive Increase Multiplicative Decrease). AIMD har en egenskap att öka 4

Civilingenjörsprogrammet Informationsteknologi Handledare: Juha Takkinen sändningshastighet linjärt fram tills tredubbla ACKar inkommer, efter vilket hastigheten minskar multiplikativt. När man skapar en TCP-anslutning ökar sändningshastigheten exponentiellt tills man når en fördefinierad tröskel, då hastigheten ökar linjärt istället. Detta kallas att man gör en Slow start. Namnet kan verka missvisande, men det är en förhållandevis långsam start om man jämför med de första TCPversionerna, som tog åt sig så mycket bandbredd som möjligt i början.[4] )DLUQHVV Fairness betyder att då det finns en flaskhals vid överföringen ska bandbredden delas lika mellan de delande anslutningar. Så vid N st anslutningar delas bandbredden i delar om 1/N [5]. 8'3 När TCP utvecklades 1973 var det ihopbakat med IP, men man såg snart att det fanns en del nackdelar med detta. TCP var visserligen pålitligt, men inte särskilt snabbt. En av ARPANET:s huvuduppgifter var nämligen att överföra röstkommunikation i realtid. Lösningen blev att separera IP och TCP, och skapa ett protokoll som skulle vara snabbare på bekostnad av TCP:s congestion control. Det nya protokollet kom att heta User Datagram Protokoll [3a]. UDP är ett väldigt simpelt protokoll. Dess huvud är bara åtta byte och innehåller sändarens och mottagarens portnummer, storlek på datan och en checksum, som kollar så att paketet inte är skadat. UDP kan inte garantera att dess paket kommit fram, och har inget som helst stöd för congestion control. Man brukar säga att UDP är ett förbindelselöst protokoll; det skapar inte en anslutning utan börjar skicka data direkt tills den är klar. En stor skillnad mellan UDP och TCP är pålitlighet, vilket märks tydligt på hastigheten. UDP är mycket snabbare och detta på grund av att det inte har någon egen congestion control eller flow control [1]. 5

([HPSHOSnWLOOlPSQLQJDUDY7&3)ULHQGO\ I detta kapitel preciseras olika lösningar och implementeringar av TCP-friendly. Då transportlagerprotokoll håller på att utvecklas och främst med avseende på dess begränsningar har vi skrivit om vad som är på gång inom TCP-friendly. '&&3 Forskare håller på att utveckla ett protokoll vid namn DCCP (Datagram Congestion Control Protocol) med ungefär samma funktionalitet som UDP, fast med congestion control. Till skillnad från UDP genomför DCCP dock en pålitlig handskakning innan det börjar skicka, och motsvarande när det slutar [8]. Tre viktiga mekanismer i DCCP kommer att förtydligas i följande avsnitt. Dessa är: z z z ECN, vars huvuduppgift är att märka paket när nätet börjar bli överbelastat. TCP-like, som är en congestion control-mekanism som påminner mycket om den som finns i TCP. TFRC, en ekvationsbaserad congestion control-mekanism. DCCP är för närvarande under utveckling, men man satsar även mycket på att kunna vidareutveckla det efter att det har börjat användas. Det har, till skillnad från TCP, utvecklats från grunden och ska anpassas till congestion control-mekanismer redan från början för att få fram en uppskattad produkt [8]. (&1 ECN (Explicit Congestion Notification) är en påbyggnad för IP som tillåter transportlagerprotokollet att ta emot information från nätet om när nätet börjar bli överbelastat. Om det inte vore för ECN skulle TCP upptäcka detta först när paket börjat tappas. ECN är dock värdelöst om det inte implementeras i ett protokoll. Det enda transportlagerprotokollet som har det inbyggt är TCP [8]. Det finns flera olika algoritmer för att upptäcka överbelastning och en av dem är RED (Random Early Detection), som räknar ut sannolikheten för överbelastning. När två värdar kommer överens om att använda ECN kommer alla IP-paket märkas som ECN-kapabla. Om en router upptäcker att dess buffert börjar fyllas kommer den att märka alla passerande paket. Om routern redan är full kommer den att tappa paket i vanlig ordning. 6

Civilingenjörsprogrammet Informationsteknologi Handledare: Juha Takkinen När mottagaren får ett märkt paket kommer den att sätta en ECN-Echoflagga på motsvarande acknowledgment för att indikera för sändaren att överbelastning av nätet är på gång. När sändaren får denna ACK kommer den att justera fönsterstorleken och nästa datapaket som skickas kommer att vara en CWR (Congestion Window Reduced) -flagga. Denna lösning går mycket snabbare än utan ECN, eftersom det bara är några bitar i ett IPhuvud som behöver ändras istället för att sändaren måste skicka om en massa paket som i vanlig TCP [8]. 7)5& Problemet med AIMD (se avsnitt 2.3.1) är att det tar lång tid att komma upp i en hög sändningshastighet. Detta trotts att hastigheten ökar exponentiellt i början. TFRC är ekvationsbaserat och justerar sändningshastigheten utifrån tidigare paketförluster. Målet med TFRC är framför allt att skapa en jämn sändningshastighet genom att öka långsamt och halvera den först när paket tappats upprepade gånger [4]. När man upprättar en halvanslutning med TFRC har man möjlighet att inkludera ACK-vektorer, vilka möjliggör användandet av ECN. En halvanslutning är en del av en TCP-like-anslutning och förklaras närmare i nästa avsnitt. Denna upprättas genom att sändaren skickar en förfrågan och mottagaren svarar. Vid användning av ACK-vektorer skickar sändaren med en ECN-flagga i datapaketet, men till skillnad från TCP-like märks inte ACK:ar som ECN-kapabla. Minst en gång per RTT skickar sändaren en ACK som svar på mottagarens ACK-vektor. Samtidigt uppskattar sändaren den nya RTT:n och räknar ut en Time-Out-tid. Om sändaren inte får någon respons av mottagaren under denna tid halveras sändningshastigheten. Om ACK-vektorer inte inkluderas blir halvanslutningen opålitlig men snabbare [9]. Sändaren har en inbyggd klocka som avgör när paket ska skickas. Om en applikation vill skicka data så skickar TFRC först vid nästa klockpuls. Tiden mellan varje klockpuls beror på feedback från mottagaren [8]. 7

7&3OLNH TCP-like, eller CCID 2, liknar på många sätt den congestion controlmekanism som finns i TCP. Det finns dock ett antal viktiga skillnader. En TCP-like-anslutning består av två halvanslutningar mellan två värdar. Den ena halvanslutningen används av den ena värden till att skicka data och av den andra värden till att skicka ACK:ar och tvärtom [9]. När den ena värden skickar ett datapaket skickar den med en ECT(0)- eller ECT(1)-flagga, dvs. den talar om att paketet är ECN-kapabelt. När paketet är mottaget skickar mottagaren tillbaka en ACK och en ACK-vektor. Eftersom TCP-like gör congestion control på ACK:ar skickas även här en flagga som talar om att paketet är ECN-kapabelt. När sändaren tar emot ACK:en kollar den ACK-vektorn om det finns några borttappade paket och om mottagaren har uppdaterat sin fönsterstorlek. Sedan modifierar den ACK-vektorn efter om det finns förlorade eller märkta paket [9]. När sändaren har skickat paket motsvarande ett congestion window och fått alla ACK:ar av mottagaren skickar sändaren en ACK som även innehåller eventuella ACK:ar från den andra halvanslutningen. Nu gör sändaren en uppskattning av Round Trip Time och räknar ut ett time out-värde på liknande sätt som TCP gör. Ett paket betraktas som borttappat när tre paket med högre sekvensnummer har mottagits. TCP-like har en Slow start som liknar den i TCP. Den ökar dataflödet exponentiellt tills en given tröskel nås eller tills paket börjar tappas. Då blir ökningen linjär istället. När man tappar ett paket halveras flödet och blir det time out börjar Slow start-algoritmen om, dvs. flödet sätts till sitt lägsta värde och den exponentiella ökningen startar igen [9]. 8

Civilingenjörsprogrammet Informationsteknologi Handledare: Juha Takkinen 5HVXOWDW I detta avsnitt vill vi åter gå till vår problemformulering och redovisa det resultat som vi har fått fram av vår studie -Vad är TCP-friendly? TCP-friendly, som vi redovisar i avsnitt 3, består av egenskapen att ett transportlagerprotokoll inte tar över hela bandbredden då den skickar. Detta kan ske genom att man kompletterar ett redan befintligt protokoll, som UDP. Eller så kan det var ett helt nypåfunnet protokoll som exempelvis DCCP. I vår undersökning har vi insett att det hela tiden utvecklas nya protokoll som ska underlätta dataöverföring. -Vad används TCP-friendly till och hur fungerar det? TCP-friendly används för att underlätta dataöverföring och det resulterar i en motverkan av överbelastning genom congestion control algoritmer. Hur algoritmerna ser ut beror på applikation. -Vad finns det för exempel på lösningar? Det finns möjlighet att lägga till TCP-friendly-mekanismer i applikationslagret, men dessa är ofta för komplexa att implementera och testa. Lösningen på detta kan vara DCCP där TCP-like och TFRC för närvarande ingår. Dessa befinner sig i transportlagret vilket gör det enklare för användaren. $QDO\VDYUHVXOWDW Då alla källor som vi använt tyder på samma definition och användning av TCP-friendly känner vi att resultatet är pålitligt. Som vi konstaterat i resultatet är TCP-friendly något som utvecklas mycket och går att utveckla inom många olika plan. Anledningen till detta är att all dataöverföring är i stort behov av att det fungerar bra och effektivt för alla användare. 6OXWVDWVHU Om UDP innehöll en congestion control-mekanism skulle det lösa det rådande problemet med överbelastade nätverk som inte uppstår med TCP. Detta kan lösas i applikationslagret men det vore smidigare om det byggdes in redan i transportprotokollet. När DCCP blir klart, eller i alla fall tillräckligt klart för att börja användas storskaligt, kommer det med stor sannolikhet att ersätta UDP inom de flesta områden såsom filmstreaming och spel. UDP:s roll kommer på sin höjd bli för enklare uppgifter, som DNS-förfrågningar och dylikt. DNS (domain name system) översätter IPadresser till värdnamn. Vissa TCP-anslutningar kommer troligen att kunna ersättas med DCCP om man har implementerat TCP bara för att komma åt congestion controlmekanismen de fall där bara behövt congestion control och fått t ex pålitligheten som bieffekt. 9

DCCP är dessutom dynamiskt på två punkter: dels har det ett antal tillval där man bland annat kan implementera pålitlighet med hjälp av ACKvektorer och dels är det från början byggt för att lätt kunna vidareutvecklas. 10

Civilingenjörsprogrammet Informationsteknologi Handledare: Juha Takkinen 5HIHUHQVHU [1] Matthews, Jeanna (2005) Computer networking: Internet protocols in action, Wiley [2] Häggqvist, Björn (2005) High Quality Video Conferencing, http://epubl.ltu.se/1402-1617/2005/098/ltu-ex-05098-se.pdf, Luleå University of Technology Masteruppsats [3] Wikipedia, Engelsk http://sv.wikipedia.org/wiki/transmission_control_protocol, Hemsida [3a] Wikipedia, Engelsk http://en.wikipedia.org/wiki/arpanet Hemsida [4] Floyd, Sally; Handley, Mark; Padhye, Jitendra; Widmer, Jörg (2000) Equation Based Congestion Control for Unicast Applications, ACM Inc http://www.icir.org/tfrc/tcp-friendly.pdf, SIGCOMM 2000 Rapport [5] Towsley, Don (2001) TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581, http://www.cs.umd.edu/~shankar/417-f01/slides/chapter3b/sld028.htm Hemsida [6] Kurose, J.F Ross, K,W(2007), Computer networking, Addison Wesley Publishing Company [7] Kozierok, Charles M. (2006), UDP Overview, History and Standards, http://www.tcpipguide.com/free/t_udpoverviewhistoryandstandards.htm, The TCP/IP Guide [8] Mattsson, Nils-Erik (2004) A DCCP module for ns-2, http://epubl.ltu.se/1402-1617/2004/175/ltu-ex-04175-se.pdf, Luleå tekniska universitet Masteruppsats [9] Hultin, Fredrik (2007), Congestion notification and rate-adaption for real-time service in All-IP radio networks. http://epubl.ltu.se/1402-1617/2007/244/ltu-ex-07244-se.pdf, Rapport, Luleå tekniska universitet 11