1. Internet and Intranet Protocols and Applications
Lecture 2: The Transport Layer in the Internet
January 18, 2005
Arthur Goldberg
Computer Science Department
New York University
9/19/2018

2. Internet Transport Protocols
Two Transport Protocols Available
Transmission Control Protocol (TCP)
connection oriented
most applications use TCP
User Datagram Protocol (UDP)
connectionless
9/19/2018

3. Transport layer addressing
Communications endpoint addressed by:
IP address (32 bit) in IP Header
Port number (16 bit) in TP Header1
Transport protocol (TCP or UDP) in IP Header
1 TP => Transport Protocol (UDP or TCP)
9/19/2018

4. Some standard services and port numbers
(last updated )
9/19/2018

5. UDP: User Datagram Protocol [RFC 768]
“no frills,” “bare bones” Internet transport protocol
“best effort” service, UDP segments may be:
lost
delivered out of order to the application
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
9/19/2018

6. UDP Port Management Source (client) Destination
Obtains a free port number
Specifies port of destination (server)
Destination
Receives datagram
Sends datagram to destination IP:port
Can send replies to source IP:port
9/19/2018

7. UDP: more often used for streaming multimedia apps loss tolerant
rate sensitive
other UDP uses (why?):
DNS
SNMP
reliable transfer over UDP: add reliability at application layer
application-specific error recover!
32 bits
source port #
dest port #
Length, in
bytes of UDP
segment,
including
header
length
checksum
Application
data
(message)
UDP segment format
9/19/2018

8. UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
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 may be errors nonetheless? More later ….
9/19/2018

9. Transmission Control Protocol (TCP)
Connection-oriented service
Point-to-point
Full-duplex communication
Stream interface (no message boundary!)
Stream divided into segments for transmission
Each segment encapsulated in IP datagram
Uses protocol ports to identify applications
9/19/2018

10. TCP Port Management When a connection is established
Source (client)
Obtains a free port number
Specifies IP:port of destination (server)
Destination
Receives connection request
Sends data to destination IP:port
The 4-tuple (source IP:port, destination IP:port) identifies where data goes
9/19/2018

11. TCP Segment Sequence number specifies where in stream data belongs
Few segments contain options
TF 6-24
9/19/2018

12. TCP Segment Format Segment divided into two parts Header
Payload area (zero or more bytes of data)
Header contains
Protocol port numbers to identify
Sending application
Receiving application
Bits to specify items such as
SYN
FIN
ACK
Fields for window advertisement, acknowledgment, etc.
9/19/2018

13. Reliability in an Unreliable World
IP offers best-effort (unreliable) delivery
TCP uses IP
TCP provides completely reliable transfer
How is this possible? How can TCP realize:
Reliable connection startup?
Reliable data transmission?
Graceful connection shutdown?
9/19/2018

14. Reliable Data Transmission
Positive acknowledgment
Receiver returns short message when data arrives
Called acknowledgment
Retransmission
Sender starts timer whenever message is transmitted
If timer expires before acknowledgment arrives, sender retransmits message
9/19/2018

15. simple telnet scenario
TCP seq. #’s and ACKs
Seq. #’s:
byte stream “number” of first byte in segment’s data
ACKs:
seq # of next byte expected from other side
cumulative ACK
Q: how receiver handles out-of-order segments
A: TCP spec doesn’t say, - up to implementer
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
time
simple telnet scenario
9/19/2018

16. Timing Problem!
The delay required for data to reach a destination and an
acknowledgment to return depends on traffic in the internet as
well as the distance to the destination. Because it allows
multiple application programs to communicate with multiple
destinations concurrently, TCP must handle a variety of delays
that can change rapidly.
How does TCP handle this .....
9/19/2018

17. Solving Timing Problem
Keep estimate of round trip time on each connection
Use current estimate to set retransmission timer
Known as adaptive retransmission
Key to TCP’s success
9/19/2018

