1. Chapter 6-2 The Transport Layer
TCP, UDP and Performance Issues
TANENBAUM
Computer Networks II

2. The Internet Transport Protocols: UDP
Introduction to UDP
Remote Procedure Call
The Real-Time Transport Protocol
TANENBAUM
Computer Networks II

3. UDP (User Data Protocol)
Provides a way to send IP datagrams without establishing a connection
A UDP segment has 8-byte header followed by data
UDP length includes header and data
UDP checksum includes the same format pseudoheader as in TCP
TANENBAUM
Computer Networks II

4. Remote Procedure Call
Allows programs to call procedures located on remote hosts
Looks as much possible as local call
Two library procedures called client stub and server stub hide the fact that call is remote
The client program makes a local call to client stub to handle the RPC
Information is transported in parameters
For this purpose, client stub packs parameters into a message (parameter marshalling)
TANENBAUM
Computer Networks II

5. Steps in making a remote procedure call. The stubs are shaded.
TANENBAUM
Computer Networks II

6. Problems with RPC Passing pointers is impossible
Array size must be specified and fixed
It may not be possible to deduce the types of the parameters
Global variables can not be used
RPC commonly uses UDP
TANENBAUM
Computer Networks II

7. Real Time Transport Protocol (RTP)
Used to transport multimedia streams
Can multiplex different streams such as the audio and video into a single UDP socket
Each packet is given a unique increasing number
No flow control, no error control, no acks,no retransmission mechanism
Contains a payload type field to specify encoding that allows changing quality of the multimedia data when available bandwidth drops
Contains timestamps that are used to synchronize streams. However, these timestamps are used to compute the relative time from the start rather than absolute time
Has a sister protocol, Real Time Control Protocol (RTCP) that carries delay, jitter, bandwidth and congestion information for feedback purposes
TANENBAUM
Computer Networks II

8. The Real-Time Transport Protocol
(a) The position of RTP in the protocol stack. (b) Packet nesting.
TANENBAUM
Computer Networks II

9. The Real-Time Transport Protocol (2)
The RTP header.
TANENBAUM
Computer Networks II

10. The Internet Transport Protocols: TCP
Introduction to TCP
The TCP Service Model
The TCP Protocol
The TCP Segment Header
TCP Connection Establishment
TCP Connection Release
TCP Connection Management Modeling
TCP Transmission Policy
TCP Congestion Control
TCP Timer Management
Wireless TCP and UDP
Transactional TCP
TANENBAUM
Computer Networks II

11. TCP Basic Functionality
Provides reliable end-to-end byte stream over an unreliable internetwork
Transport entity
A piece of software that is either
A user process or
Part of kernel
Accepts user data streams from local processes
Breaks them into pieces not exceeding 64K bytes
Send each piece as an IP datagram
At the receiver, it reconstructs original byte streams
TANENBAUM
Computer Networks II

12. The TCP Service Model
The sender and receiver create end points called sockets
Each socket has
IP address
Port number (16 bit and local)
A socket may be used for multiple connections at the same time
Some port numbers are reserved
FTP: 21
Telnet: 23
TANENBAUM
Computer Networks II

13. The TCP Service Model Some assigned ports. Port Protocol Use 21 FTP
File transfer 23
Telnet
Remote login 25
SMTP 69
TFTP
Trivial File Transfer Protocol 79
Finger
Lookup info about a user 80
HTTP
World Wide Web
110
POP-3
Remote access
119
NNTP
USENET news
TANENBAUM
Computer Networks II

14. The TCP Service Model (2)
(a) Four 512-byte segments sent as separate IP datagrams.
(b) The 2048 bytes of data delivered to the application in a single READ CALL.
A TCP connection is a byte stream, not a message stream
Message boundaries are not preserved end to end
TANENBAUM
Computer Networks II

15. The TCP Service Model (cont’d)
When an application passes data to TCP, TCP may send it immediately or buffer it at its discretion
To force data out, applications can use PUSH flag, which tells TCP not to delay transmission
At the receiver side, the same effect can be obtained by using URGENT flag
However, at the receiver side, on the contrary of PUSH flag, URGENT flag causes an interrupt to the application (provides signaling)
TANENBAUM
Computer Networks II

