3-4. Transmission Control Protocol

Minőségbiztosítás IP hálózatokon (vitt9181) 3-4. Transmission Control Protocol Kis, Szabolcs Máté, kisszm@tmit.bme.hu TÁVKÖZLÉSI ÉS MÉDIAINFORMATIKAI TANSZÉK BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM 2005. szeptember 20-23. 1 1 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. keddpéntek

Transmission Control Protocol, TCP» Provides a connection-oriented byte stream service: two applications must establish a TCP connection prior to data exchange» Broadcasting and multicasting are not applicable to TCP» Provides end-to-end reliable data delivery» Implements Flow Control algorithms» TCP data is encapsulated in an IP datagram» The unit of information passed by TCP to IP is called a segment» TCP uses logical connections between pair of processes:» TCP segments contain a source and a destination port number» The combination of an IP address and the corresponding TCP port number is called socket or transport address of the connection» socket pair : 4-tuple identifying the connection 2 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. A TCP szerepe: -a kapcsolat létrehozása -Az ablakméret, az adatméret egyeztetése -Adat küldése, fogadása -Csomag nyugtázása -Kapcsolat bontása A TCP kapcsolatorientált-kétirányú kapcsolat. Stream típusú, ami kb folyamatos kapcsolatot feltételez. Ha esetleg nem lenne elküldendő adat, akkor is szukseg lehet (opcionalis), csupán a kapcsolat fenntartása miatt is küldeni egy-egy csomagot. Két pont közötti kommunikációért felelős (pontosabban két alkalmazás). Végez adatfolyam menedzselést is. Az IP csomagokat datagramnak, a TCP csomagokat segmentnek hívják, de ez csak elnevezésbeli különbség. (a tuple kb annyit tesz, mint a byte.) A technológia nem tartalmazza a broadcasting és multicasting lehetőségeket. Mivel tartalmaz egy handshaking típusú szinkronizációt, ezért se tehetnénk meg a rendszerrel, hogy egy lassú szereplő miatt várjon mindenki, ezzel is megbénítva az egész kommunikációt. 2 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. keddpéntek

Transmission Control Protocol (TCP)» TCP exchange segments with the other end to do the following:» Establish a connection» Advertise window size, maximum segment size» Transfer data» Send acknowledgements for received data segments» Close connection 3 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 3 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. keddpéntek

TCP Packet Structure 32 bits (4 Bytes) Source Port Destination Port H Reserved LEN (6 bits) Sequence Number Acknowledgement Number Checksum Flags (6 bits) Window Urgent Pointer Options Padding DATA 4 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. Header Length: ez a mező adja meg, hogy a fejléc hányszor 32 bites információt tartalmaz. Window: Az ablakméretet tartalmazza, azaz azt a mennyiséget, amit az adó a küldés pillanatában ismer. Dinamikus, a kommunikációra vonatkozó adat. Megadja, hogy egyszerre hány nyugtázatlan byte (figyelem, nem csomag!) lehet az éterben. Az Options mezőt itt már nyugodtan használhatnánk, ugyanis a továbbító routerek nem néznek bele az IP csomagba, így a mező feldolgozására már lenne erőforrás. Azonban itt (sem?) szokás. Source port (16 bits): This is the TCP port number of the sending device. Destination port (16 bits): This is the TCP port number of the receiving device. Sequence number (32 bits): This is the sequence number of the data byte stream in the segment. Acknowledgement number (32 bits): This is the sequence number that the receiver expects to receive next. Offset (4 bits): This is the number of 32-bit words in the TCP header. It is needed because the Options field length is variable. Reserved (6 bits): Reserved for future use. It must be zero. Flags (6 bits): These are six flags that control the behaviour of a TCP packet. They are: 1. Urgent (URG) 2. Acknowledgement (ACK) 3. Push (PSH) 4. Reset connection (RST) 5. Synchronous (SYN) 6. Finish (FIN). Window (16 bits): This is used in acknowledgement segments to implement flow control. It specifies the number of data bytes the receiver has buffer for. Checksum (16 bits): This is used to verify the integrity of the TCP header. The checksum is performed on a pseudo header consisting of information obtained from the IP as well as the TCP header. Urgent Pointer (16 bits): When urgent data is being sent (as specified in the code bits), this points to the end of the urgent data in the segment. Options: The most common option field is the maximum segment size (MSS) option. 4 Minőségbiztosítás It specifies IP hálózatokon the maximum (vitt9181), sized segment A Transmission that the Control sender Protocol wants to (3-4.) receive. 2005. szeptember 20-23. keddpéntek

