Chapter 6
Transport Layer

Transport layer

• Provides end-to-end data transport for user.
• Depends upon services of network layer.
• Required because network layer is not generally reliable and often controlled by someone other than network user.
• The TPDU (Transport Protocol Data Unit) discussed in the text corresponds to the TCP (Transmission Control Protocol) header and data load. The TPDU is contained within a network packet which is itself contained within a data link frame as illustrated below for Ethernet, IP, and TCP protocols:

6.1.3 Berkley Sockets - A standard set of transport primitives used in Berkley UNIX for TCP and widely ported to other systems, including Windows, though Microsoft made significant improvements such as changing the spelling of several functions.
 

The following example of an echo client/server illustrates the relative ease that networked applications can be implemented using the Berkley sockets. For a complete version see TCP Client and TCP Server. Most languages implement network operations ad hoc using function libraries, newer languages such as Java are designed to include networking as part of the language.
 

// Server

#include <winsock2.h> 

void main(void)
{
 char                     buffer[128]; 
 int                       retval, sinlen; 
 struct sockaddr_in  sin; 
 SOCKET                s, h; 

 WSAStartup(0x202,&wsaData);

 sin.sin_family = AF_INET; 
 sin.sin_addr.s_addr = INADDR_ANY;
 sin.sin_port = htons(888);   // Port 888
                 // SOCK_STREAM is TCP
 s = socket(AF_INET, SOCK_STREAM,0);
                 // Bind socket to local port
 bind(s,(struct sockaddr*)&sin,sizeof(sin));
                 // Listen for 1 connection
 listen(s,1);
 sinlen = sizeof(sin);      

                 // 1. Block for connection request
 h=accept(s,(struct sockaddr*)&sin,&sinlen );

                 // 2. Block for receive
 recv(h,buffer,sizeof(buffer),0); 

                 // 3. Echo what is received
 send(h,buffer,strlen(buffer),0);
                
 closesocket(h);
}

// Client

#include <winsock2.h> 
#include <iostream.h>
void main(int argc, char* argv[])
{
 char                      buffer[128]= "Hello"; 
 int                        retval; 
 unsigned int          addr=0; 
 struct sockaddr_in  sin; 
 struct hostent        *host; 
 SOCKET                 s; 

 WSAStartup(0x202,&wsaData);
                  // Assume valid DNS given
 host = gethostbyname(argv[1]);

 memcpy(&(sin.sin_addr),
        host->h_addr,host->h_length); 
 sin.sin_family = host->h_addrtype; 
 sin.sin_port = htons(888);
                   // Create socket port 888
 s = socket(AF_INET, SOCK_STREAM,0);

                   // 1. Block for server accept connection
 connect(s,  (struct sockaddr*)&sin,sizeof(sin));
         
                   // 2. Send "Hello"       
 send(s,buffer,strlen(buffer)+1,0);

                   // 3. Block for Receive 
 recv(s,buffer,sizeof(buffer),0);

                   // Print what is received
 cout << "Received " << buffer << "\n"; 
        
 closesocket(s);
}

// Server

import socket


s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('', 8888))
s.listen(1)

conn, addr = s.accept()
data = conn.recv(1024)
conn.send(data)
conn.close()

// Client

import socket


s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('localhost', 8888))

s.send('Hello world')
data = s.recv(1024)
s.close()

The Internet Transport Protocols (TCP and UDP)

6.4.1 UDP - Datagram service, no flow or congestion control provided, application using UDP must implement.

• UDP encapsulated within a fully addressed IP packet, IP being the routed protocol of the Internet.
• Remember that congested routers merely discard arriving packets so no returned information on lost datagrams.

Basically UDP just adds ports to IP datagram for delivery to the destination application.

• UDP header
• Source Port and Destination Port
• Length
• Checksum



• Useful in applications where reliable communications not an issue, such as client/server application (e.g. DNS). Client requests server action, if datagram lost, client can time out and resend.
   
• Simpler to program and less overhead. No setup required in advance or to release.

TCP - Designed to provide reliable end-to-end service over unreliable network layer. Runs on hosts communicating via TCP segments encapsulated as data within an IP packet. IP is a routed protocol for hosts communicating via fully addressed packets. TCP connection is full-duplex, point-to-point (only two ends) between two ports appearing as a byte stream to an application similar to reading a file (no implicit message boundaries though a carriage return can be data).

6.4.2 TCP Protocol