16. The TCP Protocol
Every byte on a TCP connection has its own 32-bit sequence number to be used for acks and sliding window sequencing
Window mechanism has its own 32-bit header
Data is exchanged in form of segments
A segment consists of a 20-byte header and zero or more bytes
A segment must fit into a IP payload (65635 bytes) or Maximum Transfer Unit, MTU of the underlying network (further segmentation is a major problem)
Sliding window acks next expected sequence number
TANENBAUM
Computer Networks II

17. The TCP Segment Header
TANENBAUM
Computer Networks II
TCP Header.

18. The TCP Segment Header (2)
The pseudoheader included in the TCP checksum.
TANENBAUM
Computer Networks II

19. The TCP Segment Header (cont’d)
Every segment begins with a fixed format 20-byte header
Segments without any data are legal
Ack messages or other control messages
Ack: Next byte expected
Options
Specifies beginning of data
Urgent pointer specifies offset of urgent data when URG flag is set
ACK bit indicates that the ack field is valid
TANENBAUM
Computer Networks II

20. The TCP Segment Header (cont’d)
PSH flag indicates pushed data
RST flag indicates problem with connection
SYN flag indicates connection request or connection accepted together with ACK flag
FIN flag is used to release a connection
Window Size field indicates how many bytes can be accepted starting at the byte acknowledged.
Checksum is a control field on header, data and pseudo header that indicates portions of IP header
TANENBAUM
Computer Networks II

21. The TCP segment Header (cont’d)
Options
A host may specify the maximum TCP payload it is willing to accept
If not specified, the default is 536 bytes
Window scale option
In general 16 bit window size is not sufficient for current systems
This option scales up the window size
Selective Reject instead of go back n can be indicated via options field
TANENBAUM
Computer Networks II

22. TCP Connection Management
Server waits for an incoming connection by executing the LISTEN and ACCEPT primitives
Client executes CONNECT primitive
IP address, port number and options specified
Destination checks to see if a process has done a LISTEN on the indicated port
If not,request is rejected
If there is a process which has done a LISTEN, it is asked if it would accept the connection
If process rejects, destination sends a segment with RST set. If process accepts, request is acked
TANENBAUM
Computer Networks II

23. TCP Connection Establishment
6-31
(a) TCP connection establishment in the normal case.
(b) Call collision.
TANENBAUM
Computer Networks II

24. TCP Connection Management (cont’d)
If simultaneous connection request happens only one connection is established
TCP connections are full duplex
However, they are considered as two simplex connections and each of them is released independently
To release, a node sends a segment with FIN bit set and the other side acks the release
Same procedure is repeated for the other simplex connection.
TANENBAUM
Computer Networks II

25. TCP Connection Management (cont’d)
To avoid two-army problem, timers are used in release process
That is, if ack for release does not arrive on time, timer goes off and client releases the connection
After release, both sides wait for maximum packet lifetime to erase tables
TANENBAUM
Computer Networks II

26. TCP Connection Management Modeling
The states used in the TCP connection management finite state machine.
TANENBAUM
Computer Networks II

27. TCP Connection Management Modeling (2)
TCP connection management finite state machine. The heavy solid line is the normal path for a client. The heavy dashed line is the normal path for a server. The light lines are unusual events. Each transition is labeled by the event causing it and the action resulting from it, separated by a slash.
TANENBAUM
Computer Networks II

28. TCP Transmission Policy
Window management is not directly tied to acks as in data link protocols
Exclusive buffer messages manage the transmission
If no buffer at receiver, then no transmission by sender except
Urgent data may be sent
One byte segment can be sent to ask receiver to renounce its buffer status (to prevent deadlock)
TANENBAUM
Computer Networks II

29. TCP Transmission Policy
Window management in TCP.
TANENBAUM
Computer Networks II

30. TCP Transmission Policy (cont’d)
Sender and receiver are not forced to transmit or receive as soon as they receive data from the application. This improves performance as follows:
If one byte messages are sent (like in TELNET) then use NAGLE’s algorithm
Send first byte and keep the rest until ack comes back
As ack comes in send the rest and keep the further incoming bytes until ack is received
TANENBAUM
Computer Networks II