TCP packet structure (expl.)» Source port (16 bits): This is the TCP port number of the sending device.» Destination port (16 bits): This is the TCP port number of the receiving device.» Sequence number (32 bits): This is the sequence number of the data byte stream in the segment.» Acknowledgement number (32 bits): This is the sequence number that the receiver expects to receive next.» Header Length (4 bits): This is the number of 32-bit words in the TCP header. It is needed because the Options field length is variable.» Reserved (6 bits): Reserved for future use. It must be zero.» Flags (6 bits): These are six flags that control the behaviour of a TCP packet. They are: 1. Urgent (URG) 2. Acknowledgement (ACK) 3. Push (PSH) 4. Reset connection (RST) 5. Synchronous (SYN) 6. Finish (FIN).» Window (16 bits): This is used in acknowledgement segments to implement flow control. It specifies the number of data bytes the receiver has buffer for.» Checksum (16 bits): This is used to verify the integrity of the TCP header. The checksum is performed on a pseudo header consisting of information obtained from the IP as well as the TCP header.» Urgent Pointer (16 bits): When urgent data is being sent (as specified in the code bits), this points to the end of the urgent data in the segment.» Options: The most common option field is the maximum segment size (MSS) option. It specifies the maximum sized segment that the sender wants to receive. 5 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. A sequence number biztosítja az adatfolyam folyamatosságát, illetve sorrendhelyes összeállítását. Acknowledgement number: Egy helyesen érkezett, már elfogadott csomag Sequence numberét küldi vissza a feladónak, jelezve ezzel, hogy a vétel nyugtázott, küldhet újabb csomagot. Pontosabban a TCP egy un. Előremutató nyugtázást használ, azaz a Ack. Number nem az elfogadott csomag SN-e, hanem annál egyel nagyobb érték. 5 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. keddpéntek

TCP flags» Urgent flag (URG)» This flag allows one end to tell the other end that urgent data exists in the data stream» Acknowledgement flag (ACK)» It tells the other end that the acknowledgement number in the segment is valid» Push flag (PSH)» The segment contain data which the receiver should pass to the application» Reset flag (RST)» A reset segment is sent by TCP when a connection request to a nonexistent port arrived or when one end is willing to abort the connection» Synchronous flag (SYN)» The SYN flag is set in segments part of the three-way handshake (connection set-up)» Finish flag (FIN)» The communicating ends set this flag when want to close a connection 6 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. A Flags mező értéke a csomagról árul el bizonyos információt: Az egyes bitek a következő információkat tartalmazhatják: -Fontos csomag -A csomag nyugta információt (is) tartalmaz -A csomag adatot tartalmaz, így azt megkaphatja egy alkalmazás, nem kell a TCP rétegnek feldolgoznia -Kapcsolatot reset-elni kell -SYN: kapcsolat felépítésénél van szerepe -Finishflag: a kapcsolat bontásánál van szerepe. Egy kapcsolatot, ha valaki kezdeményezte bontani KELL, ez fontos, mert erőforrásokat foglal, amiket fel kell szabadítani. 6 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. keddpéntek

TCP» provides a full duplex service to the appl. layer» data can be flowing in each direction» each end must maintain a sequence number» no selective ACK» ack number : successfully received up to but not including that byte» no negative ACK» no interpretation of the byte stream» up to the applications 7 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. A kapcsolat full duplex, azaz kétirányú. Minden résztvevőnek felelőssége, hogy életben tartsák a kapcsolatot. Nincs szelektív nyugtázás, azaz valami vagy jól érkezett meg, vagy rosszul. Ha rosszul, akkor az egész csomagot újra kell küldeni. Nincs negatív nyugta. Ha a csomag nem jó, egyszerűen nem küld nyugtát, az felel meg a negatív nyugtázásnak. 7 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. keddpéntek

