770 likes | 797 Views
The Transport Layer. The Transport Layer. Recall: The transport layer is responsible for providing the illusion of a reliable end-to-end connection between two hosts Functions of the transport layer include End-to-end connection setup and tear-down End-to-end flow control
E N D
The Transport Layer • Recall: • The transport layer is responsible for providing the illusion of a reliable end-to-end connection between two hosts • Functions of the transport layer include • End-to-end connection setup and tear-down • End-to-end flow control • End-to-end error control
Contents • Connection Control • Flow and Error Control • Multiplexing • Transport Layer in the Internet
1. Connection Control • The transport layer must provide higher layers with the illusion of an end-to-end connection, especially in connectionless networks • Required functions: • Connection setup • Connection tear-down
1.1 Setting up a Transport Layer Connection • When an application in one host wants to communicate with an application in another host, it must set up a transport layer connection to that application • Setting up a connection is not as easy as it seems
Setting up a Transport Layer Connection • Naïve (bad) approach: • Source host sends a connection setup packet to the destination host • Destination host acknowledges the connection setup packet, and the connection is considered set up Host A Host B Connection Request Time Accept Connection
Problems with the Naïve approach • Duplicate “connection request” or “accept connection” packets in the network • How can CR and AC packets be duplicated in the first place, though?
Duplicate Packet Problem • Consider a network experiencing long delays (perhaps due to congestion) New CR generated after the first one timed out A B R R R First CR is just arriving to B after being delayed by congested routers Result: B thinks two connections have been requested by A
Connection request with sequence number 0 is transmitted, but delayed within the network. • Sender times out, and retransmits a duplicate request, which was then successfully received at the destination, and the connection was set up.
Now, the delayed duplicate appears at the receiver. The receiver cannot tell if it is a duplicate, or it is a new connection request (with a sequence number wrapped around) • only way for the receiver to tell if it is a duplicate is to keep history of all connection requests (This is not desirable. What if the receiver crashes and loses all history?)
Solving the Duplicate Packet Problem • Introduce sequence numbers and a 3-way handshake • Sequence numbers must cycle through a large range of numbers to make sure there are never two packets in the network with the same sequence number
Three-way Handshake: Case 1 • Successful connection Host A Host B CR (seq=x) ACK (seq=y, ACK=x) DATA (seq=x, ACK=y)
Three-way Handshake: Case 2 • Duplicate Connection Request Host A Host B duplicate CR (seq=x) ACK (seq=y, ACK=x) REJECT (ACK=y)
Three-way Handshake: Case 3 • Dulicate CR and duplicate ACK Host A Host B duplicate CR (seq=x) ACK (seq=y, ACK=x) duplicate DATA (seq=x, ACK=z) REJECT (ACK=y)
1.2 Connection Tear-Down • Two types of connection tear-down: • Asymmetric Release: • Either host may terminate the connection • Symmetric Release: • Both sides keep a unidirectional connection to the other • For each connection, the source tears it down when no more packets will be sent
Problem #1: Loss of Data • In asymmetric tear-down, data may be lost: Host A Host B CR ACK DATA DATA DR Lost data
Problem #1: Loss of Data (cont’d) • Partial solution: • Use 3-way handshake for connection tear-down • Destination host starts a timer after it receives a disconnect request (DR) • The destination finally releases the connection once its acknowledgement is also acknowledged • If no return acknowledgement arrives within the time-out interval, the connection is disconnected
Problem #2: Lost tear-down requests • What if all disconnect requests are lost? Host A Host B DR Timeout: Retry DR Timeout: Retry DR Timeout: Retry DR Timeout: Give up and close connection to B Connection to A is still open
Problem #2: Lost tear-down requests (cont’d) • Solution: • Require a host to close a connection if no packets have been received for a specified amount of time • Hosts transmit keep-alive packets to keep a connection open when they have no data to send
2. Flow and Error Control • The transport layer, like the data link layer, must provide a flow-controlled and error-controlled link • The data link layer is hop-by-hop (IMP-to-IMP), while the transport layer is end-to-end • The same flow and error control protocols used in the data link layer may be used with the transport layer • One additional concern: packet resequencing
Sliding Window with Out of Order Arrivals • Sender side window is unaffected by out of order reception of packets at the receiver • Receiver side window, however, behaves differently when packets are able to arrive out of order • New techniques required
7 0 7 0 7 0 7 0 6 1 6 1 6 1 6 1 5 2 5 2 5 2 5 2 4 3 4 3 4 3 4 3 Handling Out-of-Order Packet Arrivals Consider a sliding window protocol, size 2 Receiver Side Window: No packets have arrived Packet #0 arrives (Generate ACK for packet 0) Packet #2 arrives out of order Packet #1 arrives (Generate ACKs for packets 1 and 2)
Handling Out-of-Order Packet Arrivals (cont’d) • Procedure for receiver-side sliding window: • Packets with sequence numbers outside the sliding window are discarded • When a packet arrives out of order, place a mark by the packet’s sequence number in the window • When the first packet in the sliding window arrives, adjust the start of the sliding window up to the next unmarked sequence number. Generate acknowledgements for each of the sequence numbers the sliding window just passed.
3. Multiplexing • Multiple transport layer connections may be open: • through a single physical interface • through a single data link layer • to a single network destination • In these cases, the connections must be multiplexed onto a single channel
Two types of Multiplexing The following types of multiplexing apply only to connection-oriented networks. There is no notion of a network layer connection in connectionless networks: • Upward Multiplexing • Downward Multiplexing
Two Types of Multiplexing (cont’d) • Upward Multiplexing • Open a single network layer connection (virtual channel) to the destination • If there are multiple transport layer connections to the same network layer destination, send all their packets through a single network layer connection Transport Layer Network Layer Data Link Layer Physical Layer
Two Types of Multiplexing (cont’d) • Downward Multiplexing • Open several network layer connections to the same destination • Distribute transport layer packets among the several network layer connections Transport Layer Network Layer Data Link Layer Physical Layer
4. The Internet Transport Layer • The Internet supports two transport layer protocols: • The Transport Control Protocol (TCP) for reliable service • The Unreliable Datagram Protocol (UDP)
4.1 TCP • TCP provides the end-to-end reliable connection that IP alone cannot support • The TCP connection primitive is known as the “socket” • A socket may be viewed as a bi-directional pipe between two hosts • Connecting a socket requires a destination IP address and a port number
TCP Ports • Ports allow a host to maintain more than one connection to a single host • All port number less than 256 are reserved for standard services like: • Telnet • FTP • Email • News • etc. (See a UNIX /etc/services file for more)
The TCP Protocol • Frame format • Connection management • Flow control • Congestion control
4.1.1 TCP Frame Format 32 bits Source Port Destination Port Sequence Number Acknowledgement number HL U R G A C K P S H R S T S Y N F I N Window Size Checksum Urgent Pointer Options (0 or more 32-bit words) Data
TCP Frame Fields • Source & Destination Ports • 16 bit port identifiers for each packet • Sequence number • The packet’s unique sequence ID • Acknowledgement number • The sequence number of the next packet expected by the receiver
TCP Frame Fields (cont’d) • Window size • Specifies how many bytes may be sent after the first acknowledged byte • Checksum • Checksums the TCP header and IP address fields • Urgent Pointer • Points to urgent data in the TCP data field
TCP Frame Fields (cont’d) • Header bits • URG = Urgent pointer field in use • ACK = Indicates whether frame contains acknowledgement • PSH = Data has been “pushed”. It should be delivered to higher layers right away. • RST = Indicates that the connection should be reset • SYN = Used to establish connections • FIN = Used to release a connection
4.1.2 TCP Connection Establishment • Three-way Handshake Host A Host B SYN (seq=x) SYN (seq=y, ACK=x+1) SYN (seq=x+1, ACK=y+1)
TCP Connection Tear-down • Two double handshakes: Host A Host B FIN (seq=x) ACK (ACK=x+1) A->B torn down FIN (seq=y) ACK (ACK=y+1) B->A torn down
4.1.3 TCP Flow Control • TCP uses a modified version of the sliding window • In acknowledgements, TCP uses the “Window size” field to tell the sender how many bytes it may transmit • TCP uses bytes, not packets, as sequence numbers
TCP Flow Control (cont’d) Important information in TCP/IP packet headers Number of bytes in packet (N) Sequence number of first data byte in packet (SEQ) N SEQ Send ACK bit set Sequence number of next expected byte (ACK) Window size at the receiver (WIN) ACK WIN Recv Contained in IP header Contained in TCP header
2K SEQ=0 2K 2K SEQ=2048 1K SEQ=4096 2K 1K 2K TCP Flow Control (cont’d) Sender Receiver Receiver’s buffer Application does a 2K write 0 4K Empty ACK = 2048 WIN = 2048 Application does a 3K write Full Sender is blocked Application reads 2K ACK = 4096 WIN = 0 ACK = 4096 WIN = 2048 Sender may send up to 2K
TCP Flow Control (cont’d) Piggybacking: Allows more efficient bidirectional communication Data from A to B ACK for data from B to A N SEQ ACK WIN A B N SEQ ACK WIN Data from B to A ACK for data from A to B
TCP Flow Control Problems • The Small Packet Problem • Occurs when the source sends many small packets • The Silly Window Syndrome • Occurs when the destination reads a small number of bytes at a time from its buffer
The Small Packet Problem (SPP) • Consider an interactive application where the source host sends each keystroke one at a time to the destination host • Each keystroke is 1 byte. After adding TCP/IP overhead, a 41-byte packet is generated • When the destination receives the packet, it returns a 40-byte acknowledgement packet • When the destination removes the byte from its buffer, a 40-byte window update packet is sent • Some applications echo the typed character back to the source, creating another 41-byte packet
1 1 SEQ=0 SEQ=1 1 1 Small Packet Problem (cont’d) Sender Receiver Receiver’s buffer Application does a 1B write 0 4K Empty ACK = 1 WIN = 4095 Application reads 1 B ACK = 1 WIN = 4096 Empty Application does a 1B write ACK = 2 WIN = 4095 Application reads 1 B ACK = 2 WIN = 4096 Empty etc.
Number of bytes transmitted from A to B in a single transmission cycle = 1 Small Packet Problem (cont’d) • SPP seriously degrades throughput Transmission cycle length » RTT + RTT/2 » 3/2 RTT Number of bytes 2 » Throughput = Bytes per sec Transmission cycle 3 RTT
How TCP Solves the SPP • Nagle’s Algorithm: • When data is sent one byte at a time, send only the first byte • Buffer all remaining bytes until the first one is acknowledged • After receiving the acknowledgement, send all the buffered bytes in one packet • This algorithm reduces the amount of bandwidth required to support interactive applications
1 15 24 SEQ=16 SEQ=0 SEQ=1 1 15 Nagle’s Algorithm Sender Receiver Receiver’s buffer Application does a 1B write 0 4K Empty Application does 15 1B writes ACK = 1 WIN = 4095 Application reads 1 B ACK = 1 WIN = 4096 Empty Application does 24 1B writes ACK = 16 WIN = 4080 Application reads 15 B ACK = 16 WIN = 4096 Empty etc.
Silly Window Syndrome (SWS) • Consider an application where the source sends in large blocks of data but the destination reads bytes from its buffer 1 byte at a time • Each time the destination reads a byte from its buffer, it returns a window update to the source • The source sees that it is only free to send 1 more byte so it sends a single byte • This process repeats itself until all the data has been sent, 1 byte at a time
4K 1 SEQ=0 SEQ=4096 Silly Window Syndrome (cont’d) Sender Receiver Receiver’s buffer Application does a 4K write 0 4K Empty Sender blocked Full ACK = 4096 WIN = 0 Application does a 1K write Application reads 1 B ACK = 4096 WIN = 1 4095 Full ACK = 4097 WIN = 0 Application reads 1 B ACK = 4097 WIN = 1 4095 etc.
How TCP Solves the SWS • Clark’s Solution: • Prevent the receiver application from reading only 1 byte from its TCP buffer • The receiver application should only read from the TCP buffer when it has sufficient application buffer space to handle a larger chunk of data • The sender may also help by refusing to send small data packets