transport layer orientation

32
1 © Jörg Liebeherr, 1998,1999 CS457 1 Transport Layer Introduction Flow Control (Credit Allocation) Connection Management Examples: TCP, UDP © Jörg Liebeherr, 1998,1999 CS457 2 Orientation n Transport layer protocols are end-to-end protocols n Transport layer is only implemented at the hosts Application Transport Network HOST Data Link Data Link Data Link Network Application Transport Network HOST Data Link

Upload: lytruc

Post on 12-Jan-2017

220 views

Category:

Documents


0 download

TRANSCRIPT

1

© Jörg Liebeherr, 1998,1999 CS457 1

Transport Layer

Introduction

Flow Control (Credit Allocation)

Connection Management

Examples: TCP, UDP

© Jörg Liebeherr, 1998,1999 CS457 2

Orientation

n Transport layer protocols are end-to-end protocolsn Transport layer is only implemented at the hosts

Application

Transport

Network

HOST

Data Link Data Link Data Link

Network

Application

Transport

Network

HOST

Data Link

2

© Jörg Liebeherr, 1998,1999 CS457 3

Protocol Mechanisms

• Addressing• Multiplexing• Flow Control• Error Control• Connection Management

Note: The mechanisms needed to implement a transport service are largely dependent on the existing network layer service

© Jörg Liebeherr, 1998,1999 CS457 4

Addressing

• An address at the transport layer is typically a tuple (Station,Port) where– Station is the network address of the host, and– Port identifies the application

• Recall: The <IP address, port number> tuples used in theUnix assignments are in fact transport layer addresses

• Problem with Addressing: How to find the address of aservice?

3

© Jörg Liebeherr, 1998,1999 CS457 5

Flow Control

• Why do we need flow control at the transport layer?1. User of receiving transport entity cannot keep up with the data flow.2. Receiving transport entity itself cannot keep up withflow of incoming packet.

Result: Buffer overflows in the receiving transport entity.

© Jörg Liebeherr, 1998,1999 CS457 6

Need for Flow Control

transportentitity

transportentitity

Site A Site B

networklayer

transportuser

transportlayer

4

© Jörg Liebeherr, 1998,1999 CS457 7

Flow Control at the Transport Layer

• Flow Control at the transport layer is more complex than flowcontrol at the data link layer:– Delays are variable and are longer– Flow control involves the transport users, the transport

entities, and the network service

© Jörg Liebeherr, 1998,1999 CS457 8

Approaches to Flow Control

• Do Nothing– TPDUs that overflow the buffer are discarded

• Refuse to accept TPDUs from the network layer– Requires a backpressure mechanism that pushes flow

control to the network layer• (Fixed) Sliding-window Protocol

– Our well known sliding window scheme– But:

• Withholding acknowledgments in an unreliable networkresults in retransmission

• Sliding window flow control not effective

5

© Jörg Liebeherr, 1998,1999 CS457 9

Credit Allocation Flow Control

• Credit Allocation Flow Control is an extension of the slidingwindow flow control.

• Main Idea:– Enhance the sliding window protocol by a mechanism that

decouples acknowledgments from flow control.• Then:

– Packets can be acknowledged without granting permissionfor new transmissions

– Used in many existing transport protocols, including TCP

© Jörg Liebeherr, 1998,1999 CS457 10

Credit Allocation Flow Control

• Initialization during connection setup:– Set initial window size of receiver– Receiver both acknowledges TPDUs and grants credit by

sending a message: (ACK N, CREDIT M)

– ACK N: Acknowledges all sequence numbers through N-1– CREDIT M:Sets the number of credits to M

Credit is the maximum window size (=buffer space at the receiver)

6

© Jörg Liebeherr, 1998,1999 CS457 11

Example

ReceiverTransmitter

0 1 2 3 4 5 6 7 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3

0 1 2 3 4 5 6 7 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3

0 1 2 3 4 5 6 7 0 1 2 3