• Each byte has own 32-bit sequence number (for fragmentation and reassembly).
• Segment has 20 byte header (and optional part) with data of 0 to what will fit into a 65535 byte IP packet. In practice considerably smaller (1024 bytes common).
• Sliding window protocol used with receiving host acknowledgments exposing more data for transmission.
• Receiving host must reassemble any fragments, reorder out of sequence segments.
• Sending host must time each segment sent, resending any unacknowledged segments.

• Maximum Segment Size - TCP must fit inside data load of IP packet so limit of 65515 bytes (i.e. IP header is minimum of 20 bytes). IP fragments to send across networks with smaller frame sizes adding 20 byte IP header to each fragment.
• Flow Control  - Receiver controls sender's window to regulate number of segments sent by advertising number of segments it can accept. If overwhelmed, receiver sets advertisement size to 0 to suspend sender.
• Checksum - End-to-end check using ones-complement sum of  header, pseudo header, and data.

6.4.3 TCP Header (see Fig. 6-29 of text, page 537)

• Source and destination port - IP number and TCP port  uniquely address a source or destination for segment delivery. The IP determines the host, the port determines the application that has opened the port. A socket may be used for multiple simultaneous connections (e.g. Web server with connections on port 80, each connection serviced by a separate thread). Some well known ports are 25 for SMTP, 80 for HTTPD.
• Sequence/Acknowledgement number - Numbers each byte (for fragmentation and reassembly).
• TCP header length - Number of 32-bit words in TCP header.
• Flags
• URG - Signals urgent data at offset of Urgent Pointer.
• ACK - Signals Acknowledgment number is valid.
• PSH - PUSHed data should be delivered immediately without buffering additional segments for efficiency reasons.
• RST - Reset the connection.
• SYN - Used for CONNECTION REQUEST when SYN=1 and ACK=0, or CONNECTION ACCEPTED when SYN=1 and ACK=1.
• FIN - Releases communication link.
• Window size - For end-to-end flow control discussed below.
• Checksum - Checksums header, data, and pseudo header for reliability using 16-bit 1's complement addition. Receiver adds all received 16-bit values including checksum, result should be 0 if checksum field agrees.
• Options - One option is the maximum size TCP payload the host will accept, default is 556 bytes.
• Pseudo header - Includes IP source and destination addresses to check for misdelivered packets.

6.4.4 Connection Management

• Opening Three-way Handshake
1. Host 1 executes CONNECT to send TCP segment to Host 2 with flags SYN=1, ACK=0, an initial segment SEQ#, and destination port.
2. Host 2 passes segment to application (e.g. echoserver) listening on destination port to accept or reject connection. If connection accepted Host 2 confirms with SYN=1, ACK=1, its own initial SEQ#, an acknowledgement number of sender's SEQ#+1.
3. Host 1 confirms that it received the connection acceptance from Host 2 by SYN=0, ACK=1 and ACK#+1.

Closing Connection - The connection is closed using a three-way handshake.

6.4.5 TCP Transmission Policy

• Windowing - Windows are sized by number of bytes.
  • Each host maintains a flow control window and a separate window for congestion.
  • Uses smallest size of the two for number of unacknowledged packets.
  • Figure at right has window size four as four packets can be outstanding.
  • Receivers advertise window size of number of bytes they can accept.
     
• Flow control example
  • Receiver advertises window size, suppose 4000 bytes.
  • Segment of 3000 bytes arrives and is acknowledged, window now advertised as 1000 until receiver application accepts the data.
  • Next a 1000 byte segment received and acknowledged, window advertised as 0 until receiver application removes some data and advertises new window size.
  • When window size 0 only two exceptions allowed for sender to transmit:
  1. Urgent data such as the user on sender killing the application process on the receiver.
  2. A one byte segment from sender to which the receiver announces the next byte expected and window size, needed to prevent deadlock should the window announcement from the receiver get lost.
      
• Buffering
  • Senders not required to send data immediately as application generates, can buffer into larger segment
  • Receivers not required to send acknowledgments immediately making for more efficient use of bandwidth (i.e. piggybacking).
  • For an interactive TELNET session, user types one character which is transmitted in a 21 byte TCP header and data segment that has a 20 byte IP packet header for a total of 41 bytes for sending one character.
  • It then receives a 40 byte (TCP header and IP header) acknowledgment.
  • If receiver echoes back the character (as is often the case), process is repeated creating up to 162 bytes of traffic per character typed.
  • Delaying long enough to acquire and send two keystrokes at a time would cut the per character transmission costs by 1/2.