Well-known Port Numbers Port Number 7 20 21 23 25 53 79 80 104 139 160-223 Description Echo File transfer protocol (FTP) data connection File transfer protocol (FTP)control connection Telnet Simple mail transfer protocol (SMTP) Domain name server (DNS) Finger World wide web (WWW) X400 Mail Sending NetBIOS session service Reserved 8 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. Every TCP segment contains the source and destination port number to identify the sending and receiving application. TCP combines static and dynamic port binding, using a set of well known port assignments for commonly invoked programs (for example electronic mail), but leaving most port numbers available for the operating system to allocate as programs need them. Although the standard originally reserved port numbers less than 256 for use as well known ports, numbers over 1024 have now been assigned. The diagram lists some of the currently assigned TCP ports. 8 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. keddpéntek

TCP connection establishment and termination TÁVKÖZLÉSI ÉS MÉDIAINFORMATIKAI TANSZÉK BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM 2005. szeptember 20-23. 9 9 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. keddpéntek

Connection establishment protocol 1. The requesting end (normally called the client) sends a SYN segment specifying the port number of the server that the client wants to connect to, and the client s initial sequence number, ISN. 2. The server responds with its own SYN segment containing the server s ISN. The server also acknowledges the client SYN by ACKing the client s ISN plus one. (A SYN consumes one sequence number) 3. The client must acknowledge the SYN from the server by ACKing the server s ISN plus 1 10 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. Amennyiben a címzett hoston a címzett port nem létezik, akkor lesz szerepe a RESET bitnek. 10 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Establishing a TCP Connection the three-way handshake Client SYN SEQ # 1,000 Window 8,760 bytes Max segment 1,460 bytes SYN SEQ # 3,000 ACK # 1,001 Window 8,760 bytes Max segment 1,460 bytes Server TCP very sensitive to SYN packet losses long timeouts. SYN segments consume one sequence number. ACK # 3001 ACK 11 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. A kapcsolat felépítésénél a kliens már megad egy kívánt szegmens- és ablakméretet. A szerver a válaszüzenetben hasonlóan jár el. Ezek a méretek nem feltétlenül egyeznek meg. Amennyiben a kívánt méret nem felel meg, abban az esetben nem küld ACK üzenetet mindaddig, míg megfelelő értékeket nem kap. To establish a connection TCP uses a three-way handshake. The client s TCP software generates a sequence number (1,000 in this example). The client requests a session by sending out a segment with the synchronisation (SYN) flag set to on. The segment header also includes the sequence number, the size of its receive buffer (advertised window size) and the size of the biggest data segment it can handle. The side that sends the first SYN is said to perform an active open. The server acknowledges (ACK) the request by sending back a segment with the synchronisation (SYN) flag set to on. The segment header contains the server s own start-up sequence number and the acknowledgement for the previous SYN segment it received from the client. The segment header also includes the size of the server s receive buffer (window size) and the size of the biggest data segment it can handle. The client sends back an acknowledgement of the server s start-up sequence segment. This is the third and last segment from the three-way handshake. The purpose in these sequence numbers is to prevent packets that get delayed in the network from being delivered later and then misinterpreted as part of an existing connection. 11 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Connection termination protocol» four segments to terminate a connection» each direction shut down independently» receiving a FIN» TCP must notify the appl. that the other end has terminated that direction» TCP can still send data after receiving a FIN 12 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. A kapcsolat befejezésénél mindkét félnek zárnia kell a kapcsolatot. A megállapodáshoz FLAG-eket használnak. 12 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Closing a TCP Connection Client FIN SEQ # 775 ACK# 500 Server ACK # 776 FIN SEQ # 500 ACK # 776 ACK#501 13 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. Egy-egy file letöltésére egy-egy TCP kapcsolatot használnak. Pl.: egy honlap letöltése képenként külön kapcsolatot igényel. (min. default 2 kapcsolat-win) Egy kapcsolat lezárása az alábbiak szerint működik: While it takes three segments to establish a connection, it takes four to terminate a connection. This is caused by TCP s half close. Since a TCP connection is full-duplex, each direction must be shut down independently. The rule is that either end can send a FIN when it is done sending data. When a TCP receives a FIN, it must notify the application that the other end has terminated that direction of data flow. The sending of a FIN is normally the result of the application issuing a close. The receipt of a FIN only means that there will be no more data flowing in that direction. A TCP can still send data after receiving a FIN (the other direction is still active). While it is possible for an application to take advantage of this half-close, in practice very few TCP applications use it. The end that first issues the close (sends the first FIN) performs the active close and the other end (that receives the FIN) performs the passive close. When one end receives the FIN it sends back an ACK of the received sequence number plus one. A FIN consumes a sequence number, just like a SYN. 13 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Maximum Segment Size, MSS» largest chunk of data that TCP will send to the other end» each end announce the MSS it expects to receive» MSS option in SYN segment» if no MSS option, default 536 byte» MSS up to the outgoing interface s MTU minus the fixed TCP and IP headers 14 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. MSS: Maximális Szegmens Méret, azaz, hogy mennyi lehet maximálisan a hasznos adat mérete egy csomagban. MTU: Maximal Transfer Unit: azaz a maximális átvihető csomag mérete (fejléccel együtt) 14 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

