Lecture 8:

Transport layer

Reading 6.2, 6.3, 6.4, 6.5

Computer Networks, Tanenbaum

1
Contents

 Principles of transport layer

 UDP protocol
 Reliable data transfer
 TCP protocol

2
Transport layer in OSI model
Application Support applications
(HTTP, Mail, …)

Transport Transferring data between applications

(UDP, TCP …)

Network
Routing and forwarding data between
(IP, ICMP…) hosts

Datalink
(Ethernet, ADSL…)

Physical
(bits…)
3
Transport services and protocols
application
transport

 provide logical communication network

mobile network
data link
physical
between application processes national or global ISP

running on different hosts

 transport protocols actions in end
systems: local or
• sender: breaks application messages regional
ISP
into segments, passes to network layer home network content
• receiver: reassembles segments into provider
network
messages, passes to application layer application
transport
datacenter
network
network

 two transport protocols available to data link

physical

Internet applications enterprise

network
• TCP, UDP

4
Transport vs. network layer services
and protocols
household analogy:
12 kids in Ann’s house sending
letters to 12 kids in Bill’s
house:
 hosts = houses
 processes = kids
 app messages = letters in
envelopes
 transport protocol = Ann and Bill
who demux to in-house siblings
 network-layer protocol = postal
service

5
Transport vs. network layer services
and protocols
network layer: logical household analogy:
communication between 12 kids in Ann’s house sending
letters to 12 kids in Bill’s
hosts house:
transport layer: logical  hosts = houses
communication between  processes = kids
 app messages = letters in
processes envelopes
• relies on, enhances, network  transport protocol = Ann and Bill
layer services who demux to in-house siblings
 network-layer protocol = postal
service

6
Transport Layer Actions

Sender:
application  is passed an application- application
app. msg
layer message
transport  determines segment TThhapp. msg
transport
header fields values
network (IP)  creates segment network (IP)

link  passes segment to IP link

physical physical

7
Transport Layer Actions

Receiver:
application  receives segment from IP application
 checks header values
transport
app. msg  extracts application-layer transport
message
network (IP) network (IP)
 demultiplexes message up
link to application via socket link

physical physical
Thapp. msg

8
Why there are two kind of
services?
 Various requirement about services from
applications
 Applications that need 100% reliable data transfer,
e.g. FTP, Mail…
 Uses TCP (reliable) as transport services
 Application that need fast data transfer but can
tolerate with packet lost, e.g. VoIP, Video Streaming
 Uses UDP (best-effort) as transport services

9
Two principal Internet transport
protocols
applicatio
n
 TCP: Transmission Control Protocol transport
mobile network
network
data link
• reliable, in-order delivery physical national or global ISP

• congestion control
• flow control
• connection setup
local or
 UDP: User Datagram Protocol regional
ISP
• unreliable, unordered delivery home network content
• no-frills extension of “best-effort” IP provider
network datacenter
applicatio

 services not available:

network
n
transport
network
• delay guarantees data link
physical

• bandwidth guarantees enterprise

network

10
 Applications and transport services

Application Application protocols

Transport protocols
e-mail SMTP TCP
remote terminal access Telnet TCP
Web HTTP TCP
file transfer FTP TCP
streaming multimedia Specific protocols TCP or UDP
(e.g. RealNetworks)
Internet telephony Specific protocols
(e.g., Vonage,Dialpad) Usually UDP

11
Functionalities
MUX/DEMUX
Error control

12
Mux/Demux

Application
protocols
HTTP FTP Chat HTTP FTP Chat

Transport
Multiplexing Demultiplexing
protocols

Network protocols

13
How demultiplexing works
 host receives IP datagrams 32 bits
• each datagram has source IP source port # dest port #
address, destination IP address
• each datagram carries one other header fields
transport-layer segment
• each segment has source, application
destination port number data
 host uses IP addresses & port (payload)
numbers to direct segment to
appropriate socket TCP/UDP segment format

14
Connectionless demultiplexing
Recall: when receiving host receives
 when creating socket, must UDP segment:
specify host-local port #: • checks destination port # in
segment
DatagramSocket mySocket1
= new • directs UDP segment to socket
DatagramSocket(12534); with that port #
 when creating datagram to
