1. Chapter 6
The Transport Layer
2010

2. Services Provided to the Upper Layers
connection-oriented and connectionless
very similar to the network layer
transport layer makes it possible for the transport service to be more reliable than the underlying network service.
Furthermore, the transport service primitives can be designed to be independent of the network service primitives, which may vary considerably from network to network.
Dominant for network layer: IP thus connectionless
for transport layer:
TCP connection oriented
UDP for connectionless: IP with a little extra
2010

3. Transport Service Primitives
2010

4. Berkeley Sockets
SOCKET: Create a new communication end point. The parameters specify the addressing format, the type of service (e.g. reliable byte stream) and the protocol. It returns an ordinary file descriptor for use in succeeding calls, (same as OPEN).
BIND: Binds a local address to a socket.
LISTEN: Allocates space to queue incoming calls for the case that several clients try to connect at the same time, it does not block.
ACCEPT: Blocks a server until a connect request TPDU from a client arrives. A new socket with the same properties as the original LISTEN one is then created by the transport entity and a file descriptor for it is returned. The server can then fork off a process or tread to handle the connection on the new socket and go back to waiting for the next connection on the original socket by issuing a new ACCEPT primitive.
CONNECT: Issued by a client after it has created a socket, it blocks the client and actively starts the connection process. When it completes (the appropriate TPDU is received ), the client process is unblocked and the connection is established.
SEND: Sends some data over the connection.
RECEIVE: Receives some data from the connection
CLOSE: Symmetric connection release.
2010

5. Transport vs Data link Protocol
Both have to deal with error control, sequencing, flow control and other issues.
In the subnet a packet might be stored for a number of seconds and then delivered later. This can sometimes be disastrous, specially during connection and disconnection, and requires the use of special protocols.
The large and dynamically varying number of connections in the transport layer, requires a different buffering and flow control approach than in the data link layer. The idea of dedicating many buffers to each connection in the transport layer is not attractive.
2010

6. Flow control
In data link and transport layer a sliding window or other scheme is needed on each connection to keep a fast transmitter from overrunning a slow receiver.
A router has relatively few lines whereas a host may have many open connections.
The optimum tradeoff between source and destination buffering depends on the reliability of the connection and the type of traffic.
For low bandwidth, bursty traffic (like produced by an interactive terminal) it is better to buffer at the sender. For high bandwidth, smooth traffic (like a file transfer) it is better to buffer at the receiver.
Dynamically adjustment of buffer allocation is needed.
2010

7. Decouple buffering
A general way to manage dynamic buffer allocation is to decouple the buffering from the acknowledgments, in contrast to the sliding window protocol of the data link layer.
Initially the sender requests a certain amount of buffer space on the receiver side, based on its perceived needs. The receiver grants as many as it can afford.
Every time the sender transmits data, it must decrement its allocation, stopping all together if it reaches 0.
The receiver separately piggybacks both acks and the amount of available buffer space onto the reversed traffic.
2010

8. UDP
UDP (User Datagram Protocol) is just basically IP with a short header added. The port numbers indicate the sending and receiving transport end points. When a UDP packet arrives, its payload is send to the process attached to the destination port.
The checksum is optional and stored as 0 if not computed, a calculated 0 checksum is stored as all 1s. UDP does not do flow control, error control or retransmission upon receipt of a bad datagram. All of that is up to the user process.
2010

9. Internet Transport Protocol: TCP
TCP (Transmission Control Protocol) provides a reliable byte stream over an unreliable internetwork.
TCP accepts user data streams from local processes, breaks them up into pieces not exceeding 64K (usually about 1460 bytes to fit in a single Ethernet frame) and sends each piece as a separate IP datagram.
The receiver side gives IP datagrams containing TCP data to its TCP entity, which reconstructs the original byte streams.
IP gives no guarantees that datagrams will be delivered properly, so it is up to TCP to time out and retransmit. Also IP datagrams might be delivered in the wrong order, it is up to TCP to rearrange them in the proper sequence.
2010

10. The TCP Service Model Port Protocol Use
Port numbers below 1024 are called well-known ports and are reserved for standard services. 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
The TCP service is obtained by having both the sender and receiver create end points, called sockets. Each socket has a socket number (address) consisting of the IP address and a 16 bit number local to that host, called a port.
Two or more connections may terminate at the same socket. Connections are identified by the socket identifiers at both ends, that is (socket1, socket2).
All TCP connections are full-duplex (traffic can go in both directions) and point-to-point (each connection has exactly 2 end points). Multicasting or broadcasting are not supported.
2010

11. Byte stream
A TCP connection is a byte stream, not a message stream. For example, if the sending process does four 512 byte writes to a TCP stream, these data may be delivered to the receiving process as four 512 byte chunks, two 1024 bytes chunks, one 2048 byte chunk or some other way. This is analogous to UNIX files.
TCP may send user data immediately or buffer it, in order to send larger segments to the network layer (larger IP datagrams.)
Applications might use the PUSH flag to indicate that TCP should send the data immediately. The application can also send urgent data (e.g. when an interactive user hits the CTRL-C key), TCP then puts control information in its header and the receiving side interrupts (gives a signal in UNIX terms) to the application program using the connection.
2010

12. TCP Segment Header
2010

13. The TCP Checksum
It checksums the header, the data and a conceptual pseudo header.
The pseudo header contains IP addresses and thus violates the protocol hierarchy. It helps to detect wrongly delivered packets.
The checksum is a simple one, just adding the 16-bits words in 1's complement and then take the 1's complement of the sum. The receiving side should find a 0.
2010

