1 Chapter 3 Transport Layer Part of slides provided by J.F Kurose and K.W. Ross, All Rights Reserved 3-1 Communication Networks P. Demeester Computer.

1

Chapter 3Transport Layer

Part of slides provided by J.F Kurose and K.W. Ross, All Rights Reserved

3-1

Communication NetworksP. Demeester

Computer networking -A top-down approach featuring the internet4th Edition, 2008Addison WesleyJames F. Kurose, Keith W. RossISBN 0-321-49770-8

Transport Layer 3-2

Chapter 3: Transport Layer

Our goals: understand principles

behind transport layer services: multiplexing/

demultiplexing reliable data transfer flow control congestion control

learn about transport layer protocols in the Internet: UDP: connectionless

transport TCP: connection-oriented

transport

Transport Layer 3-3

Chapter 3 outline

3.1 Transport-layer services

3.2 Multiplexing and demultiplexing

3.3 Connectionless transport: UDP

3.4 Principles of reliable data transfer

3.5 Connection-oriented transport: TCP segment structure connection

management reliable data transfer flow control

3.6 Principles of congestion control

3.7 TCP congestion control

Transport Layer 3-4

Transport services and protocols

provide logical communication between app processes running on different hosts

transport protocols run in end systems send side: breaks app

messages into segments, passes to network layer

rcv side: reassembles segments into messages, passes to app layer

more than one transport protocol available to apps Internet: TCP and UDP

application

transportnetworkdata linkphysical

application


networkdata linkphysical



networkdata linkphysicalnetwork

data linkphysical

logical end-end transport

Transport Layer 3-5

Transport vs. network layer

network layer: logical communication between hosts (IP address)

transport layer: logical communication between processes (port) relies on, enhances,

network layer services

Household analogy:12 kids sending letters

to 12 kids processes = kids app messages =

letters in envelopes hosts = houses transport protocol =

Ann and Bill network-layer protocol

= postal service

Transport Layer 3-6

Internet transport-layer protocols

reliable, in-order delivery (TCP) congestion control flow control connection setup

unreliable, unordered delivery: UDP no-frills extension of

“best-effort” IP

services not available: delay guarantees bandwidth guarantees

application


application





networkdata linkphysicalnetwork

data linkphysical

logical end-end transport

Transport Layer 3-7

Chapter 3 outline









Transport Layer 3-8

P1application

transport

network

link

physical

SNMPDNS

server

Multiplexing/demultiplexing

16153application

transport

network

link

physical

2345Proc

host 1

application

transport

network

link

physical

4235Proc

host 2

= process= socket

delivering received segmentsto correct socket

Demultiplexing at rcv side:gathering data from multiplesockets, enveloping data with header (later used for demultiplexing)

Multiplexing at send side:

Transport Layer 3-9

How demultiplexing works

host receives IP datagrams each datagram has source IP

address, destination IP address each datagram carries 1 transport-

layer segment each segment has source,

destination port number (recall: well-known port numbers for specific applications)

host uses IP addresses & port numbers to direct segment to appropriate socket

source port # dest port #

32 bits

applicationdata

(message)

other header fields

TCP/UDP segment format

Transport Layer 3-10

Connectionless (de)multiplexing

Create sockets with port numbers:

DatagramSocket serverSocket1 = new DatagramSocket(53);

DatagramSocket serverSocket2 = new DatagramSocket(161);

UDP socket identified by two-tuple:

(dest IP address, dest port number)

When host receives UDP segment: checks destination port

number in segment directs UDP segment to

socket with that port number

IP datagrams with different source IP addresses and/or source port numbers directed to same socket


Connectionless (de)multiplexing

DatagramSocket serverSocket = new DatagramSocket(53);

ClientIP: B

client IP: A

P12345Proc

4235Proc

53DNS

serverIP: C

SP: 2345

DP: 53

SP: 53

DP: 2345

SP: 4235

DP: 53

SP: 53

DP: 4235

Source Port (SP) provides “return address”


Connection-oriented (de)mux

TCP socket identified by 4-tuple: source IP address source port number dest IP address dest port number

recv host uses all four values to direct segment to appropriate socket

Server host may support many simultaneous TCP sockets: each socket identified

by its own 4-tuple

Web servers have different sockets for each connecting client non-persistent HTTP will

have different socket for each request


httpserverIP: C

Connection-oriented (de)mux

client IP: A

SP: 80

DP: 9157

SP: 9157

DP: 80 ClientIP:B

P1

SP: 80

DP: 5775

SP: 5775

DP: 80

IP : A, CPort : 80, 9157

IP : B, CPort : 80, 5775