0 1 2 3 4 5 6 7 0 1 2 3

T0T1T2

ACK2, Credit 6

0 1 2 3 4 5 6 7 0 1 2 3

T4T5

0 1 2 3 4 5 6 7 0 1 2 3

n Initial Setting: Credit = 7

© Jörg Liebeherr, 1998,1999 CS457 12

Example

ReceiverTransmitter

0 1 2 3 4 5 6 7 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3

0 1 2 3 4 5 6 7 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3

0 1 2 3 4 5 6 7 0 1 2 3

D5D6D7

ACK0, Credit 4

0 1 2 3 4 5 6 7 0 1 2 3

7

© Jörg Liebeherr, 1998,1999 CS457 13

Error Control at the Transport Layer

• Basic techniques for error recovery are the same as at theData Link Layer:– Lost or damaged TPDUs are recovered with one of the

ARQ retransmission schemes– Mostly: Go-back-N, Selective Repeat.

• Problem: The end-to-end delay of TPDUs is variable. Thismakes it difficult to set the timeout values.– Small timeout value: unnecessary retransmissions.– Large timeout value: low throughput.

• Most transport protocols have adaptive timers

© Jörg Liebeherr, 1998,1999 CS457 14

Connection Management

• Connection establishment and connection termination areessential for a connection-oriented service

• Connection establishment is asymmetric:– one side puts itself in a LISTEN state (server)– one side issues a request for connection or RFC (client)

8

© Jörg Liebeherr, 1998,1999 CS457 15

Simple Solution (which has problems)

• CR (SeqNo = x)ConnectionRequest, A wantsto start with SeqNo= x

• ACK (SeqNo = y)Acknowledgerequest, B willwants to start withSeqNo = y

• DATA (SeqNo = x)Data transmissionwith SeqNo x

Host A Host B

CR (SeqNo = x)

ACK (SeqNo = y)

DATA(SeqNo = x)

Two Way Handshake

© Jörg Liebeherr, 1998,1999 CS457 16

Problems with Two-Way Handshake

• B responds toCR(SeqNo = z),an old duplicateconnectionrequests from A

• In the shown sce-nario, A believesthat the ACK is forthe connectionrequestCR(SeqNo = y)

Host A Host B

CR (SeqNo = x)

ACK (SeqNo = y)

DATA(SeqNo = x)

CR (SeqNo = z)

n Result: A starts to send data with Sequence x. B willthrow the data away since it expects SeqNo = z

9

© Jörg Liebeherr, 1998,1999 CS457 17

Three-Way Handshake

• Note: A and Backnowledge thesequence numberfrom the other side

• This solutionprovides protectionfrom old duplicateconnectionrequests

Host A Host B

CR (SeqNo = x)

ACK (SeqNo = y, ACK = x)

DATA(SeqNo = x, ACK = y)

© Jörg Liebeherr, 1998,1999 CS457 18

Scenario 1

• Host A rejects theinvalid connectionrequest in theREJ(ACK=y)packet

• Note: Theconnection requestCR(SeqNo=x) iscompletedsuccessfully

Host A Host B

CR (SeqNo = x)

ACK (SeqNo = y, ACK=z)

CR (SeqNo = z)

ACK (SeqNo = u, ACK = x)

DATA(SeqNo = x, ACK = u)

REJ (ACK = y)

n Duplicate connection request (CR) appears

10

© Jörg Liebeherr, 1998,1999 CS457 19

Scenario 2

• Host A rejects theinvalid ACK bysendingREJ(ACK=y)

• Note: Theconnection requestCR(SeqNo=x) iscompletedsuccessfully

Host A Host B

CR (SeqNo = x) ACK (SeqNo = y, ACK=z)

ACK (SeqNo = u, ACK = x)

DATA(SeqNo = x, ACK = u)

REJ (ACK = y)

n A duplicate acknowledgement (ACK) appears

© Jörg Liebeherr, 1998,1999 CS457 20

Connection Termination