send into UDP socket, must
specify IP/UDP datagrams with same
dest. port #, but different source
• destination IP address IP addresses and/or source port
• destination port # numbers will be directed to same
socket at receiving host

15
 Connectionless demultiplexing: an example
DatagramSocket
serverSocket = new
DatagramSocket
DatagramSocket mySocket2 DatagramSocket mySocket1 =
= new DatagramSocket (6428); new DatagramSocket (5775);
(9157); application
application P1 application
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical

source port: 6428 source port: ?

dest port: 9157 dest port: ?

source port: 9157 source port: ?

dest port: 6428 dest port: ?

16
Connection-oriented demultiplexing
 TCP socket identified by  server may support many
4-tuple: simultaneous TCP sockets:
• source IP address • each socket identified by its
• source port number own 4-tuple
• dest IP address • each socket associated with
• dest port number a different connecting client
 demux: receiver uses all
four values (4-tuple) to
direct segment to
appropriate socket

17
Connection-oriented demultiplexing:
example
application
application P4 P5 P6 application
P1 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address
dest IP,port: B,80 C
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
Three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets

18
Error Control
 Use CRC or Checksum
 Checksum
 Similar as checksum (16 bits) of IP
 Mechanism
 Split data to 16-bit chunks
 These chunks are then added, any generated
carry is added back to the sum
 Then, the 1’s complement of the sum is
performed and put in the checksum field
19
Example of checksum

20
Checksum
 Phát hiện lỗi bit trong các đoạn tin/gói tin
 Nguyên lý giống như checksum (16 bits) của giao thức
IP
 Ví dụ:

1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1

1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

Tổng 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
Checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
21
 UDP
User Datagram Protocol

22
“Best effort” protocols
 Why UDP?
 No need to establish connection (cause delay)
 Simple
 Small header
 No congestion control  send data as fast as possible

 Main functionality of UDP?

 MUX/DEMUX
 Detect error by checksum

23
Datagram format
 Data unit in UDP is 32 bits

called datagram source port # dest port #

length checksum

Length of the
datagram in
byte
Application
data
(message)

24
Internet checksum: an example
example: add two 16-bit integers
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

Note: when adding numbers, a carryout from the most significant bit needs to be
added to the result

* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/

25
Internet checksum: weak protection!
example: add two 16-bit integers
0 1
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0
1 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1 Even though
numbers have
sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 changed (bit
flips), no change
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 in checksum!

26
Issues of UDP
 No congestion control
 Cause overload of the Internet
 No reliability
 Applications have to implement themselves
mechanisms to control errors

27
Summary: UDP
 “no frills” protocol:
• segments may be lost, delivered out of order
• best effort service: “send and hope for the best”
 UDP has its plusses:
• no setup/handshaking needed (no RTT incurred)
• can function when network service is compromised
• helps with reliability (checksum)
 build additional functionality on top of UDP in application layer
(e.g., HTTP/3)

28
Reliable data transfer

29
Principles of reliable data transfer

sending receiving
process process
application dat dat
transport a a

sender-side of receiver-side
reliable data
Sender, receiver do not know transfer protocol
of reliable data
transfer protocol
the “state” of each other, e.g.,
was a message received? transport
network
 unless communicated via a unreliable channel
message
reliable service implementation

30
Reliable data transfer
 How to detect error?
 Checksum
 How to inform sender?
 ACK (acknowledgements):
 NAK (negative acknowledgements): tell sender
that pkt has error
 Reaction of sender?
 Retransmit the error packet once received NAK

31
Error control
Sender Receiver

send pkt0

pkt1 is
OK
rcv ACK
send pkt1

pkt1 is
corrupted

rcv NAK
resend pkt1

Time Time
32
Error in ACK/NAK
Sender Receiver
 ACK/ NAK may be
corrupted
 Packet is resent send pkt0
pkt0 is
 How to solve OK
packet repetition? rcv ACK
send pkt1
 Use Seq.# pkt1 is
OK

Rcv corrupted
packet! resend pkt1 rcv pkt1
duplicate,

Time Timediscard it
33
Error control without NAK

Sender Receiver

send pkt0

pkt0 is
OK
rcv ACK0
send pkt1

pkt1 is
OK
rcv ACK1
send pkt0
pkt0 is corrupted