MSS values host 1 host 2 MTU=296 MTU=296 MTU=1500 MTU=1500 SYN <mss 1460> SYN <mss 296> 15 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. A fenti ábra példa egy aszinkron erőforrás foglalásra, ahol a baloldali host nem ugyanakkora sávszélességet (tud, vagy akar) lefoglalni, mint a jobboldali, vagy csak mas csomagmeretekkel dolgozik. 15 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Path MTU discovery» after a conn. est. TCP uses the minimum of the outgoing interface s MTU and MSS announced by the other end as the starting segment size» IP datagrams sent by the TCP have DF bit set» If fragmentation required ICMP DF set, can t fragment message sent back» TCP decreases the segment size and retransmits» newer ICMP contains next hop MTU» older ICMP does not contain, next smallest MTU must be tried» larger value of MTU can also be tried (~10 minutes) 16 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. A TCP csomagokat az IP nem tördelheti, így ha az IP egy TCP csomagot szállít, akkor a DF (Don t fragment) bitje be lesz billentve, ezzel jelezve, hogy ha egy olyan routerhez érne, amely így nem tudja továbbítani, akkor az sem szedheti szét kisebb részekre, hanem egy ICMP (Internet Controll Message Protokoll) üzenetben jelzi a feladónak, hogy elakadt a csomagja, és a csomagot eldobja. A feladó, ekkor megpróbál(hat)ja a csomagot az ezen routernek megfelelő méretben továbbítani (darabolás TCP szinten), hátha így átjut a hálózaton. Végül a hálózat legszűkebb keresztmetszetének megfelelő méretre fogja darabolni a csomagot és így fogja átjuttatni a címzettnek. Később megpróbálhatja növelni ezt a méretet. 16 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

TCP interactive data flow TÁVKÖZLÉSI ÉS MÉDIAINFORMATIKAI TANSZÉK BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM 2005. szeptember 20-23. 17 17 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Studies of TCP traffic» packet count basis» half of all TCP segments contain bulk (ftp, e-mail) data» other half is interactive (telnet) data» byte-count basis» 90% bulk data» 10% interactive data 18 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. A telnet NEM BIZOTOS, HOGY JÓ PÉLDA! Mindenesetre Interaktiv kapcsolatoknal jellemzoen kis csomagmeret a jellemző(pl minden karakter külön utazik), míg letöltéseknél nagyméretű csomagok fordulnak elő. A hostoknál lévő implementáció különbözhet Ez már egy szabályozási rendszer kapcsolat szabályozás. 18 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Interactive data (rlogin)» normally, segment 2 and 3 are combined data server ackof data echo of data ackof echoed data 19 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. Telnet, SSH, esetén például Elképzelhető, hogy csak a védett hálózaton belülre SSH-zunk, onnan tovább telnetezünk. Visszhangként visszajátsza az üzeneteket. A TCP-ben ezt a megoldást használják az ellenőrző összeg hiánya miatt. 19 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Delayed ACK (Fig. 19.3)» TCP does not send an ACK the instant it receives data» Instead it delays the ACK, hoping to have data going in the same direction as the ACK, so the ACK can be sent along with the data. ACK piggyback with the data» 200 ms timer for delaying ACK s, TCP will delay an ACK up to 200ms 20 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. A TCP timeout-ja tipikusan 200 ms, eddig vár az ACK üzenetre. Ha ezalatt nem érkezne be, akkor azt negatív nyugtának értékeli. Ha később küldi a vevő a nyugtát, akkor a küldő is csak később küldheti el a saját üzenetét, ezzel szabályozzák együtt a folyamatot. Azaz a vevő is fel tudja tartani az adó oldalt. (piggyback: nyugta a válasz üzenetben) 20 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Nagle algorithm» 1 byte data : 41 byte IP datagram (tinygram)» can add congestion on wide area networks» Nagle algorithm» when a TCP connection has outstanding data that has not yet been ACKed, small segments can not be sent until the outstanding data is ACKed» instead, small amounts of data are collected by TCP and sent in a single segment when the ACK arrives 21 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 1 byte (karakter) elküldése is 41 byteos csomagot eredményez az overheaddel együtt. (TCP fejléc, ) Amennyiben kisebb csomagot küldenénk, megvárjuk, míg a korábban elküldött nagyobb csomag nyugtája megérkezik, ugyanis a kisebb csomag megelőzhetné a nagyobbat. Ez különösen pl.: egy bontási csomag elküldésekor lenne kínos. 21 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