Chapter 3 outline










UDP: User Datagram Protocol

“no frills,” “bare bones” Internet transport protocol

“best effort” service, UDP segments may be: lost delivered out of order

to app connectionless:

no handshaking between UDP sender, receiver

each UDP segment handled independently of others

Why is there a UDP? no connection

establishment (which can add delay)

simple: no connection state at sender, receiver

small segment header no congestion control:

UDP can blast away as fast as desired


UDP

often used for streaming multimedia apps loss tolerant rate sensitive

other UDP uses DNS SNMP

reliable transfer over UDP: add reliability at application layer application-specific

error recovery!

source port # dest port #

32 bits

Applicationdata

(message)

UDP segment format

length checksumLength, in

bytes of UDPsegment,including

header


UDP checksum

Sender: treat segment contents

as sequence of 16-bit integers

checksum: addition (1’s complement sum) of segment contents

sender puts checksum value into UDP checksum field

Receiver: compute checksum of

received segment check if computed

checksum equals checksum field value: NO - error detected YES - no error detected.

But maybe errors nonetheless?

Goal: detect “errors” (e.g., flipped bits) in transmitted segment


Chapter 3 outline










TCP: overview

End-to-end, point-to-point, full-duplex byte-stream service over IP’s end-to-end packet delivery service

A connection-oriented protocol (handshake for initialization) over the connectionless IP protocol

Reliability (acknowledgment, retransmission, in sequence delivery, error control) over the unreliable IP protocol

Flow control end-to-end, without help from the network

Congestion control without help from the network

No guarantee on delay, delay variation, bandwidth like IP


TCP: overview

TCP(+TCP send/

receive buffer)

IP

Send/ReceiveProcess

TCP(+TCP receive/

send buffer)

IP

Receive/Send Process

Packets

Segments

Byte stream

full-duplex, pt-pt, end-end


Use of TCP

7 Echo Sends back what is received9 Discard Discards what is received13 Daytime Sends back the time of day20 FTP data Data channel for FTP21 FTP control Control channel for FTP (get, put, …)23 Telnet Default port for telnet application25 SMTP Used for sending email to a mailserver53 DNS Domain Name System over TCP80 HTTP Used in the World Wide Web109 POPv2 Used for reading email on a mailserver110 POPv3 Used for reading email on a mailserver111 SUN RPC Sun’s Remote Procedure Call over TCP119 NNTP Network News Transfer Protocol (newsgroups)143 IMAP Used for reading email on a mailserver161-162 SNMP Simple Network Management Protocol179 BGP Border Gateway Protocol194 IRC Internet Relay Chat, a chat service220 IMAPv3 Used for reading email on a mailserver515 Print Spooler Used in print servers666 Doom The popular 3D game by Id Software6000-6063 X11 The X Window System

Port Protocol Description


16-bit source port number 16-bit destination port number32-bit sequence number

32-bit acknowledgement number4-bit

headerlength

unused(6 bits)

URG

ACK

PSH

RST

SYN

FIN

16-bit window size

16-bit TCP checksum 16-bit urgent pointer

Options (if any)

Data

TCP segment structure 20, 21 : FTP23 : Telnet25 SMTP80 : HTTP

0-1023 : reserved>1023 : ephemeral

(short lived) port

each byte from sender to receiver has a 32 bit sequence number

(this number indicates the first byte)One more than the sequence number of the last byte

being acknowledged

length of TCP headerin 32-bit words

different flags

maximum number of bytesthat sender of this segment

still can receivemandatory :

covers header and data fielde.g.: maximum segment size

(MSS) that sender can receiverelative position of the

urgent data in the segment


Chapter 3 outline










TCP Connection OPEN3

-way h

an

dsh

ake

Server sideClient side

OPEN TCP connection

(negotiate initial settings)

<SP=13400, DP=23, SEQ=4432901 (0), SYN, MSS=1024>

<SP=13400, DP=23, SEQ=4432902 (0), ACK= 1353922, ACK>

<SP=23, DP=13400, SEQ=1353921 (0), ACK=4432902, ACK, SYN, MSS=2048>

Note : most important fields in TCP header are indicatedNote : last segment may contain data

SP : Source Port numberDP : Destination Port number

SEQ : SEQuence number(…) : length data field

ACK : ACKnowledgment numberSYN : SYN flag set to 1ACK : ACK flag set to 1

MSS : Maximum Segment Size


TCP Connection CLOSE

Server sideClient side

CLOSE TCP connection

<SP=13400, DP=23, SEQ=4438053 (0), ACK=1360134, ACK, FIN>