rcv ACK1
resend pkt0

34
Time Time
Chanel with error and packet
lost
 Data and ACK can be lost
 If no ACK is received? How sender knows and
decides to resend data?
 Sender should wait for ACK for a certain time.
Timeout!
 How long should be timeout?
 At least 1 RTT (Round Trip Time)
 Need to start a timer each time sending a packet
 What if packet arrives and ACK is lost?
 Packet should be numbered.
35
Illustration
sender receiver sender receiver
send pkt0 pkt0 send pkt0 pkt0
rcv pkt0 rcv pkt0
ack send ack0 ack0 send ack0
rcv ack0 0 rcv ack0
send pkt1 pkt1 send pkt1 pkt1
rcv pkt1 X
loss
ack1 send ack1
rcv ack1
send pkt0 pkt0
rcv pkt0 timeout
ack0 send ack0 resend pkt1 pkt1
rcv pkt1
ack1 send ack1
rcv ack1
send pkt0 pkt0
(a) no loss rcv pkt0
ack0 send ack0

(b) packet loss

36
Illustration (2)
sender receiver
sender receiver send pkt0
pkt0
rcv pkt0
send pkt0 pkt0 send ack0
ack
rcv pkt0 rcv ack0
send ack0 send pkt1 0
ack pkt
rcv ack0 0 1 rcv pkt1
send pkt1 pkt send ack1
1 rcv pkt1 ack1
ack1 send ack1
X timeout
loss resend pkt1
pkt1 rcv pkt1
timeout
resend pkt1 pkt1
rcv pkt1 rcv ack1 (detect duplicate)
send pkt0 pkt0 send ack1
(detect duplicate)
ack1 send ack1 ack1 rcv pkt0
rcv ack1 rcv ack1 send ack0
send pkt0 pkt0 (ignore) ack0
rcv pkt0
ack0 send ack0 pkt
1

(c) ACK loss (d) premature timeout/ delayed ACK

37
Illustration

38
Performance of reliable data transfer
(stop-and-wait)
 U sender: utilization – fraction of time sender busy sending

 example: 1 Gbps link, 15 ms prop. delay, 8000 bit packet

• time to transmit packet into channel:
L 8000 bits
Dtrans = R = = 8 microsecs
109 bits/sec

39
Reliable data transfer : stop-and-wait
operation
sender receive
r
L/R L/R
Usender=
RTT + L / R
.008 RTT
=
30.008
= 0.00027

 The performance stinks!

 Protocol limits performance of underlying infrastructure (channel)

40
 Transmission in pipeline

1 data pkt Data pkts

Sender Receiver Sender Receiver

ACK ACKs

41
 Comparison of efficiency
stop-and-wait Pipeline
sender sender receiver
0
L/R L/R

RTT RTT

RTT + L / R RTT + L / R

time time
L: Size of data pkt time time
R: Link bandwidth
RTT: Round trip time 3*L/R
Performance =
RTT + L / R
L/R
Performance = 42

RTT + L / R
Pipelining: increased utilization
sender receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
3-packet pipelining increases
utilization by a factor of 3!

U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008

43
Sliding windows: mechanism
 Send multiple segments/frames simultaneously to
reduce the waiting time
 Store transmitted frames while waiting for ACKs
 The number of transmitted frames is dependent on
buffer
 After receiving ACK
 Release the acknowledged (ACK) frame from the buffer
 Send the next frame

44
Sliding window mechanism

45
Go-Back-N: sender
 sender: “window” of up to N, consecutive transmitted but unACKed pkts
• k-bit seq # in pkt header

 cumulative ACK: ACK(n): ACKs all packets up to, including seq # n

• on receiving ACK(n): move window forward to begin at n+1
 timer for oldest in-flight packet
 timeout(n): retransmit packet n and all higher seq # packets in window

46
Go-Back-N: receiver
 ACK-only: always send ACK for correctly-received packet so far, with
highest in-order seq #
• may generate duplicate ACKs
• need only remember rcv_base
 on receipt of out-of-order packet:
• can discard (don’t buffer) or buffer: an implementation decision
• re-ACK pkt with highest in-order seq #

Receiver view of sequence number space:

received and ACKed

… … Out-of-order: received but not ACKed