TCP bulk data flow TÁVKÖZLÉSI ÉS MÉDIAINFORMATIKAI TANSZÉK BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM 2005. szeptember 20-23. 22 22 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Sliding window» stop and wait protocol (NOT TCP!!!)» the sender of a data block required an ACK for that block before the next block was sent» sliding window» it allows the sender to transmit multiple segments before it stops and waits for an ACK» faster data transfer 23 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. Stop andwait protocol: Nagyon nagy holtidőt jelentene. Sliding window: Kb 20 (imoplementacio és beállításfüggő) csomag lehet egyszerre, nyugtázatlanul a hálón Slow start: ld.: később. 23 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Example (Fig. 20.1)» sender transmits three data segments (4-6)» segment 7 acks the first two data segments only» 4,5,6 arrive and are placed onto IP input queue» TCP processes segment 4, marked to generate delayed ACK» TCP processes the next segment (5), ACK of 2049 generated because having two outstanding segments» TCP processes the next input segment (6), again marked to generate delayed ACK» before segment 9 arrives the delayed ACK timer goes off, ACK of 3073 (segment 8) sent» segment 8, win 3072» there are still 1024 bytes of data in the TCP receive buffer that the application has not read 24 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 24 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Example (Fig 20.3), fast sender, slow receiver» sender, four back-to-back segments (4-7)» receiver, Ack 4097, win 0!!» all segments are still in the TCP receive buffer» application has no chance to read out TCP buffer» Another ACK, win 4096» window update» TCP receive buffer is emptied by the application 25 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 25 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Sliding window (Fig 20.4, 20.5, 20.6)» window advertised by the receiver offered window» bytes acked up to 3 and the advertised win size 6» usable window : which bytes can be sent immediately 26 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. Csúszó ablak Offered window: felajánlott ablak Advertised window: hirdetett ablakméret 26 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Key points (Fig. 20.6)» The sender does not have to transmit a full window s worth of data» One segment from the receiver acknowledges data and slides the window to the right. This is because the window size is relative to the acknowledged sequence number.» The size of the window can decrease (segment 7, segment 8)» The receiver does not have to wait for the window to fill before sending an ACK. Many implementations send an ACK for every two segments that are received. 27 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 27 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Window size» Results for two WS on an Ethernet with varying the transmit and receive buffer sizes» The common default of 4096 bytes is not optimal» With size of 16384 bytes 40% increase in throughput» Minimum buffer size?» bandwidth of the communication media» round trip time between the two ends 28 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. Jó-e a nagy buffer? Igaz, hogy nem vesznek el a csomagok, mert bekerülhetnek a nagyobb bufferbe, de jelentősen megnő a RTT (Round Trip Time), ami pedig egy fontos szempont a minőségbiztosítás szempontjából. Ha nagy default ablakméretet állítunk be, akkor mindenki mohó lesz, és a kapcsolatban vergődés alakulhat ki. A megoldás az lenne, ha dinamikusan tudnánk optimalizálni a kommunikációt. 28 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Slow Start» Previous examples» sender starts of by injecting multiple packets up to the advertised window size» OK when the two hosts are on the same LAN» If there are routers and slower links between the sender and the receiver, problems can arise. Some intermediate router must queue the packets, and it is possible for that router to run out space and be forced to drop packets causing performance degradation.» TCP is required to support an algorithm called Slow Start 29 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. Folyamatosan növeli a kiküldött csomagok számát, úgy, hogy minden beérkező ACK üzenet hatására két csomagot továbbít, mindaddig, míg el nem éri a maximális ablak méretet. Egy hálózaton belül nagyon jó módszer. 29 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Slow Start (2)» TCP could send at once as much data as much the window permits.» Bursty traffic can fill the intermediate routers queue, they may drop segments, thus reducing end to end TCP performance.» Slow Start algorithm avoids this by defining a congestion window (cwnd) over the window size allocated for a connection.» When a new connection is established the congestion window is initialised to one segment. The sender is allowed to transmit only one segment.» Each time an ACK is received, cwnd is increased by one segment (cwnd is maintained in bytes, but slow start always increments it by the segment size).» The sender can transmit at once min(cwnd, advertised window).» The maximum value of cwnd is the advertised window.» cwnd allows an exponential growth of the transmission speed» At some point the available bandwidth of the network will be reached and an intermediate router will start discarding packets. 30 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. Annyit küldhet, amennyit az ablak megenged. A burst a router memóriáját tölti, tehát drága + megoldandó probléma a hőtermelés ugyanitt Akkor is létrejöhet, ha új TCP kapcsolat lép be Meg kell egyezniük a sávszél elosztásában. 30 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