<SP=13400, DP=23, SEQ=4438054(0), ACK= 1360135, ACK>

<SP=23, DP=13400, SEQ=1360134 (0), ACK=4438054, ACK>

<SP=23, DP=13400, SEQ=1360134(0), ACK=4438054, ACK, FIN>acti

ve c

lose

passiv

e c

lose


ACTIVECLOSE

PASSIVECLOSE

TCP State Transition Diagram

SYN_SENT

appl: active opensend: SYN

recv: ACK, SYNsend: ACK

SYN_RCVD

recv: SYNsend: ACK, SYN

recv: ACKsend: -

LISTEN

appl: passive opensend: -

CLOSE_WAIT

recv: FINsend: ACK

recv: ACK, FINsend: ACK

FIN_WAIT_1

appl: closesend: FIN

FIN_WAIT_2

recv: ACKsend: - LAST_ACK

appl: closesend: FIN

TIME_WAIT

recv: FINsend: ACK

CLOSEDSTARTING POINT

ESTABLISHED

DATA TRANSFER

STATE

recv : ACKsend : -

wait 2 MSLMaximum segment lifetime


Chapter 3 outline










Acknowledgment and retransmission

<SEQ=135 (10)>

<ACK=145>

<SEQ=145 (20)>

<ACK>

<SEQ=145 (20)>

<ACK=165>

<SEQ=165 (30)>

Receiver sideSender side

use of acknowledgements

timeoutretransm

it


Ack/retrans/duplicate reception

<SEQ=145 (20)>

<SEQ=145 (20)>

<ACK=165>

<SEQ=165 (30)>

Receiver sideSender side

use of acknowledgements

<ACK = 165>timeoutretransmi

t

duplicatereception

=> discard


Piggybacking and delayed ACKs

<SEQ=145 (20)>

Receiver side BSender side A

<ACK=165>

<SEQ=2354 (500)>

<SEQ=145 (20)>

<SEQ=2354 (500), ACK 165>

piggybacked

ACK

Delayed ACK

<200 msec


Delayed accumulated ack

<SEQ=145 (20)>


<ACK=245>

accumulated

ACK

<SEQ=165 (20)>

<SEQ=185 (20)>

<SEQ=205 (20)>

<SEQ=225 (20)>

- ACK number indicates that all bytes before the ACK number have been received correctly- in practice : if a second segment is received, the accumulated ACK is send immediately

delayed

ACK

<ACK=185>

accumulated ACK

after 2 segments


Avoid retransmission


<ACK=145>timeoutretransm

it

<SEQ=165 (20)>

<SEQ=145 (20)>

<SEQ=145 (20)>

<ACK=185>

out of orderimmediate

ACK

missing segment arrived

accumulated ACK

start timerand

double RTO

not all segments have to be retransmitted !Les 5 6


Fast retransmission


<ACK=145>

<SEQ=165 (20)>

<SEQ=145 (20)>

<SEQ=145 (20)>

<ACK=225>

out of orderimmediate

ACK

missing segment arrived

accumulated ACK

<SEQ=185 (20)><SEQ=205 (20)>

<ACK=145>

<ACK=145>

retransmission much faster then timeout

timeoutNOT USED

3duplicate

dACK’s

=> fast retransm

it

Note : 3 dupl ack : make distinction with out of order

e.g. 1,3,4,2,5,6,...


TCP ACK generation

Event at Receiver

Arrival of in-order segment withexpected seq #. All data up toexpected seq # already ACKed

Arrival of in-order segment withexpected seq #. One other segment has ACK pending

Arrival of out-of-order segmenthigher-than-expect seq. # .Gap detected

Arrival of segment that partially or completely fills gap

TCP Receiver action

Delayed ACK. Wait up to 500msfor next segment. If no next segment,send ACK

Immediately send single cumulative ACK, ACKing both in-order segments

Immediately send duplicate ACK, indicating seq. # of next expected byte

Immediate send ACK, provided thatsegment starts at lower end of gap


Retransmission timeoutProblem : large variation in round trip time !!! (LAN <> worldwide Internet)

==> dynamic update of retransmission timeout (RTO)[TimeoutInterval]

RTT = RTT + (1-) M (in general = 7/8)RTT (Round Trip Time) = exponential weighted moving average (EWMA) [EstimatedRTT] M = last measured time for an acknowledgment [SampleRTT]

Retransmission Timeout : RTO = RTT + 4 DD = D + (1-) |RTT-M| (mean deviation) [DevRTT]

( = 3/4 … 7/8)

initial values : RTO = 3”D = 1.5”RTT = 0”

