Different types of traffic have different sensitivities to delay,jitter, and packet loss: there is no "one size fits all" recipe. Thus, the focus of this topic is not to describe every single possible type of traffic but rather focus on three specific subjects: the Transport Control Protocol (TCP) protocol, real-time traffic, and the evolution of user session durations.
TCP is a widely deployed transport protocol used at Layer 4 in the OSI model. It is a popular transport protocol because it provides flow control and traffic retransmission in the case of packet loss. This topic discusses how the features of TCP fit into the QOS realm. Real – time traffic encompasses a huge range of different applications and services and in this topic, we will focus on the common dynamics and requirements shared by all of them in regards to QOS. Finally, this topic examines the duration of the session, and here we examine what changes if the traffic flow lasts a few seconds, or a few hours, and compare the long-lasting session with the short session.
Anatomy of the TCP Protocol
Transport Control Protocol (TCP) is an extremely popular protocol used for transport at Layer 4 of the OSI model. Numerous papers and topics describe the TCP protocol in detail, several of them referenced in the further reading section of this topic. TCP is defined in RFC 793 [ 1] . The main goal of this topic is to arm the reader with the knowledge to understand key terms such as "TCP slow start" and "TCP synchronization" that are commonly used when discussing mechanisms for handling TCP congestion. The use of QOS tools to change TCP traffic behavior in a congestion scenario is a common topic in recent publications about QOS. However, the current TCP protocol implementations have evolved a long way from the publication of the standard in 1981. And there are some "well-known truths" that have been established since then. So let’s start with a very brief introduction to the TCP protocol, and then focus on enhancements that have been added to the protocol to make it more robust. About 90% of the traffic in today’s packet networks are handled by TCP sessions. While video and voice are "cool" features, they provide only a small part of the reason to enable QOS on the network. TCP is pretty much the bearer channel for the Internet, so knowledge of how it works is always important, no matter how much video and voice may distract. The main characteristics of TCP are described in following points:
• TCP is a connection-oriented protocol. Receivers send an ACK (acknowledgment) to the source of packets when they receive a packet. Packets that have not been acknowledged within a certain timeframe are retransmitted by the source.
• The source does not wait indefinitely for the ACK for a transmitted packet, there is a timeout value.
• TCP packets have a sequence number. If the destination receives a packet out of sequence, it sends a double ACK to the source, informing the source that an out-of-sequence packet has been received and which sequence number is expected.
• A parameter called "window size" specifies the number of bytes the receiver is willing to receive.
• TCP is adaptive. The window size, timers and other parameters are not statically defined and can vary during a TCP communication based on feedback messages between source and destination.
• TCP is greedy. It always tries to increase the sending and receiving windows to transmit more quickly.
• TCP is robust. The detection of packet loss because of receipt of duplicate ACKs or timeouts will cause TCP to slow down, but it is very eager to jump back into the fast lane again.
All these factors are common to every TCP implementation. However, the last parameter, robustness, has improved significantly with newer TCP developments. The TCP session between a sender and a receiver is a stream of bytes. The stream is divided into transmissions of partial data units. The unit that is transported between the TCP sender and receiver is called a segment. A segment is the micro part of the session stream (which is the macro part). To be able to keep track of what has been sent and successfully received, the source assigns a sequence number from a 32-bit wide field to each byte in the stream. For example as illustrated in Figure 4.1, a stream of a large file, say, containing a hip MPEG tune, is divided into chunks of segments.
The receiver and the sender exchange the starting sequence number value in the opening phase of a TCP session, and it is updated during the process of exchanging the whole stream. This process is one of the killer features of TCP. Segments can arrive at the receiver out of order, or sometimes a little late, but it’s okay because the receiver can re-order it by keeping track of the byte positions associated with each segment’s number. Another killer feature of TCP is that the transmission of each segment is acknowledged (ACK). In a nutshell, this is the TCP reliability function. Each segment, and thereby each received byte position, is ACKed to the sender by the receiver. The ACK can be for one segment or be for several in one window of the transmission, as illustrated in Figure 4.2.
Figure 4.2 The TCP acknowledgment of segments
Simply stated, the TCP reliability process is that the receiver acknowledges what has been received. Packets can arrive from the Internet in a different order from how they were transmitted, or drops can occur because of congestion or network failures. If the receiver realizes that a segment is missing, it generates a duplicate ACK from the last received segments, thereby notifying the sender that a retransmission is required, as illustrated in Figure 4.3.
In summary, the popularity of TCP is to a great extent due to its reliable transmission. The applications on top of TCP can safely trust TCP’s mechanism to deliver, for example, HTTP can focus on its specific tasks and can leave the delivery to the TCP layer below, relying on TCP to fix any transport issues and to pack and unpack files in the proper order and byte position. It is the end hosts (that is, the sender and receiver) that are responsible for this process, thereby relieving the intervening network transport elements of the need to perform transmission control (one example of a protocol in which the transport elements handle the retransmission is X-25). Just imagine if every router on Internet were required to maintain the state for each session, and be responsible, and ACK every packet on all links. The Internet would definitely not be what it is today were if not for IP and TCP.
Figure 4.3 The TCP Misordering and Duplicate ACK
Figure 4.4 The TCP three-way handshake process
The TCP Session
To understand the TCP guarantee delivery mechanism, let’s look briefly at some simple packet traces from an Secure Shell Copy (SCP) transfer. There is nothing special here, SCP just happens to be one protocol with a packet transfer session based on the TCP delivery mechanism.
Any TCP session starts with the classic three- way handshake that probably many readers of this topic have been forced to identify in networking tests: the sequence SYN, SYN-ACK, and ACK. Figure 4.4 shows a successfully established TCP socket between sender 192.168.0.101 and receiver 192.168.0.27.
The messages in the handshake exchange can appear terribly confusing. Let us briefly discuss some of the parameters in the exchange that set the tone for the session’s performance.
The Maximum Segment Size (MSS) is the largest chunk of data that TCP sends to the other end in one segment. Here, both ends of the session use 1460, which is the size that results when you subtract the TCP header (20 bytes) and the IP header (20 bytes). This MSS assumes that the minimum Maximum Transmissions Unit (MTU) can handle 1500-byte packets excluding the media header (here, we have Ethernet with no VLAN header, so the packet size is 1514 bytes, including media header). The end station’s ability to discover the MTU along the path over which the packet travels is handled later in this topic, with the PMTU.
Window size is the raw number of bytes that the end station can receive or transmit before sending or receiving an acknowledgment (ACK). In a session, the receiver uses the receive window size to control the flow and rate from the sender. While the details of window tuning are beyond the scope of this topic (a quick Internet search will provide all the details you want or need). One important concept with regards to QOS is the sliding window , which is the ability to change the window size over time to fully optimize the throughput.
The congestion window (cwnd) is related more to the sender than to the source because it is used to implement flow control by the sender, and it controls what the source can send with an outstanding ACK. The cwnd is fully dynamic and can increase or decrease based on the feedback received from timers and ACKs from the receiver.
By the way, some of the other parameters in the three-way handshake, such as Sequence ACK (SACK), and window scale support, are discussed later in this topic.
So, once the TCP session has been established, the sender 192.168.0.101 starts to send datagrams to the receiver 192.168.0.27. Depending on the TCP implementation, one or two segments of MSS full-sized packets are sent, as shown in Figure 4.5. -n Figure 4.5 , the sender sends segments starting with sequence numbers 2902 and 4350.
Figure 4.5 Double push
Figure 4.6 Big push
Because the packets arrive in sequence, the receiver needs to ACK only the last sequence byte size ending, which is 5798 (4350 + 1448). This is TCP’s way of optimizing the session speed. Consistent with TCP’s greedy behavior, the sender ramps up the transfer of packets without waiting for an ACK. The delivery control is based upon feedback in the ACK message from the receiver as shown Figure 4.6.
So in the perfect world, and the perfect network, the session’s speed is ramped up to the receiver ‘ s window size and the sender ‘ s congestion window. Any issues with the delivery are handled by the sequence control in the ACKs received and with the timeout window.
