Notes On Chapter Twenty-Six -- TCP: Reliable Transport Service

• 26.1 Introduction
  
  
  • Transport protocols in general
  • TCP in particular
  • How TCP provides reliable delivery
  
  
• 26.2 The Transmission Control Protocol
  
  
  • The Transmission Control Protocol, TCP provides reliable transport service on the Internet.
  • An application using TCP can treat the Internet pretty much like an abstract I/O system - for example, like a file system. That is not the case for applications that use a best-effort connectionless service such as UDP. Therefore TCP makes things easier for network application programmers.
  
  
• 26.3 The Service TCP Provides to Applications
  
  
  • Seven major features of TCP:
    1. Connection Oriented: requires connection creation, use, and tear-down.
    2. Point-to-Point Communication: a connection has exactly two endpoints.
    3. Complete Reliability: ensured complete in-order delivery
    4. Full Duplex Communication: either party can send data any time.
    5. Stream Interface: data sent and received as a continuous stream.
    6. Reliable Connection Startup
    7. Graceful Connection Shutdown: TCP ensures that all data is delivered and both sides are in agreement before their connection is shut down.
  
  
• 26.4 End-to-End and Virtual Connections
  
  
  • Refer to Figure 26.1 on page 431.
  • TCP is connection-oriented but the connections are virtual.
  • A TCP segment (packet) travels across a physical network encapsulated in an IP datagram.
  
  