rcv_base
Not received

47
Go-Back-N in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, discard,
012345678 rcv ack0, send pkt4 (re)send ack1
012345678 rcv ack1, send receive pkt4, discard,
pkt5 (re)send ack1
ignore duplicate ACK receive pkt5, discard,
(re)send ack1
pkt 2 timeout
012345678 send pkt2
012345678 send pkt3
012345678 send pkt4 rcv pkt2, deliver, send ack2
012345678 send pkt5 rcv pkt3, deliver, send ack3
rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5

48
Selective repeat
receiver individually acknowledges all correctly received packets
• buffers packets, as needed, for eventual in-order delivery to upper
layer
sender times-out/retransmits individually for unACKed packets
• sender maintains timer for each unACKed pkt
sender window
• N consecutive seq #s
• limits seq #s of sent, unACKed packets

49
Selective repeat: sender, receiver
windows

50
Selective repeat: sender and receiver
sender receiver
data from above: packet n in [rcvbase, rcvbase+N-1]
 if next available seq # in  send ACK(n)
window, send packet  out-of-order: buffer
timeout(n):  in-order: deliver (also deliver
buffered, in-order packets),
 resend packet n, restart timer
advance window to next not-yet-
ACK(n) in [sendbase,sendbase+N]: received packet
 mark packet n as received packet n in [rcvbase-N,rcvbase-1]
 if n smallest unACKed packet,  ACK(n)
advance window base to next otherwise:
unACKed seq #
 ignore

51
Selective Repeat in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send
receive pkt4, buffer,
pkt5
record ack3 arrived send ack4
receive pkt5, buffer,
pkt 2 timeout send ack5
012345678 send pkt2
012345678 (but not 3,4,5)
012345678 rcv pkt2; deliver pkt2,
012345678 pkt3, pkt4, pkt5; send ack2

Q: what happens when ack2 arrives?

52
Selective repeat: sender window
(after receipt)
receiver window
(after receipt)

a dilemma! 0123012 pkt0

0123012 pkt1 0123012
0123012 pkt2 0123012

example: 0123012 pkt3

0123012

X
 seq #s: 0, 1, 2, 3 (base 4 counting) 0123012
pkt0 will accept packet
 window size=3 (a) no problem
with seq number 0

0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 X 0123012
X 0123012
X
timeout
retransmit pkt0
0123012 pkt0
will accept packet
with seq number 0
(b) oops!

53
Selective repeat: sender window
(after receipt)
receiver window
(after receipt)

a dilemma! 0123012 pkt0

0123012 pkt1 0123012
0123012 pkt2 0123012

example: 0123012 pkt3

0123012

X
 seq #s: 0, 1, 2, 3 (base 4 counting)  receiver can’t
0123012
pkt0 will accept packet
 window size=3 see sender side with seq number 0
(a) no problem
 receiver
behavior
identical in both
cases!
01 2something’s
3012 pkt0
Q: what relationship is needed (very)
0123012 wrong!
pkt1 0123012

between sequence # size and 0123012 pkt2 X

X
0123012

window size to avoid problem

0123012
X
in scenario (b)? timeout
retransmit pkt0
0123012 pkt0
will accept packet
with seq number 0
(b) oops!

54
Illustration

55
 TCP
Transmission Control Protocol

TCP segment structure

Connection management
Flow control
Congestion control

56
Overview of TCP
 Connection oriented
 3 steps hand-shake
 Data transmission in stream of byte, reliable
 Use buffer
 Transmit data in pipeline
 Increase the performance
 Flow control
 Sliding windows
 Congestion control
 Detect congestion and solve

57
 TCP segment
32 bits
URG: urgent data - For reliable
source port # dest port #
transmission
sequence number
ACK: ACK #
acknowledgement number
head not
PSH: data needs to len used
UAP R S F Receive window
-For flow control
be sent immediately checksum Urg data pnter -with sliding window
RST, SYN, FIN: Options (variable length)
Flag for special
segment
application
data
(variable length)

58
How TCP provide reliable service?
 In order to assure if data arrives to
destination:
 Seq. #
 Ack
 TCP cycle life:
 Connection establishing
 3 steps
 Data transmission
 Close connection
