1. 2017 session 1 TELE3118: Network Technologies Week 10: Transport Layer TCP
Slides have been adapted from:
Computer Networking: A Top Down Approach, 7th (global) edition. Jim Kurose, Keith Ross. Pearson, April All material copyright J.F Kurose and K.W. Ross, All Rights Reserved.
Computer Networks, 5th edition. Andrew S. Tanenbaum, David J. Wetherall, Pearson, 2010.
Transport Layer

2. Principles of congestion control
informally: “too many sources sending too much data too fast for network to handle”
different from flow control!
manifestations:
lost packets (buffer overflow at routers)
long delays (queueing in router buffers)
a top-10 problem!
Transport Layer

3. Causes/costs of congestion: scenario 1
original data: lin
throughput: lout
two senders, two receivers
one router, infinite buffers
output link capacity: R
no retransmission
Host A
unlimited shared output link buffers
Host B
R/2
delay
lin
R/2
lout
lin
maximum per-connection throughput: R/2
large delays as arrival rate, lin, approaches capacity
Transport Layer

4. Causes/costs of congestion: scenario 2
one router, finite buffers
sender retransmission of timed-out packet
application-layer input = application-layer output: lin = lout
transport-layer input includes retransmissions : lin lin ‘
lin : original data
lout
l'in: original data, plus retransmitted data
Host A
finite shared output link buffers
Host B
Transport Layer

5. Causes/costs of congestion: scenario 2
lout
lin
idealization: perfect knowledge
sender sends only when router buffers available
lin : original data
lout
copy
l'in: original data, plus retransmitted data A
free buffer space!
finite shared output link buffers
Host B
Transport Layer

6. Causes/costs of congestion: scenario 2
Idealization: known loss packets can be lost, dropped at router due to full buffers
sender only resends if packet known to be lost
lin : original data
lout
copy
l'in: original data, plus retransmitted data A
no buffer space!
Host B
Transport Layer

7. Causes/costs of congestion: scenario 2
Idealization: known loss packets can be lost, dropped at router due to full buffers
sender only resends if packet known to be lost
R/2
lin
lout
when sending at R/2, some packets are retransmissions but asymptotic goodput is still R/2 (why?)
lin : original data
lout
l'in: original data, plus retransmitted data A
free buffer space!
Host B
Transport Layer

8. Causes/costs of congestion: scenario 2
Realistic: duplicates
packets can be lost, dropped at router due to full buffers
sender times out prematurely, sending two copies, both of which are delivered
R/2
when sending at R/2, some packets are retransmissions including duplicated that are delivered!
lout
lin
R/2
timeout
lin
lout
copy
l'in A
free buffer space!
Host B
Transport Layer

9. Causes/costs of congestion: scenario 2
Realistic: duplicates
packets can be lost, dropped at router due to full buffers
sender times out prematurely, sending two copies, both of which are delivered
R/2
when sending at R/2, some packets are retransmissions including duplicated that are delivered!
lout
lin
R/2
“costs” of congestion:
more work (retrans) for given “goodput”
unneeded retransmissions: link carries multiple copies of pkt
decreasing goodput
Transport Layer

10. Causes/costs of congestion: scenario 3
Q: what happens as lin and lin’ increase ?
four senders
multihop paths
timeout/retransmit
A: as red lin’ increases, all arriving blue pkts at upper queue are dropped, blue throughput g 0
Host A
lout
lin : original data
Host B
l'in: original data, plus retransmitted data
finite shared output link buffers
Host D
Host C
Transport Layer

11. Causes/costs of congestion: scenario 3
lout
lin’
C/2
another “cost” of congestion:
when packet dropped, any “upstream transmission capacity used for that packet was wasted!
Transport Layer

12. Approaches towards congestion control
Two broad approaches towards congestion control:
End-end congestion control:
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 (SNA, DECbit, TCP/IP ECN, ATM)
explicit rate sender should send at
Transport Layer

13. TCP Congestion Control
end-end control (no network assistance)
sender limits transmission:
LastByteSent-LastByteAcked
 CongWin
Roughly,
cwnd is dynamic, function of perceived network congestion
How does sender perceive congestion?
loss event = timeout or 3 duplicate acks
TCP sender reduces rate (cwnd) after loss event
three mechanisms:
AIMD
slow start
conservative after timeout events
rate =
cwnd
RTT
Bytes/sec
Transport Layer

