Chapter 6 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:
| Primitive | Meaning |
| SOCKET | Create new communication end point in program |
| BIND | Attach a local port address to a socket |
| LISTEN | Open socket to connection requests and define number of queued connections |
| ACCEPT | Block execution until a connection request arrives; server |
| CONNECT | Attempt to establish connection (e.g. to a program blocked at an ACCEPT); client |
| SEND | Send data over a connection (encapsulated within an TCP segment) |
| RECEIVE | Receive data over a connection. |
| CLOSE | Opposite of ACCEPT and CONNECT |
// 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.
Exercise 1 - ARP
|
Exercise 2 - ping
|
Exercise 3 - UDP
|
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.
- 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.
- Opening Three-way Handshake
- Host 1 executes CONNECT to send TCP segment to Host 2 with flags SYN=1, ACK=0, an initial segment SEQ#, and destination port.
- 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.
- Host 1 confirms that it received the connection acceptance from Host 2 by SYN=0, ACK=1 and ACK#+1.
| Host 1 Client | Host 2 Server |
| Send SYN=1 ACK=0 SEQ#=101 | |
| Receive SYN=1 ACK=0 SEQ#=101 Send SYN=1 ACK=1 SEQ#=35 ACK#=102 |
|
| Receive SYN=1 ACK=1 SEQ#=35 ACK#=102 Send SYN=0 ACK=1 ACK#=36 SEQ#=102 |
|
| Receive SYN=0 ACK=1 ACK#=36 SEQ#=102 |
| Host 1 Request Connect by Client | Host 2 Connect Accept by Server | Host 1 Ack Accept by Client |
| TCP: ----- TCP header ----- TCP: TCP: Source port = 1041 TCP: Destination port = 889 TCP: Sequence number = 6001 TCP: Data offset = 24 bytes TCP: Flags = 02 TCP: ..0. .... = (No urgent pointer) TCP: ...0 .... = (No acknowledgment) TCP: .... 0... = (No push) TCP: .... .0.. = (No reset) TCP: .... ..1. = SYN TCP: .... ...0 = (No FIN) TCP: Window = 4096 TCP: Checksum = 7865 (correct) TCP: TCP: Options follow TCP: Maximum segment size = 1024 |
TCP: ----- TCP header ----- TCP: TCP: Source port = 889 TCP: Destination port = 1041 TCP: Sequence number = 40001 TCP: Acknowledge number = 6002 TCP: Data offset = 24 bytes TCP: Flags = 12 TCP: ..0. .... = (No urgent pointer) TCP: ...1 .... = Acknowledgment TCP: .... 0... = (No push) TCP: .... .0.. = (No reset) TCP: .... ..1. = SYN TCP: .... ...0 = (No FIN) TCP: Window = 4096 TCP: Checksum = 5F17 (correct) TCP: TCP: Options follow TCP: Maximum segment size = 1024 |
TCP: ----- TCP header ----- TCP: TCP: Source port = 1041 TCP: Destination port = 889 TCP: Sequence number = 6002 TCP: Acknowledge number = 40002 TCP: Data offset = 24 bytes TCP: Flags = 02 TCP: ..0. .... = (No urgent pointer) TCP: ...1 .... = (No acknowledgment) TCP: .... 0... = (No push) TCP: .... .0.. = (No reset) TCP: .... ..0. = SYN TCP: .... ...0 = (No FIN) TCP: Window = 4096 TCP: Checksum = 7865 (correct) TCP: TCP: Options follow TCP: Maximum segment size = 1024 |
- Closing Connection - The connection is closed using a three-way
handshake.
| Client | Server |
| Send FIN=1 | |
| Receive FIN=1 but may continue sending DATA or ACK FIN | |
| Receive DATA or ACK FIN |
Exercise 4 - OPEN and CLOSE Connection
|
- 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:
- Urgent data such as the user on sender killing the application process on the receiver.
- 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.
Exercise 5 - FLOW ControlPERFclient sends a specified number of bytes and packets to PERFserver, useful for monitoring protocol behavior under load. These applications and Ethereal, a network monitoring tool, are used to examine flow control on TCP.
|
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
- Send 512 bytes
- Send 512 bytes
- Acknowledge
- Case 2 - Timeout
- Send 512 bytes
- Send 512 bytes
- Timeout
- Threshold - 8192/2 = 4096
- Flow control window - 1024
- Congestion window - 512 one segment
- Segment - 512
- Send 512 bytes
- Acknowledge
- Threshold - 4096
- Flow control window - 1024
- Congestion window - 512+512 = 1024
- Segment - 512
- Send 512 bytes
- Acknowledge
- Threshold - 4096
- Flow control window - 1024
- Congestion window - 1024+1024 = 2048
- Segment - 512
- RetransmissionsIf 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.
No comments:
Post a Comment