• A connection release should involve both sides of theconnection (otherwise data is lost)

CR ()

ACK ()

DATA()DATA()DATA()DATA()

DR ()

Host A Host B

n Here: B shouldwait afterDisconnectionRequest (DR) issent until all datahas arrived

11

© Jörg Liebeherr, 1998,1999 CS457 21

Connection Termination in 4 steps

• An elegant way to terminate connections is to have each endshut down independently (“half-close”)

• If one end wants to shut down, it sends a DR message• Four steps involved:

(1) A sends a DR to B (active close)(2) B ACKs the DR,

(at this time: B can stillsend data to A)

(3) and B sends a DR to A (passive close)(4) A ACKs the DR

© Jörg Liebeherr, 1998,1999 CS457 22

Connection Termination in 4 steps

Host A Host B

DR

ACK

ACK

DR

n To account forpacket losses, atimer is needed tolimit the waitingtime of a side

12

© Jörg Liebeherr, 1998,1999 CS457 23

Connection Termination

Host A Host B

DR

ACK

ACK

DR

B starts atimer

B times outand releasesconnectoin

n B disconnectsafter a timeout if itdoes not receivean ACK for its DR

n Note: B knows thatboth sides havesent a DR packet;hence B knowsthat no more datais sent

© Jörg Liebeherr, 1998,1999 CS457 24

Connection Termination

Host A Host B

DR

ACK

B times outand releasesconnectoin

A starts atimer

DR

n A has aretransmissiontimer forsending the firstDR

13

© Jörg Liebeherr, 1998,1999 CS457 25

Transport Protocols in the Internet

• The Internet uses two transport protocols

– Transmission Control Protocol (TCP)

– User Datagram protocol (UDP)

© Jörg Liebeherr, 1998,1999 CS457 26

Transport Protocols in the Internet

ApplicationLayer

NetworkLayer

Link Layer

IP

ARP HardwareInterface RARP

Media

ICMP IGMP

TransportLayer

TCP UDP

UserProcess

UserProcess

UserProcess

UserProcess

14

© Jörg Liebeherr, 1998,1999 CS457 27

Transport Protocols in the Internet

UDP - User DatagramUDP - User DatagramProtocolProtocol

• datagram oriented• unreliable, connectionless• simple• unicast and multicast• useful only for few

applications, e.g., multimediaapplications

• used a lot for services– network management

(SNMP), routing (RIP),naming (DNS), etc.

TCP - Transmission ControlProtocol

• stream oriented• reliable, connection-oriented• complex• only unicast• used for most Internet

applications:– web (http), email (smtp),

file transfer (ftp), terminal(telnet), etc.

© Jörg Liebeherr, 1998,1999 CS457 28

UDP - User Datagram Protocol

• UDP is supports unreliable transmissions of datagrams• UDP merely extends the host-to-to-host delivery service of IP datagram to

an application-to-application service• The only thing that UDP adds is multiplexing and demultiplexing

UDP

IP IPIP IP IP

UDP

Applications Applications

15

© Jörg Liebeherr, 1998,1999 CS457 29

UDP Format

IP header UDP header UDP data

UDP message length Checksum

DATA

20 bytes 8 bytes

0 15 16 31

Source Port Number Destination Port Number

•Port numbers identify sending and receiving applications(processes). Maximum port number is 216-1= 65,535• Message Length is at least 8 bytes (I.e., Data field can beempty) and at most 65,535• Checksum is for header (of UDP and some of the IP headerfields)

© Jörg Liebeherr, 1998,1999 CS457 30

Port Numbers

• UDP (and TCP) use port numbers to identify applications• A globally unique address at the transport layer (for both UDP and TCP) is

a tuple <IP address, port number>• There are 65,535 UDP ports per host

IP

TCP UDP

UserProcess

Demultiplexbased on

Protocol field in IPheader

UserProcess

UserProcess

UserProcess

UserProcess

UserProcess

Demultiplexbased on

port number

16

© Jörg Liebeherr, 1998,1999 CS457 31