The exponential increase» Sender transmits one segment and waits for its ACK» When that ACK is received, the cwnd is incremented from one to two, and two segments can be sent» When each of those two segments is acked, the cwnd is increased to four.» Approximately, during every RTT the cwnd is doubled 31 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 31 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Example of Slow Start (Fig 20.8) TÁVKÖZLÉSI ÉS MÉDIAINFORMATIKAI TANSZÉK BUDAPESTI MŰSZAKI ÉS GAZDASÁGTUDOMÁNYI EGYETEM 2005. szeptember 20-23. 32 32 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Bulk Data Throughput (Fig 20.9, 20.10)» time 0 : sender transmits one segment. Because of slowstart it must wait for the ACK.» RTT : 8 units of time» when the ACK received two more segments can be sent (cwnd=2)» From time 31 the pipe between the sender and the receiver is full.» each unit of time a segment is removed by the receiver and another segment is placed into the network by the sender.» ideal steady state of the connection 33 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 33 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Bandwidth-Delay Product» How big should the window be?» In our example the sender needs to have eight segments outstanding and unacknowledged at any time for maximum throughput» The receiver s advertised window must be that large» Capacity of the pipe = = Bandwidth Round-Trip Time (bandwidth-delay product) 34 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 34 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

TCP timeout and retransmission» TCP manages a retransmission timer when expecting an ACK from the other end» TCP segments and ACKs can get lost in the network» due to congestion at intermediate routers» If an ACK is not received during the timeout interval, the segment is retransmitted and cwnd is set to 1» TCP measures (estimates) the Round Trip Time (RTT) for a connection (time duration between sending a segment and receiving an ACK for it) for calculating the retransmission timeout» slow start follows the retransmission due to timeout 35 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. A TCP garantálja, hogy a feladott csomag megérkezzen a címzetthez. Ha a timeout lejártáig nem érkezne nyugta, akkor a kérdéses csomagot újraküldi. Működés közben folyamatosan mérjük a Round Trip Time-ot. Ez azért fontos, hogy annak megváltozása esetén se várjunk fölöslegesen a nyugtára. 35 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

RTT and RTO calculations» RTT αrtt+(1-α)m» α is a smoothing factor ( 0.9)» M is the new measurement value» RTO = RTT β» β : delay variance factor, recommended value is 2» problem : can not keep up with wide fluctuations of the delay» Jacobson recommended to keep track the variance in the RTT measurements (with integer arithmetic) 36 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. RTT: Round Trip Time (csuszóátlag számítás) RTO: Retransmission TimeOut Baj lenne, ha nagyon nagy ingadozás lenne a rendszerben. Az alfa és béta beállításai az optimalizált forgalomnak megfelelőek. A timeout értékét határozzák meg újraküldéshez. 36 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Retransmission due to timeout Send Packet 1 Start Timeout Timer Sender Timer for Packet 1 Receiver Packet lost Packet should arrive ACK should be sent ACK would normally arrive at this time Timer Expires Reset Timer Retransmit Packet 1 Receive Ack Reset Timer and send next packet Receive Packet 1 Ack for Packet 1 is sent 37 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. Pl.: ha eldobnak egy csomagot ( vagy elvész ). (a nyugta is elveszhet, de az kisebb méretű, így kisebb valószínűséggel veszne el útközben.) A fenti példa azt mutatja, hogy viselkedne a TCP-vel kommnunikáló két folyamat, ha a csomag időközben elveszne. (Hasonló lenne a modell ACK vesztés esetén is) 37 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Another retransmission example (Fig 21.7)» segment 45 lost» the reception of segment 62 forces retransmission» this is the third duplicate ACK with 6657» Implementation count the number of duplicate ACKs received, and when the third one is received, assume that a segment has been lost and retransmit only one segment starting with that sequence number. This is Jacobson fast retransmit algorithm 38 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 38 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Another retransmission example (2)» Before retransmission the receiver TCP saves the data received out of order. For every TCP segments arrived out of order the receiver sends back duplicate ACK immediately (no delayed ACK!!!).» After the retransmission the sender continues normal transmission of data.» Currently there is no way for TCP to tell the other end that a segment is missing. Also, TCP can not acknowledge out of order data. 39 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 39 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Congestion avoidance algorithm» With Slow Start, cwnd is increased exponentially» The exponential growth of cwnd is stopped by a packet loss» After a packet loss (due to retransmission) TCP reduces cwnd to one segment and performs Slow Start» Congestion avoidance algorithm allows TCP to switch from exponential growth of cwnd to additive growth of it.» With congestion avoidance TCP increases cwnd with maximum one segment each round trip time» Packet losses will be less frequent. 40 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. Csomagvesztéskor felezzük a kapcsolat sebességét, nem újra indítjuk 1 csomagról. 40 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

CWND increase in congestion avoidance» cwnd = cwnd + 1/cwnd each time an ACK is received» this is an additive increase (compared to slow start exponential increase)» cwnd is increased by one segment in each RTT» cwnd = cwnd + segmentsize segmentsize/cwnd» cwnd is maintained in bytes!!! 41 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. A windowméretet byte-ban kezeljük. 41 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Congestion avoidance cwnd, ssthresh (slow start threshold size) 1. Init for a given connection cwnd =1, ssthresh=65536 2. cwnd is increased by slow start until packet lost (congestion). One half of the current window size (min of cwnd and advertised window) is saved in ssthresh 3. If congestion indicated by timeout, cwnd is set to one (segment) and slow start takes over 4. If cwnd is less than or equal to ssthresh, it is increased by slow start. If cwnd is larger than ssthresh, congestion avoidance dictates that cwnd is increased at most one segment in each RTT. 42 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 42 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Fast Retransmit and Fast Recovery Algorithms» three or more duplicate ACK is received» strong indication that a segment has been lost» retransmission (without waiting for RTO expiration) fast retransmit» Next, congestion avoidance (but not slow start) is performed. This is the fast recovery algorithm 43 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 43 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Fast Retransmit and Fast Recovery 1. When the third duplicate ACK is received set ssthresh to one half of the minimum of the current congestion window and the advertised window 2. Retransmit the missing segment. 3. Set cwnd to ssthresh plus 3 times the segment size. 4. Each time another duplicate ACK arrives, increment cwnd by the segment size and transmit a packet (if allowed by the new value of cwnd). 5. When the next ACK arrives that acknowledges new data, set cwnd to ssthresh (the value set in step 1). This should be the ACK of the retransmission from step 2, one RTT after the retransmission. This ACK should acknowledge all the intermediate segments sent between the lost packet and the receipt of the third duplicate ACK. This step is congestion avoidance 44 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 44 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.

Example (Fig 21.7, 10, 11)» When the first two duplicate ACK arrives, they are counted and cwnd is left alone.» When the third one arrives, ssthresh is set to one-half cwnd (rounded down to the next multiple of the segment size).» cwnd is set ssthresh + 3 segment size» The retransmission is then sent.» Five more duplicate ACK arrive and the cwnd is incremented by the segment size each time.» Finally, a new ACK arrives and cwnd is set to sstresh and the normal congestion avoidance takes over.» During the fast retransmit and fast recovery phase new data have been transmitted after duplicate ACK s 66, 68, 70 but not after 64 and 65 (due to the cwnd values and the unacknowledged data) 45 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23. 45 Minőségbiztosítás IP hálózatokon (vitt9181), A Transmission Control Protocol (3-4.) 2005. szeptember 20-23.