14. TCP congestion control: additive increase multiplicative decrease
approach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs
additive increase: increase cwnd by 1 MSS every RTT until loss detected
multiplicative decrease: cut cwnd in half after loss
additively increase window size …
…. until loss occurs (then cut window in half)
AIMD saw tooth
behavior: probing
for bandwidth
congestion window size
cwnd: TCP sender
time
Transport Layer

15. TCP Congestion Control: details
TCP sending rate:
roughly: send cwnd bytes, wait RTT for ACKS, then send more bytes
sender sequence number space
cwnd
last byte
ACKed
last byte sent
sent, not-yet ACKed
(“in-flight”)
cwnd
RTT
sender limits transmission:
cwnd is dynamic, function of perceived network congestion
rate ~
bytes/sec
LastByteSent-
LastByteAcked
<
cwnd
Transport Layer

16. TCP Slow Start
Host A
Host B
when connection begins, increase rate exponentially until first loss event:
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
one segment
RTT
two segments
four segments
time
Transport Layer

17. TCP: detecting, reacting to loss
loss indicated by timeout:
cwnd set to 1 MSS;
window then grows exponentially (as in slow start) to threshold, then grows linearly
loss indicated by 3 duplicate ACKs: TCP RENO
dup ACKs indicate network capable of delivering some segments
cwnd is cut in half window then grows linearly
TCP Tahoe always sets cwnd to 1 (timeout or 3 duplicate acks)
Transport Layer

18. TCP: switching from SS to CA
Q: when should the exponential increase switch to linear?
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
* Check out the online interactive exercises for more examples:
Transport Layer

19. Summary: TCP Congestion Control
New
ACK!
congestion
avoidance
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
transmit new segment(s), as allowed
new ACK .
dupACKcount++
duplicate ACK
slow
start
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
cwnd = cwnd+MSS
transmit new segment(s), as allowed
new ACK
dupACKcount++
duplicate ACK L
ssthresh = 64 KB L
cwnd > ssthresh
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
ssthresh= cwnd/2
cwnd = ssthresh + 3
retransmit missing segment
dupACKcount == 3
timeout
ssthresh = cwnd/2
cwnd = 1
dupACKcount = 0
cwnd = ssthresh
dupACKcount = 0
New ACK
ssthresh= cwnd/2
cwnd = ssthresh + 3
retransmit missing segment
dupACKcount == 3
fast
recovery
cwnd = cwnd + MSS
transmit new segment(s), as allowed
duplicate ACK
Transport Layer

20. TCP throughput avg. TCP thruput as function of window size, RTT?
ignore slow start, assume always data to send
W: window size (measured in bytes) where loss occurs
avg. window size (# in-flight bytes) is ¾ W
avg. thruput is 3/4W per RTT
avg TCP thruput = 3 4 W
RTT
bytes/sec W
W/2
Transport Layer

21. TCP Futures: TCP over “long, fat pipes”
example: 1500 byte segments, 100ms RTT, want 10 Gbps throughput
requires W = 83,333 in-flight segments
throughput in terms of segment loss probability, L [Mathis 1997]:
➜ to achieve 10 Gbps throughput, need a loss rate of L = 2· – a very small loss rate!
new versions of TCP for high-speed
TCP throughput =
1.22 .
MSS
RTT L
Transport Layer

22. 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
bottleneck
router
capacity R
TCP connection 2
Transport Layer

23. Why is TCP fair? two competing sessions:
additive increase gives slope of 1, as throughout increases
multiplicative decrease decreases throughput proportionally R
equal bandwidth share
loss: decrease window by factor of 2
congestion avoidance: additive increase
Connection 2 throughput
loss: decrease window by factor of 2
congestion avoidance: additive increase
Connection 1 throughput R
Transport Layer

24. Fairness (more) Fairness, parallel TCP connections Fairness and UDP
application can open multiple parallel connections between two hosts
web browsers do this
e.g., link of rate R with 9 existing connections:
new app asks for 1 TCP, gets rate R/10
new app asks for 11 TCPs, gets R/2
Fairness and UDP
multimedia apps often do not use TCP
do not want rate throttled by congestion control
instead use UDP:
send audio/video at constant rate, tolerate packet loss
Transport Layer

25. Explicit Congestion Notification (ECN)
network-assisted congestion control:
two bits in IP header (ToS field) marked by network router to indicate congestion
congestion indication carried to receiving host
receiver (seeing congestion indication in IP datagram) ) sets ECE bit on receiver-to-sender ACK segment to notify sender of congestion
TCP ACK segment
source
destination
application
transport
network
link
physical
application
transport
network
link
physical
ECE=1
ECN=11
ECN=11
ECN=00
IP datagram
Transport Layer