TCP

TCP = Transmission Control Protocol• Connection-oriented protocol• Provides a reliable unicast end-to-end byte stream over an

unreliable internetwork.

TCP

IP Internetwork

Byt

e S

tream

Byt

e S

tream

TCP

© Jörg Liebeherr, 1998,1999 CS457 32

TCP is Connection-Oriented

• Before any data transfer, TCP establishes a connection:• One TCP entity is waiting for a connection (“server”)• The other TCP entity (“client”) contacts the server

• The actual procedure for setting up connections is the threeway handshake

• Each connection isfull duplex

CLIENT SERVER

waiting forconnection

request

Request a connection

Accept a connection

DisconnectData Transer

17

© Jörg Liebeherr, 1998,1999 CS457 33

Reliable Data Transer

• Byte stream is broken up into chunks which are calledsegments– Receiver sends acknowledgements (ACKs) for segments– TCP maintains a timer. If an ACK is not received in time,

the segment is retransmitted

• Detecting errors:– TCP has checksums for header and data. Segments with

invalid checksums are discarded– Each byte that is transmitted has a sequence number

© Jörg Liebeherr, 1998,1999 CS457 34

TCP

Application

1. write 100 bytes2. write 20 bytes

queue ofbytes to betransmitted TCP

queue ofbytes thathave beenreceived

Application1. read 40 bytes2. read 40 bytes3. read 40 bytes

Segments

TCP gives a Byte Stream Service

• To the lower layers, TCP handles data in blocks, thesegments.

• To the higher layers TCP handles data as a sequence ofbytes and does not identify boundaries between bytes

• So: Higher layers do not know about the beginning and endof segments !

18

© Jörg Liebeherr, 1998,1999 CS457 35

TCP Segment Format

IP header TCP header TCP data

Sequence number (32 bits)

DATA

20 bytes 20 bytes

0 15 16 31

Source Port Number Destination Port Number

Acknowledgement number (32 bits)

window sizeheaderlength 0 Flags

Options (if any)

TCP checksum urgent pointer

20 bytes

• TCP segments have a 20 byte header with >= 0 bytes of data.

© Jörg Liebeherr, 1998,1999 CS457 36

TCP header fields

• Port Number:• A port number identifies the endpoint of a connection.• A pair <IP address, port number> identifies one

endpoint of a connection.• Two pairs <client IP address, server port number>

and <server IP address, server port number> identifya TCP connection.

TCP

IP

Applications

23 10480Ports:

TCP

IP

Applications

7 1680 Ports:

19

© Jörg Liebeherr, 1998,1999 CS457 37

TCP header fields

• Sequence Number (SeqNo):

– Sequence number is 32 bits long.– So the range of SeqNo is

– 0 <= SeqNo <= 232 -1 ≈ 4.3 Gbyte

– Each sequence number identifies a byte in the bytestream

– Initial Sequence Number (ISN) of a connection is setduring connection establishment

© Jörg Liebeherr, 1998,1999 CS457 38

TCP header fields

• Acknowledgement Number (AckNo):– Acknowledgements are piggybacked– A hosts uses the AckNo field to send acknowledgements.

(If a host sends an AckNo in a segment it sets the “ACKflag”)

– The AckNo contains the next SeqNo that a hosts wants toreceiveExample: The acknowledgement for a segment

with sequence numbers 0-1500 is AckNo=1501

20

© Jörg Liebeherr, 1998,1999 CS457 39

TCP header fields

• Flag bits:

– URG: Urgent pointer is valid– If the bit is set, the following bytes contain an urgent message in

the sequence number range “SeqNo <= urgent message <=SeqNo+urgent pointer”

– ACK: Segment carries a valid acknowledgement– PSH: PUSH Flag

– Notification from sender to the receiver that the receiver shouldpass all data that it has to the application.

– Normally set by sender when the sender’s buffer is empty

© Jörg Liebeherr, 1998,1999 CS457 40