14. TCP Connection Establishment
A 3-way handshake. CR (connection request) and REJECT are indicated by the SYN and FIN bits in a segment header.
The initial sequence numbers are chosen in a special way, ensuring that no delayed or duplicated older request can fake a connection.
2010

15. TCP Connection Management Modeling
There are 11 states used in the TCP connection management finite state machine. Data can be send in the ESTABLISHED and the CLOSE WAIT states and received in the ESTABLISHED and FINWAIT1 states.
Releasing a TCP connection is symmetric. Either part can send a TCP segment with the FIN bit set, meaning it has no more data to send. When the FIN is acked, that direction is shut down, but data may continue to flow in the other direction.
It is not really fool proof, but it works.
2010

16. TCP Finite state Machine
Each line is marked by an event/action pair.
The event can either be a user-initiated system call (CONNECT, LISTEN, SEND or CLOSE), a segment arrival (SYN, FIN, ACK or RST), or a timeout.
For the TIMED WAIT state the event can only be a timeout of twice the maximum packet length.
The action is the sending of a control segment (SYN, FIN or RST) or nothing.
The time-outs to guard for lost packets ( e.g. in the SYN SENT state) are not shown here.
2010

17. TCP Window management Sender buffering:
Senders are not required to transmit data as soon as they come in from the application. Usually Nagle's algorithm is used. When data come into the sender one byte at a time (e.g. on a Telnet connection), just the first byte is send and the rest is buffered until the outstanding byte is acked. Sometimes it is better to disable this, e.g. when mouse movements are sent in X-Windows applications.
2010

18. Silly window syndrome
This occurs when the sender transmit data in large blocks, but an interactive receiver application reads data 1 byte at a time.
The receiver continuously gives 1 byte window updates and the sender transmits 1 byte segments.
Clark's solution is to let the receiver only send updates when it can handle the maximum segment size it advertised when the connection was established or when its buffer is half empty.
Receivers are also not required to send acks and window updates immediately.
Many implementations delay them for 500 msec in the hope to piggyback them.
2010

19. TCP Congestion Control
It is assumed that time-outs are caused by network or receiver congestion as lost packets are rare these days. (Wireless networks are now an exception)
Each sender maintains two windows:
the window the receiver has granted (indicating the receiver buffer capacity)
the congestion window (indicating the network capacity).
The number of bytes that may be sent is the minimum of the 2 windows.
2010

20. TCP slow start
The congestion window is doubled on each packet successfully sent (an ack received before the timeout). This exponential increase (called the slow start) continues until the threshold (initially 32K) is reached, after which the increase is linearly.
When a timeout occurs, the threshold is set to half the current congestion window and the slow start is repeated. If an ICMP source quench packet comes in, it is treated the same way as a timeout.
2010

21. TCP Timer Management
For each segment the round trip time M is measured and the estimates of the mean and mean deviation are updated as:     RTT = ß*RTT + (1-ß)*M     D = ß*D + (1-ß) * |RTT-M| with ß a smoothing parameter, typically 7/8. The timeout is then set to: RTT + 4 D
2010

22. Improvements
Change from the original Go-Back-N to an more Selective Repeat type of retransmit of lost segments:
Buffering out-of-order segments in the receiver
Sender detects missing segments by looking at duplicate ACK’s (NACK’s can not be used) and retransmits before the timer expires.
Improved congestion control:
look also to duplicate ACK’s to lower the congestion window to half its value
start from that value with linear increase
versions to handle HTTP (www) trafic efficiently
versions for high speed links to increase the throughput
On a wireless network if a packet is lost, it is usually not due to congestion, but due to transmission "noise". TCP should not slow down, but retransmit as soon as possible.
2010

23. Wireless TCP
Using an indirect TCP solution is a possibility. But the acknowledgment, returned from the base station to the sender, does not indicate that the mobile host has received the data.
Another possibility is to add a snooping agent on the base station. It watches the interchange between base station and mobile host and performs retransmissions (and interception of duplicated acknowledgments) on that part alone. However there is still the possibility that the sender times out and starts it congestion control.
2010

24. Real-Time Transport Protocol
RTP is intended for real-time multimedia applications
Its basic function is to multiplex several real-time data streams into a single stream of UDP packets
It can be regarded as a transport sublayer
Used for e.g. radio, telephony, music-on-demand, videoconferencing, video-on-command, etc.
It may contain for example a video stream and 2 audio stream for stereo or sound tracks in 2 languages.
2010

25. RTP header
Each payload may contain multiple samples, they may be coded any way the user wants. The payload type field indicates which one is used.
The timestamp gives the time of each sample relative to the first sample.
Synchronization source identifier: uniquely identifies the synchronizing source of a stream
Contributing source identifier: uniquely identifies the contributing streams (There are CC of them)
2010

26. some RTP audio/ video formats
2010

27. Real Time Control Protocol
RTCP can be used to handle synchronization between the sources.
further it gives feedback on delay, jitter, bandwidth and congestion.
The encoding process can use it to increase the data rate and give better quality if the network is functioning well,
otherwise it can cutback in data rate and hence reduce the quality.
note that missing RTP packets are usually not requested but are to some extend compensated for in the used encoding method.
2010

28. Real-Time Streaming Protocol
RTSP controls the transmission of a video stream.
It does not control the stream itself.
2010