26. TCP flow control flow control
application
process
application may
remove data from
TCP socket buffers ….
application OS
TCP socket
receiver buffers
… slower than TCP
receiver is delivering
(sender is sending)
TCP
code IP
code
receiver controls sender, so sender won’t overflow receiver’s buffer by transmitting too much, too fast
flow control
from sender
receiver protocol stack
Transport Layer

27. TCP flow control
receiver “advertises” free buffer space by including rwnd value in TCP header of receiver-to-sender segments
RcvBuffer size set via socket options (typical default is 4096 bytes)
many operating systems autoadjust RcvBuffer
sender limits amount of unacked (“in-flight”) data to receiver’s rwnd value
guarantees receive buffer will not overflow
to application process
buffered data
free buffer space
RcvBuffer
rwnd
TCP segment payloads
receiver-side buffering
Transport Layer

28. Connection Management
before exchanging data, sender/receiver “handshake”:
agree to establish connection (each knowing the other willing to establish connection)
agree on connection parameters
application
application
connection state: ESTAB
connection variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client
connection state: ESTAB
connection Variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client
network
network
Socket clientSocket =
newSocket("hostname","port number");
Socket connectionSocket = welcomeSocket.accept();
Transport Layer

29. Agreeing to establish a connection
2-way handshake:
Q: will 2-way handshake always work in network?
variable delays
retransmitted messages (e.g. req_conn(x)) due to message loss
message reordering
can’t “see” other side
Let’s talk
ESTAB OK
ESTAB
choose x
req_conn(x)
ESTAB
acc_conn(x)
ESTAB
Transport Layer

30. Agreeing to establish a connection
2-way handshake failure scenarios:
choose x
req_conn(x)
ESTAB
acc_conn(x)
client terminates
ESTAB
choose x
req_conn(x)
acc_conn(x)
data(x+1)
accept
connection
x completes
server
forgets x
retransmit
req_conn(x)
ESTAB
half open connection!
(no client!)
retransmit
req_conn(x)
ESTAB
data(x+1)
accept
client terminates
server
forgets x
connection
x completes
Transport Layer

31. TCP 3-way handshake client state server state LISTEN SYNSENT
SYNbit=1, Seq=x
choose init seq num, x
send TCP SYN msg
SYN RCVD
ESTAB
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
choose init seq num, y
send TCP SYNACK
msg, acking SYN
ACKbit=1, ACKnum=y+1
received SYNACK(x)
indicates server is live;
send ACK for SYNACK;
this segment may contain
client-to-server data
received ACK(y)
indicates client is live
ESTAB
Transport Layer

32. TCP 3-way handshake: FSM
closed
Socket connectionSocket = welcomeSocket.accept(); L
Socket clientSocket =
newSocket("hostname","port number");
SYN(x)
SYNACK(seq=y,ACKnum=x+1)
create new socket for
communication back to client
listen
SYN(seq=x)
SYN
rcvd
SYN
sent
SYNACK(seq=y,ACKnum=x+1)
ACK(ACKnum=y+1)
ACK(ACKnum=y+1)
ESTAB L
Transport Layer

33. TCP: closing a connection
client, server each close their side of connection
send TCP segment with FIN bit = 1
respond to received FIN with ACK
on receiving FIN, ACK can be combined with own FIN
simultaneous FIN exchanges can be handled
Transport Layer

34. TCP: closing a connection
client state
server state
ESTAB
ESTAB
FIN_WAIT_1
FINbit=1, seq=x
can no longer
send but can
receive data
clientSocket.close()
CLOSE_WAIT
FIN_WAIT_2
ACKbit=1; ACKnum=x+1
wait for server
close
can still
send data
can no longer
send data
LAST_ACK
TIMED_WAIT
FINbit=1, seq=y
CLOSED
timed wait
for 2*max
segment lifetime
CLOSED
ACKbit=1; ACKnum=y+1
Transport Layer