Exponential back-off : every retransmission of the same segment will double the RTO (with an upper limit and latching of 64”)(connection timeout after preconfigured number of retransmissions)

(note : the RTT will not be updated based on the measurement of a retransmitted segment)

new value old value measured value


Measured round trip time (M)

<SEQ=145 (20)>

<ACK=185>

<SEQ=165 (20)>

<SEQ=125 (20)>

<ACK=145>M #1

M #2

measured round trip time


Chapter 3 outline





3.5 Connection-oriented transport: TCP segment structure reliable data transfer flow control connection

management




Flow control

Flow Control : receiver limits sender speedbased on own buffer filling

• slow receiver may not be able to cope with segmentstream from fast sender

• receiver will measure buffer filling• receiver will advertise to sender its free buffer space

(advertise receive window : RcvWindow)• sender will limit outgoing traffic• ONLY terminals participate in flow control (layer 4!)


Flow control : receiver side

transport layer : TCP

receiver buffer (4 x MSS)

receiver

application layer

receive window = 2

segments delivered to application layer

segments receivedfrom senderreceive window = 4


Flow control : sender sideapplication layer

transport layer : TCP

information from applicationready to send

sender

1 2 3 4 5 6 7 8 9

ACK=3, W=3

sent, not yet acknowledged

sent and acknowledged

send window = 4send window = 2send window = 3

send window = amount of data still allowed to send


Flow control : example

1 2 3 4 5 6 7 8 9

data to be sent (expressed in MSS)

sender receiverreceiver buffer (4 x MSS)

<SYN>

<ACK, SYN, MSS=1,

Window=4>

<ACK>

<SEQ=1>

1 2 3 4 5 6 7 8 9

1 2 3 4 5 6 7 8 9

<SEQ=2>

<SEQ=3>

<SEQ=4>

2 MSS to application

<ACK=4, W=1>

1 2 3 4 5 6 7 8 9

1 2 3 4 5 6 7 8 9

<ACK=5, W=2>

receive window

send window

received not transferredto application

sent, not yet ack.

1 2 3 4 5 6 7 8 9

1 2 3 4 5 6 7 8 9sent and

acknowledged

1 2 3 4 5 6 7 8 9

zero window <ACK=5, W=0> will stop communication (no more window updates) regular probing from sender (use persistency timer)


Flow control : sliding window

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<ACK=3, W=2>

<ACK=4, W=3>

SEND WINDOW = receive window (RcvWindow)

MINUS number of sent but not yet acknowledged bytes

(LastByteSent – LastByteAcked)

allowed to send if : LastByteSent – LastByteAcked < RcvWindow or SndWindow > 0

LastByteSentLastByteAcked


Chapter 3 outline






management




Congestion <> Flow control

flow control : L4 buffers in hostscongestion control : L3 buffers in routers

Network layer : IP

Transport layer : TCP

sender receiver

buffer

!! Discarded !!

ROUTER

Transport layer : TCP

sender 2

sender 1 receiver 1

receiver 2

!! Discarded !!


Impact of congestion

Effective throughput

Traffic offered to the network

Network congestion (layer 3): - limited capacity of routers (L3)- traffic load high

Solution : Congestion Control (in terminals)

layer 4 (TCP) will reduce load offered to L3 (IP)

Maximum capacityof the network

retransmissions: packet lossdue to buffer overflow

linear increase

congestion starts


Approaches towards congestion control

End-end congestion control (TCP approach):

no explicit feedback from network

congestion inferred from end-system observed loss, delay

approach taken by TCP

Network-assisted congestion control:

routers provide feedback to end systems single bit indicating

congestion explicit rate sender

should send at

Two broad approaches towards congestion control:


Chapter 3 outline






management




Congestion window : limit send rate

Flow control : detection by receiver and control by senderreceive window (set at receiver side)

Congestion control : detection and control by sender- congestion window (set at sender side)

SEND WINDOW : MINIMUM {receive window, congestion window}

MINUSnumber of sent but not yet acknowledged bytes

allowed to send if : LastByteSent – LastByteAcked < min {CongWindow, RcvWindow}

or SndWindow > 0


Congestion window

- focus on the congestion window- suppose congestion window < receive window- congestion window multiple of MSS- expressed in bytes

receive window

congestion window

sent, not yet ack.

send window

sent and ack.

congestion window < receive window

congestion window > receive window


Congestion detection (by sender !) Timeout :

• A segment or ACK was dropped due to congestion.• A segment or ACK is experiencing a large delay due to congestion. • A segment or ACK was dropped due to a transmission error

(has nothing to do with congestion and is assumed to be not important).