TCP header fields

• Flag bits:

– RST: Reset the connection– The flag causes the receiver to reset the connection– Receiver of a RST terminates the connection and indicates

higher layer application about the reset

– SYN: Synchronize sequence numbers– Sent in the first packet when initiating a connection

– FIN: Sender is finished with sending– Used for closing a connection– Both sides of a connection must send a FIN

21

© Jörg Liebeherr, 1998,1999 CS457 41

TCP Connection Establishment

• TCP uses a three-way handshake

(1) ACTIVE OPEN: Client sends a segment with– SYN bit set *– port number of client– initial sequence number (ISN) of client

(2) PASSIVE OPEN: Server responds with a segment– SYN bit set *– initial sequence number of server– ACK for ISN of client

(3) Client acknowledges by sending a segment with– ACK ISN of server (* counts as one byte)

© Jörg Liebeherr, 1998,1999 CS457 42

Three-Way Handshake

aida.poly.edu mng.poly.edu

SYN (SeqNo = x)

SYN (SeqNo = y, AckNo = x + 1 )

(SeqNo = x+1, AckNo = y + 1 )

22

© Jörg Liebeherr, 1998,1999 CS457 43

Three-Way Handshake

aida.poly.edu mng.poly.edu

S 1031880193:1031880193(0)win 16384 <mss 1460, ...>

S 172488586:172488586(0)

ack 1031880194 win 8760 <mss 1460>

ack 172488587 win 17520

© Jörg Liebeherr, 1998,1999 CS457 44

TCP Connection Termination

• Each end of the data flow must be shut down independently(“half-close”)

• If one end is done it sends a FIN segment. This means thatno more data will be sent

• Four steps involved in closing a connection(1) X sends a FIN to Y (active close)(2) Y ACKs the FIN,

(at this time: Y can still send data to X)(3) and Y sends a FIN to X (passive close)(4) X ACKs the FIN.

23

© Jörg Liebeherr, 1998,1999 CS457 45

TCP States

State Description

CLOSED No connection is active or pendingLISTEN The server is waiting for an incoming callSYN RCVD A connection request has arrived; wait for AckSYN SENT The client has started to open a connectionESTABLISHED Normal data transfer stateFIN WAIT 1 Client has said it is finishedFIN WAIT 2 Server has agreed to releaseTIMED WAIT Wait for pending packets (“2MSL wait state”)CLOSING Both Sides have tried to close simultanesouslyCLOSE WAIT Server has initiated a releaseLAST ACK Wait for pending packets

© Jörg Liebeherr, 1998,1999 CS457 46

TCP States in Connection Lifetime

SYN (SeqNo = x)

SYN (SeqNo = y, AckNo = x + 1 )

(AckNo = y + 1 )

SYN_SENT(active open)

SYN_RCVD

ESTABLISHED

ESTABLISHED

FIN_WAIT_1(active close)

LISTEN(passive open)

FIN (SeqNo = m)

CLOSE_WAIT(passive close)

(AckNo = m+ 1 )

FIN (SeqNo = n )

(AckNo = n+1)LAST_ACK

FIN_WAIT_2

TIME_WAIT

CLOSED

24

© Jörg Liebeherr, 1998,1999 CS457 47

TCP State Transition DiagramOpening A Connection

CLOSED

LISTEN

SYN RCVD SYN SENT

ESTABLISHED

active opensend: SYN

recv: SYN, ACKsend: ACK

recv: SYNsend: SYN, ACK

recvd: ACKsend: . / .

recv:RST

Application sends datasend: SYN

simultaneous openrecv: SYNsend: SYN, ACK

close ortimeout

passive opensend: . / .

recvd: FIN send: FIN

send:FIN

© Jörg Liebeherr, 1998,1999 CS457 48

TCP State Transition DiagramClosing A Connection

FIN_WAIT_1

FIN_WAIT_2

ESTABLISHED

recv: FINsend: ACK

recv: ACKsend: . / .