• 26.5 Techniques that Transport Protocols Use
  
  
  • 26.5.1 Sequencing to Handle Duplicates and Out-of-Order Delivery
    • A sender assigns a sequence number to each TCP segment.
    • Receivers use the sequence numbers to make sure that they hand off segments in order to the next layer up.
    • Receivers also detect duplicate packets by checking sequence numbers.
    
    
  • 26.5.2 Retransmission to Handle Lost Packets
    • TCP uses positive acknowledgement with retransmission.
    • A receiver of a TCP segment sends a short message of acknowledgement (an ACK) back to the sender.
    • The sender has the responsibility to make sure that each segment is received intact.
    • The sender keeps track of how much time has elapsed after it sends each segment. The sender will retransmit the segment if it does not receive an ACK within a certain time limit.
    • The sender will continue in this manner, retransmitting a packet again and again if it continues to be unacknowledged.
    • After a certain number of retransmissions, the sender will eventually 'give up' and "declare that communication impossible."
    • It should be noted that retransmission can result in duplication of packets - which underscores the importance of the fact that TCP is able to deal with duplicate packets.
    
    
  • 26.5.3 Techniques to Avoid Replay
    • Replay: refers to the danger that a long-delayed packet from a previous connection will be accepted as part of a later conversation, and the correct packet bearing the same sequence number discarded as a duplicate.
    • If a protocol assigns a unique identifier to each connection, and includes the identifier in each packet, then replays can be detected.
    
    
  • 26.5.4 Flow Control to Prevent Data Overrun
    • Refer to Figure 26.2 on page 435. (There's an error in this figure - packets 7-12 should be labeled "still unsent" and 1-2 should be labeled "already acknowledged")
    • Refer to Figure 26.3 on page 435.
    • The purpose of flow control is to prevent prevent data from being sent faster than receivers can process it.
    • Stop-and-go protocols will do the trick - the sender waits for each packet to be acknowledged by the receiver before sending another packet.
    • However, stop-and-go can slow senders much more than necessary and result in unacceptably low data transfer rates.
    • A sliding window scheme is likely to work as well and produce much higher data rates. The receiver preallocates buffer space for a certain number (the window size) of packets.
    • The sender keeps track of how full the receiver's buffer is.
    • The sender only sends a packet if it is sure there is room for it in the receiver's buffer.
    • Suppose the sender knows that the receiver does not keep ACK'd packets in its buffer.
    • Then it is safe for the sender to keep sending packets until the number of un-Ack'd packets is equal to the buffer size .
    • At that point, the receiver's buffer could be full, or about to become full so the sender must pause until more packets are ACK'd.
    • Under ideal conditions, the sender can send a window's worth of packets at a time, receive an ACK for all of them as quickly as the network can carry a message back from the receiver, then send another window's worth of packets, and so on.
    • Thus under ideal conditions, if T is the time it takes for a datum to travel from the sender to the receiver and back, the sender may be able to send a window's worth of data in every time slot of length T.
    • In contrast, using stop-and-go, the sender could only send ONE packet in each time slot of length T.
    • Of course the amount the sender can send in a given time is also limited by the available bandwidth.
    
    
  
  
• 26.6 Techniques to Avoid Congestion
  
  
  • Refer to Figure 26.4 on page 436.
  • Congestion is a very real and constant 'threat' on today's networks.
  • The basic reason is that routers and links often do not have the ability to handle the amount of traffic that can potentially be injected into them.
  • One approach is to create a scheme wherein devices downstream send messages back to the sources telling it to slow down.
  • Sources can react a little faster if they just temporarily reduce their window size when an acknowledgement times out. The reason is usually congestion.
  • One advantage of relieving congestion quickly is that routers and hosts 'drop' packets when their buffers overflow. More dropped packets mean more retransmission, hence more load on the network.
  
  
• 26.7 The Art of Protocol Design
  
  
  • Protocol design details must be chosen carefully.
  
  
• 26.8 Techniques Used in TCP to Handle Packet Loss
  
  
  • Refer to Figure 26.5 on page 438.
  • In designing a protocol such as TCP, one has to be careful when programming how long TCP will wait for and ACK before retransmitting a packet.
  • Waiting too long leads to less utilization of the network and lost time on the sending and receiving hosts. Not waiting long enough means unnecessarily loading the network with duplicate packets.
  • To calculate a reasonable wait time, one should consider not only the distance to the destination, but the delay due to traffic congestion.
  
  
• 26.9 Adaptive Retransmission
  
  
  • TCP monitors delay on each connection and adapts its timeout values according to changing conditions.
  • TCP uses a formula to set timeouts that allows it to be conservative during periods when delay is fluctuating.
  
  
• 26.10 Comparison of Retransmission Times
  
  
  • Refer to Figure 26.6 on page 440.
  • Basically the timeout maintained by TCP for a connection is an amount slightly higher than the current mean round-trip delay.
  • Waiting this long is enough to conclude that the packet was probably lost. However it's not likely to be a wait that is much longer than necessary.
  
  
• 26.11 Buffers, Flow Control and Windows
  
  
  • Refer to Figure 26.7 on page 441.
  • TCP flow control follows the sliding window paradigm describer earlier, but not in every detail.
  • The TCP window is measured in bytes.
  • TCP does not use ACK's as an indication of current window size. It uses a separate mechanism called a window advertisement
  • A receiver sends a window advertisement with each acknowledgement.
  • When the receiver runs out of buffer space it advertises a zero window
  
  
• 26.12 TCP's Three-Way Handshake
  
  
  • Refer to Figure 26.8 on page 443.
  • Refer to Figure 26.9 on page 443.
  • When TCP either establishes or closes a connection, it uses a sequence of three messages.
  • These sequences are called three-way handshakes.
  • When establishing a connection, each side is required to generate a random 32-bit number called a sequence number. Sequence numbers serve as connection identifiers for use in avoiding replay problems.
  
  
• 26.13 TCP Congestion Control
  
  
  • When starting a new connection or when a message is lost, TCP backs off - it sends nothing for a while except one message.
  • If the first message is ACK'd without loss, TCP sends two additional messages.
  • If those are ACK'd normally it sends four more, and so on until reaching a point where it is sending half the window size.
  • After that it ramps up slowly and linearly slow start until reaching the window size (assuming there's no sign of congestion).
  • When TCP connections collectively use this methodology on the Internet, it works to alleviate congestion. It avoids doing a lot of retransmission, which would add to the congestion.
  
  
• 26.14 TCP Segment Format
  
  
  • Refer to Figure 26.10 on page 445.
  • TCP uses the same TCP segment format for all messages.
  • Some of the fields refer to the 'forward' data stream, and others to the 'reverse' data stream.
  • The main things are that the SEQUENCE NUMBER field is the sequence number of the first octet of data carried in the segment in the forward direction, and
  • and the ACKNOWLEDGEMENT NUMBER is the first sequence number for which data is missing in the reverse direction.