TCP solution : slow start + congestion avoidance

Duplicate acknowledgments (3 or more) :• One segment was dropped due to congestion.• Next segments still get through the network

(generating duplicate acknowledgments)

TCP solution : fast retransmission (see reliability) + fast

recovery


Slow start

<SEQ=1(1)>

values expressed in MSS

<SEQ=2(1)>

<ACK=2>

<SEQ=3(1)>

<ACK=3>

<SEQ=4(1)><SEQ=5(1)><SEQ=6(1)><SEQ=7(1)><ACK=5>

cwnd = 1

cwnd = 2

cwnd = 4

cwnd = 8<SEQ=8(1)>

0

2

4

6

8

10

12

14

16

18

cwnd (# MSS)

0 1 2 3 4 5# RTT

<ACK=9>...

cwnd = 16

!!! value ofmeasured RTTis varying !!!

<ACK=4>

<ACK=6>

<ACK=7>

<ACK=8>

...


Slow start threshold / Congestion avoidance

0

2

4

6

8

10

12

14

16

18

cwnd (# MSS)

0 1 2 3 4 5# RTT

cwnd = 1

cwnd = 2

cwnd = 4

cwnd = 8

cwnd = 9

cwnd = 10

SlowStart

Threshold(ssthresh)

slowstart

congestionavoidance


Avoiding congestion (Timeout)

# RTT

cwdnsize

!!! TIMEOUT !!!ssthresh =

cwnd/2cwnd = 1 x MSS

Intial values : ssthresh = 64 kbyte

cwnd = 1xMSS

slow start

slow start

congestion avoidance

!!! TIMEOUT !!!ssthresh =

cwnd/2cwnd = 1 x MSS

Note : when cwnd > receive window==> normal flow control takes over

(based on receive window)


Avoiding congestion : dupl ack

0

2

4

6

8

10

12

14

16

18

cwnd (

# M

SS)

time

duplACK=

5

fast retransmit :

first non-ack segment=5

Ssthresh = 1/2 cwnd

cwnd = sstresh

+ 3 MSS

cwnd = sstresh

duplACK=

5

duplACK=

5

duplACK=

5

acknowledgeretransmitte

dsegment=5

ACK=11(accumulate

d)duplACK=

5

CongestionavoidanceACK=19

normal

ACK=5

see notes


TCP AIMD : Additive Increase Multiplicative Decrease

Multiplicative Decrease: cut cwnd in half after loss event

Additive Increase: increase cwnd by 1 MSS every RTT in the absence of loss events: probing

Long-lived TCP connection

8 Kbytes

16 Kbytes

24 Kbytes

time

congestionwindow


Summary: TCP Congestion control

When CongWin is below Threshold, sender in slow-start phase, window grows exponentially.

When CongWin is above Threshold, sender is in congestion-avoidance phase, window grows linearly.

When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold.

When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.


TCP fairness

Fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K

TCP connection 1

bottleneckrouter

capacity R

TCP connection 2


rate = CongWin

RTT Bytes/sec

Why is TCP fair?

time

rate

R/2

R = bottleneck rateRTT = constantrate ~ CongWinonly 3 dup ack

3 dup ack

3 dup ack

every time a “3 dup ack” occurs, difference in bitrate is halved resulting in fair distribution


Fairness : UDP, TCP

Fairness and UDP Multimedia apps

often do not use TCP do not want rate

throttled by congestion control

Instead use UDP: pump audio/video at

constant rate, tolerate packet loss

Not fair

Fairness and parallel TCP connections

nothing prevents app from opening parallel connections between 2 hosts.

Web browsers do this Example: link of rate R

supporting 9 cnctions; new app asks for 1 TCP,

gets rate R/10 new app asks for 11 TCPs,

gets R/2 !


Chapter 3 Summary

principles behind transport layer services: multiplexing,

demultiplexing reliable data transfer flow control congestion control

instantiation and implementation in the Internet UDP TCP

Next: leaving the network

“edge” (application, transport layers)

into the network “core”


Table of contents

3.1 Transport-layer services 3 3.2 Multiplexing and demultiplexing 7 3.3 Connectionless transport: UDP 14 3.5 Connection-oriented transport: TCP 18 3.6 Principles of congestion control 43 3.7 TCP congestion control 47 Summary 60 Table of contents 61

1 Chapter 3 Transport Layer Part of slides provided by J.F Kurose and K.W. Ross, All Rights Reserved 3-1 Communication Networks P. Demeester Computer.

Documents

transportlayer services

transport layer3

network layer r network

transport services

connectionless transport

transport layer services

transport layer protocols

houses r transport protocol