59
TCP sequence numbers, ACKs
outgoing segment from sender
Sequence numbers: source port # dest port #
sequence number
• byte stream “number” of acknowledgement number

first byte in segment’s data checksum

rwnd
urg pointer

window size
Acknowledgements: N

• seq # of next byte expected

from other side sender sequence number space

• cumulative ACK sent sent, not- usable not

ACKed yet ACKed but not usable
Q: how receiver handles out-of- (“in-flight”) yet sent

order segments outgoing segment from receiver

• A: TCP spec doesn’t say, - up

source port # dest port #
sequence number
to implementor acknowledgement number
A rwnd
checksum urg pointer

60
TCP sequence numbers, ACKs
Host A Host B

User types‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs receipt
of‘C’, echoes back ‘C’
Seq=79, ACK=43, data = ‘C’
host ACKs receipt
of echoed ‘C’
Seq=43, ACK=80

simple telnet scenario

61
TCP: retransmission scenarios
Host A Host B Host A Host B

SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

timeout

timeout
ACK=100
X
ACK=100
ACK=120

Seq=92, 8 bytes of data Seq=92, 8

SendBase=100 bytes of data send cumulative
SendBase=120 ACK for 120
ACK=100
ACK=120

SendBase=120

lost ACK scenario premature timeout

62
TCP: retransmission scenarios
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

ACK=100
X
ACK=120

Seq=120, 15 bytes of data

cumulative ACK covers

for earlier lost ACK

63
TCP fast retransmit
Host A Host B
TCP fast retransmit
if sender receives 3 additional
ACKs for same data (“triple
duplicate ACKs”), resend
unACKed segment with X
smallest seq #
 likely that unACKed segment
lost, so don’t wait for timeout

timeout
Receipt of three duplicate
ACKs indicates 3 segments Seq=100, 20 bytes of data

received after a missing

segment – lost segment is
likely. So retransmit!

64
 Connection establishing in TCP :
3 steps (3-way handshake)
 Step 1: A sends SYN to B
A B  Indicate initial value of seq # of
A
 No data
 Step 2: B receives SYN, replies
by SYNACK
 B initiates the buffer on its side
 Indicate initial value of seq. # of
B
 Step 3: A receives SYNACK,
replies ACK, maybe with data.

65
 Close connection
 Step 1: Send FIN to B A B
 Step 2: B receives FIN, replies
ACK, closes the connection closing
and sends FIN.
 Step 3: A receives FIN, replies
ACK, go to “waiting”. closing

 Bước 4: B receives ACK.

close connection
timed wait
closed

closed
66
 Symplified life cycle of TCP
Client application
Initiates a TCP connection Server application
Creates a listen socket
CLOSED
Wait 30 sec. Receive ACK
CLOSED
Send nothing
Send SYN

TIME_WAIT SYN_SENT LAST_ACK LISTEN

Receive FIN Receive SYN/ACK Receive SYN

Send ACK Send ACK Send FIN Send SYN/ACK

FIN_WAIT_2 ESTABLISHED CLOSE_WAIT SYN_RCVD

Send FIN
Receive ACK
Send nothing Receive FIN Receive ACK
FIN_WAIT_1 Send ACK ESTABLISHED Send nothing

Client application
Initiates close connection 67
Flow control in TCP

68
TCP flow control
application
Q: What happens if network Application removing
process

layer delivers data faster data from TCP socket

buffers
than application layer TCP socket
removes data from socket receiver buffers
buffers?
TCP
code
Network layer
delivering IP
datagram payload
into TCP socket IP
code
buffers

from sender

receiver protocol stack

69
TCP flow control
application
Q: What happens if network Application removing
process

layer delivers data faster data from TCP socket

buffers
than application layer TCP socket
removes data from socket receiver buffers
buffers?
TCP
code
Network layer
delivering IP
datagram payload
into TCP socket IP
code
buffers

from sender

receiver protocol stack

70
TCP flow control
application
Q: What happens if network Application removing
process

layer delivers data faster data from TCP socket

buffers
than application layer TCP socket
removes data from socket receiver buffers
buffers?
TCP
code

receive window
flow control: # bytes
receiver willing to accept IP
code

from sender

receiver protocol stack

71
TCP flow control
application
Q: What happens if network Application removing
process

layer delivers data faster data from TCP socket

buffers
than application layer TCP socket
removes data from socket receiver buffers
buffers?
TCP
flow control code

receiver controls sender, so

sender won’t overflow IP
code
receiver’s buffer by
transmitting too much, too
fast from sender

receiver protocol stack

72
TCP flow control

 Size of free buffer

= Rwnd
= RcvBuffer-[LastByteRcvd
- LastByteRead]

73
Information exchanged on
Rwnd
A B
 Receiver inform
regularly to senders
the value of Rwnd in
acknowledgment
segments

74
Congestion control in TCP

75
Principles of congestion control
Congestion:
 informally: “too many sources sending too much data too fast for
network to handle”
 manifestations:
• long delays (queueing in router buffers)
• packet loss (buffer overflow at routers)
 different from flow control! congestion
 a top-10 problem! control: too many
senders, sending too fast

flow control: one sender

too fast for one receiver

Congestion
occur
76
TCP congestion control: AIMD
 approach: senders can increase sending rate until packet loss
(congestion) occurs, then decrease sending rate on loss event
Additive Increase Multiplicative Decrease
increase sending rate by 1 cut sending rate in half at
maximum segment size every each loss event
RTT until loss detected

AIMD sawtooth
TCP sender Sending

behavior: probing
rate

for bandwidth

time

77
TCP AIMD: more
Multiplicative decrease detail: sending rate is
 Cut in half on loss detected by triple duplicate ACK (TCP Reno)
 Cut to 1 MSS (maximum segment size) when loss detected by
timeout (TCP Tahoe)

Why AIMD?
 AIMD – a distributed, asynchronous algorithm – has been
shown to:
• optimize congested flow rates network wide!
• have desirable stability properties

78
TCP congestion control: details
sender sequence number space
cwnd TCP sending behavior:
 roughly: send cwnd bytes,
wait RTT for ACKS, then
send more bytes
last byte
available but cwnd
ACKed sent, but not- TCP rate ~
~ bytes/sec
yet ACKed not used RTT
(“in-flight”) last byte sent

 TCP sender limits transmission: LastByteSent- LastByteAcked< cwnd

 cwnd is dynamically adjusted in response to observed

network congestion (implementing TCP congestion control)

79
TCP slow start
Host A Host B
 when connection begins,
increase rate exponentially
until first loss event:

RTT
• initially cwnd = 1 MSS
• double cwnd every RTT
• done by incrementing cwnd
for every ACK received
 summary: initial rate is
slow, but ramps up
exponentially fast time

80
TCP: from slow start to congestion
avoidance
Q: when should the exponential
increase switch to linear?
X
A: when cwnd gets to 1/2 of its
value before timeout.

Implementation:
 variable ssthresh
 on loss event, ssthresh is set to
1/2 of cwnd just before loss event

81
Congestion control – illustration
cwnd

22
Timeout
20

18
Threshold=16 Threshold is set to half of cwnd (20)
16 And slow start starts
14
3 ACKs
12 SS
Threshold=10 Threshold is set to half of cwnd (12)
10
AI And additive increase starts
8
SS
6
AI Threshold=6

4
AI
2

Step
82
Exercise
 Assume that we need transmit 1 file
 File size O =100KB over TCP connection
 S is the size of each TCP segment, S = 536 byte
 RTT = 100 ms.
 Assume that the congestion window size of
TCP is fixed with value W.
What is the minimum transmission time? If the
transmission speed is
 R = 10 Mbit/s;
 R= 100 Mbits/s. 83
Solution (cont.)
 T transmit (W packet) = W * S/R
 Transmit without waiting:
 => (W-1)*S/R >= RTT
 => W >= RTT*R/S +1
 Time to transmit all data L = L/R + RTT
 R=100 Mbps
 W>= 100ms * 100 Mbps/ (536*8) + 1

84
 Exercise
 Assume that we need transmit 1 file
 File size O =100KB over TCP connection
 S is the size of each TCP segment, S = 536 byte
 RTT = 100 ms.
 Assume that the congestion window of TCP works
according to slow-start mechanism.
 What is the size of the congestion window when the
whole file is transmited.
 How much of time is required for transmitting the file?
If R = 10 Mbit/s; R= 100 Mbits/s.
85