COMP 3234B
Computer and Communication Networks
2nd semester 2020-2021
Transport Layer (III)
Prof. C Wu
Department of Computer Science The University of Hong Kong
Roadmap
Transport layer
Principles behind transport-layer services
multiplexing/demultiplexing (ILO1, 2) reliable data transfer:(ILO 2, 3)
rdt 1.0
rdt 2.0, 2.1, 2.2 rdt 3.0
GBN
selective repeat
Transport protocols in the Internet (ILO 2, 3) TCP: RDT, flow control, congestion control UDP
application
ttransporrtt
network
link
physical
TCP: overview
RFCs: 793, 1122, 1323, 2018, 2581
Connection-oriented
handshaking (exchange of control msgs) before data exchange
Flow and congestion controlled
sender will not overwhelm receiver
sender adjusts sending rate upon detecting congestion
Point-to-point
one sender, one receiver
Reliable data transfer
in-order byte steam
Pipelined transfer
TCP congestion control and flow control (set window size)
Full duplex service
bi-directional data flow in same connection
TCP: segment structure
used for explicit congestion notification
count in 32-bit words
whether ack number is valid
indicate urgent data in segment
push data to upper layer immediately
location of last byte of urgent data
generally not used
32 bits
counting
by bytes
of data
(not segments!)
# of bytes receiver willing to accept
for connection setup and teardown
variable length, used for sender/receiver negotiation of MSS, etc.
MSS (maximum segment size)
The maximum amount of application-layer data in a segment
TCP: seq. #’s and ACKs
TCP views data as ordered stream of bytes
Seq. #
byte-stream number of first byte in segment’s data
outgoing segment from sender
window size N
sender sequence number space
source port #
dest port #
sequence number
acknowledgement number
rwnd
checksum
urg pointer
not number of segments
initial seq. # is randomly chosen
ACK #
seq. # of next byte expected from the other side
cumulative ACK
acknowledges bytes up to the first missing byte ACK piggybacked in data segments
sent ACKed
sent, not- yet ACKed (“in- flight”)
usable not but not usable yet sent
incoming segment to sende
source port #
dest port #
sequence number
acknowledgement number
A
rwnd
checksum
urg pointer
How does receiver handle out-of-order bytes: discard or buffer?
TCP RFCs do not specify
up to implementor
in practice, buffer (as in Selective Repeat)
TCP: seq. #’s and ACKs (an example)
Telnet
application-layer protocol for remote login runs over TCP
Host A
Host B
host ACKs receipt of ‘C’, echoes back ‘C’
User types ‘C’
host ACKs receipt of echoed ‘C’
simple telnet scenario
time
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
TCP reliable data transfer
TCP creates reliable data transfer service on top of IP’s unreliable best-effort service
Selective repeat or go-back-N? A hybrid.
Pipelined segments
Cumulative acks
Uses single retransmission timer Retransmissions are triggered by:
timeout events
duplicate acks
TCP RDT: simplified sender
L
NextSeqNum = InitialSeqNum SendBase = InitialSeqNum
event
ACK received, with ACK field value y
data received from application above
create segment, seq. #: NextSeqNum
pass segment to IP (i.e., “send”) NextSeqNum = NextSeqNum + length(data) if (timer currently not running)
start timer
timeout
retransmit not-yet-acked segment with smallest seq. #
start timer
wait for
if (y > SendBase) {
SendBase = y
/* SendBase–1: last cumulatively ACKed byte */ if (there are currently not-yet-acked segments)
start timer else stop timer
}
ack correctly received
If acknowledging previously unacked segments
advance send_base to next unacked seq. # start timer if there are unacked segments
data received from app layer
create segment with seq. # start timer if not already running
timer is for oldest unacked segment
timeout
retransmit oldest segment that is not acked
restart timer
TCP RDT: retransmission scenarios
Host A Host B
Host A Host B
SendBase=92
SendBase=92
SendBase=100
Seq=92, 8 bytes of data
ACK=100
X
Seq=92, 8 bytes of data
ACK=100
lost ACK scenario
SendBase=100 SendBase=120
SendBase=120
Seq=92, 8 bytes of data
Seq=100, 20 bytes of data
ACK=100
ACK=120
ACK=120
premature timeout
Seq=92, 8 bytes of data
timeout
timeout
TCP RDT: retransmission scenarios
Host A
Host B
SendBase=92
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
SendBase=120
stop timer on seq=92 segment start time on seq=120 segent
timeout
TCP RDT: receiver
TCP ACK Generation Recommendation [RFC 5681]
Event at Receiver
TCP Receiver action
Arrival of in-order segment with expected seq #. All data up to expected seq # already ACKed
Delayed ACK. Wait up to 500ms for another in-order segment. If no next segment, send an ACK.
Arrival of in-order segment with expected seq #. One other segment has ACK pending.
Immediately send single cumulative ACK, ACKing both in-order segments.
Arrival of out-of-order segment higher- than-expect seq. # . Gap detected.
Immediately send duplicate ACK, indicating seq. # of next expected byte.
Arrival of segment that partially or completely fills gap
Immediate send ACK, provided that segment starts at lower end of gap
TCP RDT: fast retransmit
Detect lost segments via timeouts
timeout period often relatively long => long delay before resending lost packet
Detect lost segments via duplicate ACKs
sender often sends many segments back-to-back
if segment is lost, there will likely be many duplicate ACKs.
TCP fast retransmit: if sender receives 3 duplicate ACKs for the same data, it supposes that segment after ACKed
data was lost, and resends segment before timeout
a duplicate ACK for already ACKed segment
fast retransmit
event: ACK received, with ACK field value of y if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer }else stop time
else { //y=SendBase
increment count of dup ACKs received for y if (count of dup ACKs received for y = 3) {
resend segment with sequence number y }
Seq=92, 8 bytes of data
ACK=100
TCP RDT: fast retransmit (cont’d)
TCP sender with fast retransmit:
the following code replaces ACK received event on slide 8
Host A
Host B
SendBase=92
SendBase=100
Seq=100, 20 bytes of data
X
ACK=100
ACK=100 ACK=100
Seq=100, 20 bytes of data
fast retransmit after sender receipt of triple duplicate ACK
timeout
TCP flow control
Receiver side of TCP connection has a receive buffer:
application process
TCP socket receiver buffers
TCP code
IP code
Application process may be slow at reading from buffer
Flow control
sender won’t overflow receiver’s buffer by sending too much, too fast speed-matching service
matching the sending rate to the receiving app’s drain rate
application may remove data from TCP socket buffers ….
… may be slower than TCP receiver is delivering (sender is sending)
application OS
from sender
receiver protocol stack
TCP flow control (cont’d)
How TCP flow control works
At TCP receiver
spare room in buffer = RcvWindow = RcvBuffer- [LastByteRcvd – LastByteRead]
Receiver advertises spare room by including value of current RcvWindow in segments to sender
RcvBuffer size can be set via socket options Sender limits unACKed data to RcvWindow
guarantees receive buffer does not overflow
LastByteRcvd LastByteRead
TCP connection management: three-way handshake
Recall: TCP sender, receiver establish “connection” before exchanging data segments
How?
client: connection initiator clientSocket.connect(
(serverName, serverPort) )
server: contacted by client connectionSocket, addr =
serverSocket.accept()
Why?
initialize TCP variables:
seq. #s
RcvBuffer size at client,
server
Three-way handshake
Step 1: client host sends TCP SYN segment to server
★ specifies client initial seq # ★ no data
Step 2: server host receives SYN, replies with SYNACK segment
★ server allocates buffers
★ specifies server initial seq. #
Step 3: client receives SYNACK, replies with ACK segment, which may contain data
TCP connection management: closing a connection
Closing a connection (socket.close())
Step 1: client sends TCP FIN control segment (FIN bit is 1) to server
Step 2: server receives FIN, replies with ACK. Closing connection, sends FIN. Step 3: client receives FIN, replies with ACK.
Enters “timed wait” – will respond with ACK to received FINs Step 4: server, receives ACK. Connection closed.
client state
FIN_WAIT_1
FIN_WAIT_2
TIMED_WAIT
can no longer send but can receive data
wait for server close
FINbit=1, seq=x
ACKbit=1; ACKnum=x+1
FINbit=1, seq=y ACKbit=1; ACKnum=y+1
can still send data
server state
CLOSE_WAIT
LAST_ACK
CLOSED
can no longer send data
timed wait
for 2*max
(waiting time is
segment lifetime
implementation dependent)
CLOSED
TCP server lifecycle
TCP client lifecycle
Required Reading:
Computer Networking: A Top-Down Approach (7th Edition)
Ch 3.5.1, 3.5.2, 3.5.4, 3.5.5, 3.5.6
Acknowledgement:
Some materials are extracted from the slides created by Prof. Jim F. Kurose and Prof. Keith W. Ross for the textbook.