03. Transport Layer

$\gdef \N{\mathbb{N}} \gdef \Z{\mathbb{Z}} \gdef \Q{\mathbb{Q}} \gdef \R{\mathbb{R}} \gdef \C{\mathbb{C}} \gdef \setcomp#1{\overline{#1}} \gdef \sseq{\subseteq} \gdef \pset#1{\mathcal{P}(#1)} \gdef \covariant{\operatorname{Cov}} \gdef \of{\circ} \gdef \p{^{\prime}} \gdef \pp{^{\prime\prime}} \gdef \ppp{^{\prime\prime\prime}} \gdef \pn#1{^{\prime\times{#1}}} $

Transport Services and Protocols¶

Their job is to provide logical communication between application processes running on different hosts.
The sender breaks the application messages into segments, and passes those to the Network Layer.

The receiver reassembles segments into messages, and returns them to the Application Layer.

Transport Layer vs. Network Layer¶

The purpose of the Transport Layer is to ensure the data is sent/received as intended (ensure all the segments get transmitted, order is maintained).
The purpose of the Network Layer is to route and (attempt) to deliver the data.

Primary Transport Protocols¶

There are two Transport Protocols available to Internet applications:

• TCP – Transmission Control Protocol
  • Reliable, in-order delivery
  • Congestion control
  • Flow control
  • Connection setup (handshake, etc)
  • Error Detection
    • and handling
• UDP – User Datagram Protocol
  • Unreliable, unordered delivery
  • No-frills ‘best effort’ IP
  • Error Detection
    • NO handling

UDP and TCP provide integrity checking by including error- detection fields in their segments’ headers. These two minimal transport-layer services—process-to-process data delivery and error checking—are the only two services that UDP provides! In particular, like IP, UDP is an unreliable service—it does not guarantee that data sent by one process will arrive intact (or at all!) to the destination process.

TCP, on the other hand, offers several additional services to applications. First and foremost, it provides reliable data transfer. Using flow control, sequence numbers, acknowledgments, and timers, TCP ensures that data is delivered from sending process to receiving process, correctly and in order. TCP thus converts IP’s unreliable service between end systems into a reliable data transport service between processes. TCP also provides congestion control. Congestion control is not so much a service provided to the invoking application as it is a service for the Internet as a whole, a service for the general good. Loosely speaking, TCP congestion control prevents any one TCP connection from swamping the links and routers between communicating hosts with an excessive amount of traffic. TCP strives to give each connection traversing a congested link an equal share of the link bandwidth. This is done by regulating the rate at which the sending sides of TCP connections can send traffic into the network. UDP traffic, on the other hand, is unregulated. An application using UDP transport can send at any rate it pleases, for as long as it pleases.

Multiplexing and Demultiplexing¶

This is the part where we connect host-to-host communication with process-to-process communication.

Here’s how it works:

1. The host receives IP datagrams from the Network Layer
   • Each datagram has a source and destination IP address
   • Each datagram carries one transport-layer segment
   • Each segment has a source and destination port number
2. The host uses the IP address and the port number to direct the segment to the appropriate socket

Connectionless Demultiplexing – UDP¶

When creating a datagram to send in a UDP socket, we must specify

• The destination IP address
• The destination port number
  When a host receives a UDP segment, it
• Checks the destination port number in the segment
• Directs the UDP segment to the socket with the corresponding port number

Connection-oriented Demultiplexing – TCP¶

When creating a datagram to send in a TCP socket, we must specify

• The source IP address
• The source port number
• The destination IP address
• The destination port number
  When a host receives a TCP segment, it checks each of the four fields to direct a segment to the appropriate socket.
  A server may support many simultaneous TCP sockets.
  

UDP¶

UDP Checksum¶

The checksum allows us to detect errors (flipped bits) in a transmitted segment.
The checksum is taken from the UDP headers, the application data, and a pseudo-header that contains the source and destination IP addresses.

Reliable Transmission¶

Since the network protocol is unreliable, we use the Transport Layer to implement reliability through data validation and receipt confirmation. This way, the Application Layer can just ‘assume’ that everything is reliable and not have to worry about making sure all the bits are correct and got delivered in the right order.

An acknowledgement (ACK) is a small control frame that a protocol sends back to its peer saying that it has received the earlier frame.
(A control frame is a header-only frame, with no body)

If the sender doesn’t get an ACK after a reasonable amount of time (the timeout), it resends the original frame.
This strategy of using ACK and timeouts to implement reliable delivery is called Automatic Repeat reQuest (ARQ).

Stop and Wait Protocol¶

• After sending a single frame, the sender waits for an ACK before sending the next one.
• If the sender does not receive an ACK within the timeout, it retransmits the original frame.

How does the receiver know the retried frame is a duplicate (in the case that the receiver actually got the original frame but the ACK response didn’t get delivered to the sender in time)?

We use a 1 bit sequence number. When the sender retransmits frame 0, the receiver can determine that it’s seeing a second copy of frame 0, rather than the first copy of frame 1, and can therefore ignore it (but also sends an ACK, in case the first ACK was lost).

Performance¶

Let \(U_{\text{sender}}\) represent the amount of time the sender is busy actually sending data.

Example: 1 Gbps link, 15 ms propagation delay, 8Kb packet.

• The time to transmit the packet into the channel
  • \(D_{\text{transmit}}=\frac LR = \frac{8000\text{ bits}}{10^9\text{ bits/sec}}=8\mu s\)
• \[\begin{align}U_{\text{sender}}&=\frac{L/R}{RTT+L/R}\\&=\frac{0.008}{30.008}\\&=0.00027\end{align}\]
• This means the sender is sending data only \(0.027\%\) of the time!
  Stop and Wait performance stinks!

Pipelined Stop and Wait¶

Sender allows multiple packets to be sent before requiring ACK.

Go Back N – Sender¶

The sender sends a ‘window’ of up to \(N\) consecutive transmitted but unACKed packets.

Go Back N – Receiver¶

The receiver only sends an ACK for a correctly received packet. Meaning, if it receives packets 1,2,3,6,4,5,7,8, it’ll send an ack for packets 1,2,3,4, (skip six, because it’s out of order), 5, (skip 7 and 8 because we’re now expecting 6).
When an out of order packet is received, it can either discard or save that packet for later (implementation decision), and it re-ACK-s the packet with highest-in-order sequence number.

Piggybacking¶

When we send an ACK in the same frame that we send data, it’s called Piggybacking.

TCP¶