18. TCP Flow Control Receiver Sender
Advertises available buffer space
Called window
Sender
Can send up to entire window before ACK arrives
Each acknowledgment carries new window information
Called window advertisement
Can be zero (called closed window)
Interpretation: I have received up through X, and can take Y more octets
9/19/2018

19. TCP Flow Control flow control
receiver: explicitly informs sender of (dynamically changing) amount of free buffer space
RcvWindow field in TCP segment
sender: keeps the amount of transmitted, unACKed data less than most recently received RcvWindow
sender won’t overrun
receiver’s buffers by
transmitting too much,
too fast
RcvBuffer = size or TCP Receive Buffer
RcvWindow = amount of spare room in Buffer
receiver buffering
9/19/2018

20. Why Startup/ Shutdown Difficult?
Segments can be
Lost
Duplicated
Delayed
Delivered out of order
Either side can crash
Either side can reboot
Need to avoid duplicate ‘‘shutdown’’ message from affecting later connection
9/19/2018

21. TCP’s Startup/ Shutdown Solution
Uses three-message exchange known as 3-way handshake
Necessary and sufficient for
Unambiguous, reliable startup
Unambiguous, graceful shutdown
SYN used for startup, FIN used for shutdown
9/19/2018

22. TCP Connection Management (OPEN)
client
server
opening
SYN
opening
SYNACK
ACK
established
closed
9/19/2018

23. TCP Connection Management (CLOSE)
client
server
closing
FIN
ACK
closing
FIN
ACK
timed wait
closed
closed
9/19/2018

24. TCP Connection Management (cont)
TCP server
lifecycle
TCP client
lifecycle
9/19/2018

25. Transport Protocol Summary
Transport protocols fit between applications and Internet Protocol
Two transport protocols in TCP/IP suite
User Datagram Protocol (UDP)
Transmission Control Protocol (TCP)
UDP
Unreliable
Message-oriented interface
TCP
Major transport protocol used in Internet
Complete reliability
Stream-oriented interface
Uses adaptive retransmission
9/19/2018

26. Extra slides follow

27. 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!
9/19/2018

28. 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
9/19/2018

29. TCP Congestion Control
end-end control (no network assistance)
transmission rate limited by congestion window size, Congwin, over segments:
Congwin
w segments, each with MSS bytes sent in one RTT:
throughput =
w * MSS
RTT
Bytes/sec
9/19/2018

30. TCP congestion control:
“probing” for usable bandwidth:
ideally: transmit as fast as possible (Congwin as large as possible) without loss
increase Congwin until loss (congestion)
loss: decrease Congwin, then begin probing (increasing) again
two “phases”
slow start
congestion avoidance
important variables:
Congwin
threshold: defines threshold between two slow start phase, congestion control phase
9/19/2018

31. TCP Slowstart Slowstart algorithm initialize: Congwin = 1
Host A
Slowstart algorithm
Host B
one segment
initialize: Congwin = 1
for (each segment ACKed)
Congwin++
until (loss event OR
CongWin > threshold)
RTT
two segments
four segments
exponential increase (per RTT) in window size (not so slow!)
loss event: timeout (Tahoe TCP) and/or or three duplicate ACKs (Reno TCP)
time
9/19/2018

32. TCP Congestion Avoidance
/* slowstart is over */
/* Congwin > threshold */
Until (loss event) {
every w segments ACKed:
Congwin++ }
threshold = Congwin/2
Congwin = 1
perform slowstart 1
1: TCP Reno skips slowstart (fast
recovery) after three duplicate ACKs
9/19/2018

33. TCP Fairness
Fairness goal: if N TCP sessions share same bottleneck link, each should get 1/N of link capacity
TCP connection 1
bottleneck
router
capacity R
TCP
connection 2
9/19/2018

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
9/19/2018

35. More on Reliable Data Transfer
9/19/2018