• Nagle's Algorithm - To avoid high cost of interactive applications sending one character at a time.
  • When sender application produces data send the first byte and buffer the rest until an acknowledgment arrives.
  • Then send buffered characters in one TCP segment.
  • Continue buffering until next acknowledgment arrives.
  • Sometimes necessary to disable such as when for X-Windows where mouse movements generate dozens of individual bytes but should not be sent in bursts (i.e. would cause mouse pointer to stall during buffering then make many moves when buffered data sent).
• Silly Window Syndrome - Suppose the receiver's buffer is full then the receiver application removes one byte.
  • A window size of one is advertised and the sender sends one more byte at a possible cost of 162 bytes (noted above in Telnet example).
  • Solution is to prevent receiver from advertising a window smaller than maximum segment size.
  • Receiver would already have other data buffered when available window size below the maximum so receiver application would not run out of data.

6.4.6 TCP Congestion Control

• Detection - Assumes all timeouts due to congestion.
   
• Control and avoidance - Sliding window protocol for congestion and flow control

 
• Flow control window - Deals with receiver capacity. Sender informed by receiver of receiver size through window advertisement header field.
   
• Congestion window - Deals with network capacity. Both ends maintain a flow control advertised to the sender and a separate congestion control window (since both are normally sender and receiver). Sender transmits segments of the smaller window size to prevent overwhelming receiver and avoid congestion.

   Example: A receiver may advertise a window larger than a congested network can support.

• Sender controls congestion window based on lost segments, assumes all lost due to congestion (i.e. segment discarded by router).
• Receiver controls flow control window based on available buffer size. Advertises flow control window size to sender.
   
• Threshold - Initially 64K, determines the size of congestion window.

 
• Fast stop - After timeout set congestion window to byte size of one maximum segment (1024 bytes is common).
   
• Congestion avoidance - After timeout reduce threshold by 1/2.
   
• Slow start - Slow start increases congestion window by one segment for first acknowledgment, two for second, etc. effectively doubling each time a full window is acknowledged (exponential growth is not slow) until threshold reached.

  At threshold, increase congestion window and threshold by 1 segment each time a full window is acknowledged (linear increase), growing up to the receiver flow control window size.
   

• Timeout - On timeout, set congestion avoidance threshold to 1/2 congestion window and reduce congestion window size to one segment size.

  Use slow start till avoidance threshold reached then use avoidance. Rationale is that congestion probably occurred due to new sender coming on so available bandwidth is conservatively halved.
   

• Example
• Initial conditions
• Threshold - 8192
• Flow control window - 1024
• Congestion window - 4096
• Segment - 512
• Case 1 - No timeouts
1. Send 512 bytes
2. Send 512 bytes
3. Acknowledge
• Case 2 - Timeout
1. Send 512 bytes
2. Send 512 bytes
3. Timeout
• Threshold - 8192/2 = 4096
• Flow control window - 1024
• Congestion window - 512 one segment
• Segment - 512
4. Send 512 bytes
5. Acknowledge
• Threshold - 4096
• Flow control window - 1024
• Congestion window - 512+512 = 1024
• Segment - 512
6. Send 512 bytes
7. Acknowledge
• Threshold - 4096
• Flow control window - 1024
• Congestion window - 1024+1024 = 2048
• Segment - 512

6.4.7 TCP Timer Management

• Retransmissions

  If too short timeout, duplicates sent, too long, increased delay waiting for acknowledgment that may never arrive.

  TCP averages RTT estimate (Round Trip Time) since delay may vary widely between segments sent. Using an acknowledgment time of M (latest RTT for acknowledged message):

 

RTT = aRTT + (1 - a)M

With a= 7/8, weighting the effect of the estimated RTT more heavily than the most recent time M to determine the new timeout.

• Karn's Algorithm - For unreliable mediums such as radio many retransmissions required producing many duplicate acknowledgements. Including retransmitted segments RTT lead to an underestimated timeout since cannot distinguish between the acknowledgement of the original or retransmitted segment.

  Solution is to ignore RTT of any segment that is retransmitted and double the timeout value until segments are acknowledged prior to timeout. Then include in RTT calculation.
   

• Persistence timer - Prevent deadlock when receiver sends acknowledgement with window size of 0 telling sender to wait.

  Receiver then updates window size > 0 which is lost leaving sender and receiver waiting on the other to do something, hence deadlock. Persistence timer goes off causing sender to send probe to receiver, receiver responds with window size.

Document last modified: