ilab Lab 4 TCP/UDP Purpose of the Transport Layer Provides an end - - PowerPoint PPT Presentation

Lehrstuhl für Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München

ilab

Lab 4 TCP/UDP

ilab: TCP/UDP 2

Purpose of the Transport Layer

 Provides an end to end connectivity to applications  Tasks

• Addressing of applications on end hosts
• Reliable data transfer
• Packets might
• get lost on their way
• arrive out of order
• contain errors
• Protection of the receiver and the network

application TCP IP Network 1 IP Network 1Network 2 IP Network 2Network 3 application TCP IP Network 3

1 / 2 3 4

ilab: TCP/UDP 3

Addressing of application

 The internet model uses port numbers to address services  „Well-known“ Ports:

• e.g. a webserver is usually reachable at port 80

 Sometimes port numbers are dynamically exchanged on connection

establishment (e.g. Voice over IP)

 Otherwise the user needs to specify the port in order to communicate

with a service

Server Webserver Port 80 Mailserver Port 25 Client Browser

ilab: TCP/UDP 4

Addressing of applications II

 Port numbers are NOT globally unique  Several clients can connect to the same server using the same port  Thus, more information is needed in order to uniquely identify a

connection

 IP 5 tuple:

• Source port, source IP address, destination port, dest. IP address, layer 4

protocoll (tcp or udp)

• The endpoints of such a connection are called sockets

Server Webserver Port 80 Client Browser Browser Client Browser Browser

ilab: TCP/UDP 5

The transport layer in the internet

 Mainly two protocols of the transport layer are used in the internet:

• TCP (Transmission Control Protocol): reliable, connection oriented

transport protocol on top of the unreliable IP

• UDP (User Datagram Protocol): unreliable, connectionless transport
• protocol. Provides an application interface for IP

Application protocol TCP UDP IP Layer 2 protocol

host A

Internet

Application protocol TCP UDP IP Layer 2 protocol

host B

ilab: TCP/UDP 6

UDP (User Datagram Protocol)

 unreliable, connectionless, simpler and faster than TCP  Demultiplexing based on port numbers  Optional checksum (mandatory for UDP over IPv6)  some „well-known“ ports:

• 13: daytime
• 53: domain name server
• 123: network time protocol

 Many multimedia applications use UDP instead of TCP

31

Packet- header Source Port Destination Port Message Length Checksum Data ...

16

ilab: TCP/UDP 7

TCP: properties and services

 TCP provides reliable, ordered delivery of a stream of bytes from a

program on one computer to another program on another computer.

 TCP adapts dynamically to the environment (e.g. network topology,

changing bandwidth)

 Data transfer:

• Connection oriented
• Full duplex
• Error correction through sequence numbers, checksum,

acknowledgements and retransmissions

• Flow control and congestion control (-> adaption to network load, stability
• f the network and fairness)

 Multiplexing based on port numbers

ilab: TCP/UDP 8

TCP: well-known ports



Many applications are based on TCP and need to choose a port number



Well known ports reserved for the most important services

• 13: time
• 20: FTP data
• 25: SMTP

(Simple Mail Transfer Protocol)

• 53: DNS

(Domain Name Server)

• 80: HTTP

(Hyper Text Transfer Protocol)

• 119: NNTP

(Network News Transfer Protocol)

> telnet walapai 13 Trying 129.13.3.121... Connected to leonis. Escape character is '^]'. Mon Aug 4 16:57:19 2002 Connection closed by foreign host

> telnet mailhost 25 Trying 129.13.3.161... Connected to mailhost . Escape character is '^]'. 220 mailhost ESMTP Sendmail 8.8.5/8.8.5; Mon, 4 Aug 2002 17:02:51 +0200 HELP 214-This is Sendmail version 8.8.5 214-Topics: 214- HELO EHLO MAIL RCPT DATA 214- RSET NOOP QUIT HELP VRFY 214- EXPN VERB ETRN DSN 214-For more info use "HELP <topic>". ... 214 End of HELP info

ilab: TCP/UDP 9

TCP Header

31

Packet Header

alternatively: PSH (Push-Bit) 16

Source Port Destination Port Sequence Number Piggyback Acknowledgement

4 bit TCP header length 6 bit unused U R G A C K E O M R S T S Y N F I N

Window Checksum Urgent Pointer Options (0 oder mehr 32-bit-Worte) Daten ...

ilab: TCP/UDP 10

Lifetime of a TCP connection

 connection establishment

• 3 way handshake
• Negotiation of window size and

sequence numbers

 data transfer

• Piggyback confirmation

 connection termination

• confirmed
• Ressources on client are

deallocated after the time-wait period (e.g. after 30s or 1min)

Client Server

[SYN, seq=17] [SYN, seq=39, ACK=18] [seq=18, ACK=40] Connection establishment [seq=53, ACK=78, data=‚hi‘] [seq=78, ACK=55, data=‚ho‘] Data transfer Connection termination [FIN] [ACK] [ACK] [FIN]

Time wait

ilab: TCP/UDP 11

TCP: Mechanisms (I)

 Unit for the data transfer: Segment (TCP header + payload)

• Max. size: 65536 byte (IP payload)
• In practice: 1500 byte (ethernet MTU) to avoid IP fragmentation
• TCP provides stream of bytes to application, fragmentation and segments are

hidden from user

 Checksum

• Protection of TCP header, payload and some fields of the IP header (mainly

source and destination address)

• Algorithm used: one‘s complement sum

ilab: TCP/UDP 12

TCP: Mechanisms (II)

 Detection of missing segments (at sender)

• Retransmission timer: a timer is set when sending the segment
• If the segment is not acknowledged before the timer has expired the

segment is retransmitted

• Timer is dynamically adapted to round trip time
• Alternative detection of missing segments:

Fast Retransmit -> later

 Retransmission similar to Go-Back-N

• Retransmission begins with the missing packet
• Packets that arrive out of order are buffered at the receiver

(different than Go-Back-N)

ilab: TCP/UDP 13

TCP: Mechanisms (III)

 Acknowledgements (ACKs)

• ACK number n acknowledges the reception of all bytes until seq. Number n-1

(cumulative acknowledgement)

• On gaps (e.g. due to out of order transmission) the receiver always sends an

acknowledgement containing the number of the next expected byte which leads to duplicate ACKs (see next slide)

• Faulty packets are discarded and not acknowledged

 Piggybacking

• No separate ACK
• ACKs are included in payload

ilab: TCP/UDP 14

Cumulative acknowledgements 1

send ACK

1 1 3 3 2

• 1. Segment arrives and is acknowledged:
• 2. Segment arrived out of order, 1st byte after the first segment is still

missing

send „duplicate“ ACK send ACK

• 3. Segment arrives and fills the gap. Receiver acknowledges 3rd segment

ilab: TCP/UDP 15

Sliding Window

 The receive window specifies the amount of data that the receiver is

willing to buffer for the connection

• Performance advantage compared to stop and wait

P1,0 ACK,1 P2,1 P3,2 ACK,2 ACK,3 P4,3

1 2 3 4 5 … Sequence numbers Sending window 1 2 3 4 5 … 1 2 3 4 5 … 1 2 3 4 5 … ACK for received packet Px,i is ACK, (i+1)

CAREFUL:

Unit for Sequence- numbers is bytes!

Slide window on received acknowledges

ilab: TCP/UDP 16

Window size



The sending window is the minimum of

• The receiver window for the flow control (protection agains too many packets)
• The congestion window (CWND, control the rate of data entering the network)



Flowcontrol in TCP

• Credit based
• The receiver informs the sender using the „window field“ in the TCP header

about the amount of data it is willing to buffer



Scalability of the window field

• Default window size is 16 bit (max. 65536 bytes of unacknowledged data)
• Not enough for high performance networks (window option with 32bit allows a max.
• f 4Gb of unack. data)
• limit because of 32bit sequence numbers

ilab: TCP/UDP 17

Sliding Window / Flow Control

Sender

 LastByteAcked < =

LastByteSent

 LastByteSent < =

LastByteWritten

 Buffers all data

LastByteAcked and LastByteWritten

Sender LastByteWritten TCP LastByteSent LastByteAcked Receiver LastByteRead TCP LastByteRcvd NextByteExpected

Receiver



LastByteRead < NextByteExpected



NextByteExpected < = LastByteRcvd +1



Buffers all data LastByteRead and LastByteRcvd

ilab: TCP/UDP 18

Congestion Control

 Goals and problems hereby

• Reasonable behavior in case of network (over)load
• Without controlling the outgoing amount of data, the capacity may

drop to zero because of deadlocks

• Fair ressource sharing
• Criteria: effective, simple, robust, end-host driven

Load of the system Without control Flow and congestion control ideal deadlock capacity

max.

ilab: TCP/UDP 19

Congestion control (Van Jacobson)

 Problem: the end host does not know a lot about the network. It only

knows if a packet has been delivered successfully or not

 Self clocking: for every segment that leaves the network we can send

a new one

 Assumption: packet loss only because of congestion

• Not true for wireless networks

Figure: Van Jacobson. Congestion aviodance and control. In ACM SIGCOMM, pages 314

• - 329, August 1988

ilab: TCP/UDP 20

TCP congestion control without fast retransmit

4 8 12 16 20 24 28 32 36 40 44 CWND size 2 4 6 8 10 12 14 16 18 20 22 24

Slow start algorithm of TCP

Threshold Threshold SSTHRESH Timeout Round-trips Slow-Start + 1 per ACK Congestion-Avoidance + per ACK

windowsize 1

Here the window size is measured in number of packets Real TCP uses bytes.

ilab: TCP/UDP 21

Slow Start

 Basic idea: packet loss indicates congestion  Algorithm slowly approaches the limit

t in RTTs t in RTTs CWND in Segments

• 1. Segment 1 is sent
• 2. The ACK for segment 1 is received, CWND+=1 (now 2)

Segments 2 and 3 are sent out

• 3. The ACK for segments 2+3 are received, CWND+=2

(now 4), Segments 4-7 are sent out

• 4. The ACK for segments 4-7 are received, CWND+=4

(now 8), Segments 8-15 are sent out

• 5. The ACK for segments 8 and 9 are received,

Packets 10-15 got lost on their way CWND+=2 (now 10), segments 16-19 are sent and get lost No more ACKs are received  Timeout.

ilab: TCP/UDP 22

Congestion Avoidance

Situation: CWND was 10  set SSTHRESH = 10 / 2 = 5 last acked segment 9  continue with 10

• 1. Slow Start till CWND = SSTHRESH
• 2. Afterwards CWND is increased by 1 per Round-Trip time.

t in RTTs CWND in Segments

ilab: TCP/UDP 23

Fast Retransmit

t in RTTs

Situation: Segment 39 was lost. CWND is 8, segments 40-46 can be sent without waiting for the ACK for segment 39

• 1. Segment 40 arrives at the receiver and is buffered. Since it is

waiting for 39, the receiver resends the ACK for packet 39

• 2. Segments 41 and 42 arrive. The receiver sends the ACK for

39 two times

• 3. Now the sender received 4 ACKs for packet 39 (1x original, 3x

duplicate). It assumes that segement 39 is missing but all other packets made their way (no complete congestion). Thus it retransmits segment 39.

CWND in Segments

ilab: TCP/UDP 24

Fast Recovery I

t in RTTs CWND in SMSS

Situation: Segment 39 was lost and re-transmitted, it will take a whole RTT until its ACK arrives. Segments 40-46 were already sent. CWND is 8, so with the regular rules, the sender would have to wait for the right ACK before being allowed to send any more data. 3 duplicate ACKs were received so far (corresponding to packet 40, 41, 42). As the sender still receives ACKs it can tell that the congestion is not too bad – at least the line is not so congested that nothing comes through. Hope: Maybe only a single segment was lost. Each arriving duplicate ACK means, that one packet has arrived at the receiver, so there is one less packet currently in transit. Idea of fast Recovery:

• Reduce the Window by 50%
• Then keep the number of segments in transit equal to the new window size even though there are no

new ACKs (Compare Jacobson’s Self-Clocking).

ilab: TCP/UDP 25

Fast Recovery II

t in RTTs CWND in SMSS

• 1. The sender reduces the congestion window by

50% (window size: 4, segments: 39-42). This is the amount of data that we want to have in transit for now.

• 2. It adds 3 for the 3 duplicate ACKs it has received

 those packets have already left the network. (window size: 7, segments: 39-45)

• 3. The next duplicate ACK arrives. CWND is

increased by 1 (window size: 8, segments: 39-46).

• 4. Another duplicate ACK arrives. CWND is

increased by 1 (window size: 9, segments: 39-47). The sender is allowed to send a new segment!

• 5. One more duplicate ACK arrives. CWND is

increased by 1 (window size: 10, segments: 39-48). The sender is allowed to send a new segment!

• 7. The ACK for segment 39 arrives (actually it is a cummulative ACK for segment 46).

The sender remembers the value of CWND before starting fast retransmit. CWND is set to half of the old value.

• 8. The sender continues with Congestion Avoidance.

(window size: 4, segments 47-50)

ilab: TCP/UDP 26

A Simulation Trace