31. TCP Transmission Policy (2)
Silly Window Syndrome: Receive bytes one by one and send window messaging accordingly
TANENBAUM
Computer Networks II

32. TCP Transmission Policy (cont’d)
Clark’s Solution to Silly Window Syndrome
Prevent receiver from sending one byte updates and make it wait until decent amount of space available before it sends buffer messages
Sender may also pospone sending messages
Nagle’s Algorithm and Clark’s solution are complementary and they can be used at the same time
TANENBAUM
Computer Networks II

33. TCP Congestion Control
When congestion occurs, IP has limited effect on managing congestion
Most of the congestion control is done by TCP by cutting down the data rate
Indication of congestion
Timeouts
Packet discards
In fiber optic cable transmission errors are minimized so timeouts mainly due to congestion
TANENBAUM
Computer Networks II

34. Congestion Window
In addition to receiver’s buffer information, the sender also maintains a congestion window.
This is mainly due to the fact that even if receiver may have space for fast data transfer, network may not carry it due to congestion.
The number of bytes to be sent is the minimum of the two windows
TANENBAUM
Computer Networks II

35. TCP Congestion Control
(a) A fast network feeding a low capacity receiver.
(b) A slow network feeding a high-capacity receiver.
TANENBAUM
Computer Networks II

36. Slow Start Algorithm
Initialize the size of the congestion window to the maximum segment size
If no timeout occurs increase the size of the window by one segment and send again.
Repeat above n times. If no timeout, then increase the window by n segments.
Internet uses threshold in addition to the above algorithm
TANENBAUM
Computer Networks II

37. TCP Congestion Control (2)
An example of the Internet congestion algorithm.
TANENBAUM
Computer Networks II

38. TCP Timer Management: Retransmission Timer
When goes off, segment is retransmitted
Setting the timer value is much more difficult than that of data-link layer, beacuse the delay is not easily predictable
TCP uses a dynamic algorithm to solve this problem
For each connection, TCP maintains a variable called RTT (round trip time)
TANENBAUM
Computer Networks II

39. TCP Timer Management
(a) Probability density of ACK arrival times in the data link layer.
(b) Probability density of ACK arrival times for TCP.
TANENBAUM
Computer Networks II

40. Retransmission Timer (cont’d)
M: The time to receive ack
:Smoothing factor, usually 7/8
RTT=RTT+(1-)M
D=D+(1-)|RTT-M|
Timeout=RTT+4D
Karn’s Algorithm
Do not update RTT on any segments that have been retransmitted (difficult to figure out for what segment the ack is)
TANENBAUM
Computer Networks II

41. TCP Timers (cont’d) Persistence Timer Keepalive Timer Timed Wait
Used to prevent deadlock when buffer management messages are lost
Keepalive Timer
Check the other side if the line is idle for a long time
Timed Wait
Used to close the connection
TANENBAUM
Computer Networks II

42. Wireless TCP and UDP
In theory, transport protocol should be independent of the technology of the underlying network layer
However, if the transmission is wireless, performance of TCP degrades drastically
Wired connections
Timeouts are considered to be caused by congestion not by lost packets
Wireless Connections
Timeouts are primarily due to lost packets
TANENBAUM
Computer Networks II

43. Wireless TCP and UDP (cont’d)
Wired TCP Timeout
Slowdown to alleviate congestion
Wireless TCP Timeout
Retransmit as soon as possible
Indirect TCP
Split TCP connection into two separate connections
Sender-to-base station
Base station to mobile host
TANENBAUM
Computer Networks II

44. Splitting a TCP connection into two connections.
Wireless TCP and UDP
Splitting a TCP connection into two connections.
TANENBAUM
Computer Networks II

45. Indirect TCP Snooping Agent Wireless UDP
Observes and caches TCP segments going out to the mobile host and acknowledges coming back from it
When an ack for a segment to mobile host is late, it retransmits the segment to mobile host without telling anything to the source
Congestion control algorithm will never start unless there is congestion on the wired part
Wireless UDP
Stations should not expect reliability
TANENBAUM
Computer Networks II