recvd: ACKsend: . / .

recv:FIN, ACKsend: ACK

active opensend: FIN

TIME_WAIT

CLOSINGrecv: FINsend: ACK

CLOSED

Timeout(2 MSL)

CLOSE_WAIT

LAST_ACK

passive closerecv: FINsend: ACK

applicationclosessend: FIN

recv: ACKsend: . / .

25

© Jörg Liebeherr, 1998,1999 CS457 49

Flow Control in TCP

• Flow Control: How to prevent that the sender overruns the receiver with information?

• Flow Control in TCP– TCP implements sliding window flow control– Sending acknowledgements is separated from setting the

window size at sender. Acknowledgements do notautomatically increase the window size (credit allocationflow control)

– Acknowledgements are cumulative

© Jörg Liebeherr, 1998,1999 CS457 50

Slow Start/Congestion Avoidance

• TCP has a mechanism for congestion control. Themechanism is implemented at the sender

• The sender has two additional parameters:– Congestion Window (cwnd; Initial value is 1 MSS

counted as bytes)– Threshhold Value (ssthresh; Initial value is 65536 bytes)

• The window size at the sender is set as follows: Allowed Window =

MIN (flow control window, congestion window)

26

© Jörg Liebeherr, 1998,1999 CS457 51

Slow Start

• Whenever starting traffic on a new connection, or wheneverincreasing traffic after congestion was experienced:

• Set cwnd = MSS bytes (=1 segment)• Each time an ACK is received, the congestion window

is increased by 1 segment (= MSS bytes).• If an ACK acknowledges two segments, cwnd is still

increased by only 1 segment.• Even if ACK acknowledges a segment that is smaller

than MSS bytes long, cwnd is increased by MSS bytes.

• Does Slow Start increment slowly? Not really.In fact, the increase of cwnd can be exponential

© Jörg Liebeherr, 1998,1999 CS457 52

Slow Start Example

• The congestionwindow size growsvery rapidly– For every ACK, we

increase cwnd by1 irrespective ofthe number ofsegments ACK’ed

• TCP slows down theincrease of cwndwhencwnd > ssthresh

segment 1

ACK for segment 1

cwnd =1xMSS

cwnd =2xMSS segment 2

segment 3

ACK for segments 2

cwnd =4xMSS segment 4

segment 5segment 6

ACK for segments 4

cwnd =7xMSS

ACK for segments 3

ACK for segments 5

ACK for segments 6

27

© Jörg Liebeherr, 1998,1999 CS457 53

Slow Start

• “Slow Start” slows down if the congestion window is largerthan a threshold value

• If cwnd > ssthresh then each time an ACK is received,increment cwnd as follows:

• cwnd = cwnd + MSS * MSS / cwnd + segsize / 8

• So cwnd is increased by one only if all segments have beenacknowledged.

• ssthresh is modified if there is congestion in the network

© Jörg Liebeherr, 1998,1999 CS457 54

Slow Start Example

Assume that ssthresh = 8 cwnd = 1

cwnd = 2

cwnd = 4

cwnd = 8

cwnd = 9

cwnd = 10

02468

101214

t=0 t=2 t=4 t=6Roundtrip times

Cw

nd (i

n se

gmen

ts)

ssthresh

28

© Jörg Liebeherr, 1998,1999 CS457 55

Congestion Avoidance

• Most often, a packet loss in a network is due to an overflow ata congested router (rather than due to a transmission error)

• A sender can detect lost packets through a:• Timeout of a retransmission timer• Receipt of a duplicate ACK

• TCP assumes that a packet loss is caused by congestion andreduces the size of the sending window

• The algorithm that reduces and then reopens the sendingwindow is called Congestion Avoidance

© Jörg Liebeherr, 1998,1999 CS457 56

Slow Start / Congestion Avoidance

• Implemented with two variables:• Congestion window (cwnd)• Slow start threshhold (ssthr)

• Initialization:cwnd= MSS bytesssthr = 64535 bytes

