1. These slides are adapted from Kurose and Ross
Transport Layer
Abusayeed Saifullah
CS 5600 Computer Networks
These slides are adapted from Kurose and Ross

2. TCP: closing a connection
Connection release is easy but needs care
Asymmetric release
is the way the telephone system works:
when one party hangs up, the connection is broken.
Symmetric release
treats the connection as two separate unidirectional connections and
requires each one to be released separately.

3. Asymmetric Release Abrupt disconnection with loss of data 
CR: connection request
DR: disconnect request
Abrupt disconnection with loss of data 
needs better protocol

4. Symmetric release
Symmetric release does the job when each process has a fixed amount of data to send and clearly knows when it has sent it.
One can envision a protocol in which host 1 says ‘‘I am done. Are you done too?’’ If host 2 responds: ‘‘I am done too. Goodbye, the connection can be safely released.’’
Unfortunately, this protocol does not always work: two-army problem.

5. Two-army problem

6. Two-army problem A white army is encamped in a valley.
On both surrounding hillsides are blue armies.
The white army is larger than either of the blue armies alone, but together the blue armies are larger than the white army.
If either blue army attacks by itself, it will be defeated, but if the two blue armies attack simultaneously, they will be victorious.

7. Two-army problem The blue armies want to synchronize their attacks.
However, their only communication medium is to send messengers on foot down into the valley, where they might be captured and the message lost (i.e., they have to use an unreliable communication channel).
The question is: does a protocol exist that allows the blue armies to win?

8. Two-army problem Answer: no protocol exists that works.
Relevance to connection release
substitute ‘‘disconnect’’ for ‘‘attack.’’
If neither side is prepared to disconnect until it is convinced that the other side is prepared to disconnect too, the disconnection will never happen.

9. solution to close a TCP connection
In practice, we can avoid this quandary by foregoing the need for agreement and letting each side independently decide when it is done.
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
While this protocol is not infallible, it is usually adequate.

10. solution to close a TCP 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
CLOSED
ACKbit=1; ACKnum=y+1

11. Roadmap 1 transport-layer services 2 multiplexing and demultiplexing
3 connectionless transport: UDP
4 connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
5 principles of congestion control
6 TCP congestion control

12. 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!

13. 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

14. 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

15. 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

16. 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

17. 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 retransmitted 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

18. 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

19. 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

20. 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

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

22. 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
Already studied

23. Roadmap 1 transport-layer services 2 multiplexing and demultiplexing
3 connectionless transport: UDP
4 connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
5 principles of congestion control
6 TCP congestion control

24. 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 (congestion window) 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

25. TCP Congestion Control: details
sender sequence number space
TCP sending rate:
roughly: send cwnd bytes, wait RTT for ACKS, then send more bytes
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

26. 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

27. 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)

28. TCP: switching from slow start 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 (slow start threshold)
on loss event, ssthresh is set to 1/2 of cwnd just before loss event

29. TCP: switching from slow start to CA
the threshold is initially equal to 8 MSS.
For the first eight transmission rounds, Tahoe and Reno take identical actions.
The congestion window climbs exponentially fast during slow start and hits the threshold at the fourth round of transmission.
The congestion window then climbs linearly until a triple duplicate- ACK event occurs, just after transmission round 8.

30. TCP: switching from slow start to CA
Note that the congestion window is 12 • MSS when this loss event occurs.
ssthresh is then set to 0.5 • cwnd = 6 • MSS.
Under TCP Reno, the congestion window is set to cwnd = 6 • MSS and then grows linearly.
Under TCP Tahoe, the congestion window is set to 1 MSS and grows exponentially until it reaches the value of ssthresh, at which point it grows linearly.

31. Consider sending a large file from a host to another over a TCP connection that has no loss.
Suppose TCP uses AIMD for its congestion control without slow start. Assuming cwnd increases by 1 MSS every time a batch of ACKs is received and assuming approximately constant round-trip times, how long does it take for cwnd increase from 6 MSS to 12 MSS (assuming no loss events)? What is the average throughout (in terms of MSS and RTT) for this connection
up through time = 6 RTT?

32. TCP throughput avg. TCP throughput 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

33. 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

34. 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

35. Fairness (more) Fairness and UDP Fairness, parallel TCP connections
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
Problem with UDP? Firewall blocks  use TCP
Fairness, parallel TCP connections
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