46. Translational TCP
If RPC requires long replies, then UDP is not suitable and TCP becomes the choice
However, TCP requires nine packets and this not efficient
A variant of TCP called T/TCP (Translational TCP) solves this problem
Allows transfer of data during setup
TANENBAUM
Computer Networks II

47. Transitional TCP (a) RPC using normal TCP. (b) RPC using T/TCP.
TANENBAUM
Computer Networks II

48. Performance Issues Performance Problems in Computer Networks
Network Performance Measurement
System Design for Better Performance
Fast TPDU Processing
Protocols for Gigabit Networks
TANENBAUM
Computer Networks II

49. PERFORMANCE ISSUES: Performance Problems
Fast line-slow CPU
Broadcast storm
Power failure (RARP density when machines are up)
Lack of memory allocation
Timeouts set incorrectly
Bandwidth-delay product (BDP)
The receiver window should be at least BDP
Jitter
TANENBAUM
Computer Networks II

50. Performance Problems in Computer Networks
The state of transmitting one megabit from San Diego to Boston
(a) At t = 0, (b) After 500 μsec, (c) After 20 msec, (d) after 40 msec.
TANENBAUM
Computer Networks II

51. Measuring Network Performance
Make sure that the sample size is large enough
Make sure that the samples are representative
Be careful when using a coarse-grained clock
Be sure that nothing unexpected is going on during your tests
Caching can wreak havoc with measurements
Understand what you are measuring
Be careful about extrapolating the results
TANENBAUM
Computer Networks II

52. Network Performance Measurement
The basic loop for improving network performance.
Measure relevant network parameters, performance.
Try to understand what is going on.
Change one parameter.
TANENBAUM
Computer Networks II

53. System Design for Better Performance
Rules:
CPU speed is more important than network speed.
Reduce packet count to reduce software overhead.
Minimize context switches.
Minimize copying.
You can buy more bandwidth but not lower delay.
Avoiding congestion is better than recovering from it.
Avoid timeouts.
TANENBAUM
Computer Networks II

54. System Design for Better Performance (2)
Response as a function of load.
TANENBAUM
Computer Networks II

55. System Design for Better Performance (3)
Four context switches to handle one packet
with a user-space network manager.
TANENBAUM
Computer Networks II

56. Fast TPDU Processing Main obstacle is protocol software
Processing overhead components
Overhead per TPDU
Overhead per byte
Optimization for overhead per TPDU
Minimize tests if in ESTABLISHED state
Headers of consecutive data TPDU’s are almost the same
Store a prototype header and overwrite the changing values
TANENBAUM
Computer Networks II

57. Fast TPDU Processing
The fast path from sender to receiver is shown with a heavy line.
The processing steps on this path are shaded.
TANENBAUM
Computer Networks II

58. Fast TPDU Processing (2)
(a) TCP header. (b) IP header. In both cases, the shaded fields are taken from the prototype without change.
TANENBAUM
Computer Networks II

59. Optimizations for high speed networks
Buffer management
Avoid unnecessary copying
Timer Management
Use linked list of timer events sorted by expiry time
At every clock tick, the counter in the head entry is decremented
Timer wheel
More efficient if timer interval is known in advance
TANENBAUM
Computer Networks II

60. Timer Wheel
TANENBAUM
Computer Networks II

61. Protocols for Gegabit Networks
32 bit sequence number is small
Communication speed is much faster than computing speed
Go back n is not good when bandwidth-delay product is high
Gegabit lines are delay limited rather than bandwidth limited
Variance of packet arrival time may be very important
TANENBAUM
Computer Networks II

62. Protocols for Gigabit Networks
Time to transfer and acknowledge a 1-megabit file over a 4000-km line.
TANENBAUM
Computer Networks II

63. Gegabit (cont’d) Design for speed not for bandwidth optimization
Make protocols simple and let the main CPU do the work
Reserve necessary sources at the connection set up time rather than implementing e.g. Slow start algorithm
Minimize header length and copy time
Checksum the header and data separately
Concentrate on succesful cases rather than failures
TANENBAUM
Computer Networks II

64. Required Reading Tanenbaum Sections 6.4 6.5 6.6 TANENBAUM
Computer Networks II