• The window size at the sender is set as follows:Allowed Window = MIN (advertised window, cwnd)

29

© Jörg Liebeherr, 1998,1999 CS457 57

Slow Start / Congestion Avoidance

• Here we give a more accurate version than in our earlierdiscussion of Slow Start:

If cwnd <= ssthresh thenEach time an Ack is received:cwnd = cwnd + MSS

else /* cwnd > ssthresh */Each time an Ack is received :cwnd = cwnd + MSS * MSS / cwnd + segsize / 8

endif

© Jörg Liebeherr, 1998,1999 CS457 58

Slow Start / Congestion Avoidance

• Each time when congestion occurs (timeout or receipt ofduplicate ACK),– cwnd is reset to one:

– cwnd = 1– ssthresh is set to half the current size of the congestion

window:– ssthressh = cwnd / 2

30

© Jörg Liebeherr, 1998,1999 CS457 59

Slow Start / Congestion Avoidance

• A typical plot of cwnd for a TCP connection (MSS = 1500bytes) :

© Jörg Liebeherr, 1998,1999 CS457 60

Error Control in TCP

• TCP implements a variation of the Go-back-N retransmissionscheme

• TCP maintains four (4) timers for each connection• TCP couples error control and congestion control (I.e., it

assumes that errors are caused by congestion)• TCP allows accelerated retransmissions (Fast Retransmit)

31

© Jörg Liebeherr, 1998,1999 CS457 61

Round-Trip Time Measurements

• The retransmission mechanism of TCP is adaptive• The retransmission timers are set based on round-trip time

(RTT) measurements that TCP performs

Segment 1

Segment 4

ACK for Segment 1

Segment 2Segment 3

ACK for Segment 2 + 3

Segment 5

ACK for Segment 4

ACK for Segment 5

RTT #1

RTT #2

RTT #3

The RTT is based on timedifference between segmenttransmission and receipt of ACKBut:

TCP does not ACK eachsegmentEach connection has onlyone timer

© Jörg Liebeherr, 1998,1999 CS457 62

Round-Trip Time Measurements

• Retransmission timer is set to a Retransmission Timeout(RTO) value

• RTO is calculated based on the RTT measurements• The RTT measurements are smoothed by the following

estimators srtt and rttvar:srttn+1 = α RTT + (1- α ) srttnrttvarn+1 = β ( | RTT - srttn+1 | ) + (1- β ) rttvarn

RTOn+1 = srttn+1 + 4 rttvarn+1

• The gains are set to α =1/4 and β =1/8• srtt0 = 0 sec, rttvar0 = 3 sec, Also: RTO1 = srtt1 + 2 rttvar1

32

© Jörg Liebeherr, 1998,1999 CS457 63

Karn’s Algorithm

• If an ACK for a retransmittedsegment is received, the sendercannot tell if the ACK belongs tothe original or the retransmission.

segment

ACK

retransmissionof segment

Timeout !

RT

T ?

RT

T ?

Karn’s Algorithm:Don’t update srtt on any segments that have beenretransmitted.Each time when TCP retransmits, it sets:RTOn+1 = max ( 2 RTOn, 64) (exponential backoff)

© Jörg Liebeherr, 1998,1999 CS457 64

RTO Calculation: Example

• At t1: RTO = srtt + 2 rttvar = 6 sec

• At t2: RTO= 2 * (srtt + 4rttvar) = 24 sec (exponential backoff)

• At t4: RTO is not updated (Due to Karn’s algorithm)

RTT #1 RTT #3

Seg

men

t 1

AC

K for S

egment 1

SY

N

SY

N

Time-out !

SY

N + A

CK S

egm

ent 2

Seg

men

t 3

AC

K for S

egment 2

ACK

for

Segment 3

RTT #2

Segm

ent 4

.Se

gmen

t 5

.

Segm

ent 6

.

ACK

for

Segment 4

t1 t2 t3 t4 t5 t6 t7 t8

AC

K

t9