Understanding UC, Adaptive Video, and Data Traffic Interaction

Transcription

1 Understanding UC, Adaptive Video, and Data Traffic Interaction Different types of network traffic can make dramatically different demands on the network. Unified communications (UC), which can include voice and video conferencing, is unique from YouTube or Netflix streaming video standards, as well as traditional data like database servers and backup servers. Learning the underlying network and protocol concepts for these three distinct traffic types enables more effective maintenance, support, and troubleshooting using tools like Wireshark and the Observer Performance Management Platform. Access links to the internet commonly are either very symmetric, such as 50 Mbps down/50 Mbps up, or very asymmetric, such as 10 Mbps down/1 Mbps up. Studies based on the two types of links can aid in understanding traffic utilization, as they tend to magnify protocol stack characteristics and related traffic behavior. These studies can be repeated easily for various enterprise connections, although they tend to display more symmetric network activity. Before diving into the details and complexities of UC, adaptive video, and data traffic interaction, start with a foundational understanding of the transport layer protocols that support them. Modern networks that use TCP/IP have two important transport protocols: Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). They transport data across networks very differently, so it is important to differentiate how they work and how they differ in their packet transport mechanisms. A connection-oriented protocol, TCP is generally used for traditional data applications such as file transfers and system backups. It is also used for web page retrieval and adaptive bit rate video. Currently somewhere between 85 and 95 percent of all network traffic uses TCP. On the other hand, UDP is a connectionless transport protocol and used for applications like short queries, VoIP, and video conferencing. While TCP carries the bulk of our information, its operation is actually one of the least understood aspects of networking. White Paper

2 The UDP Protocol In the middle of the protocol stack, UDP sits under the application and over the network. Compared to TCP, UDP is a simple protocol that connects the application to the network and provides these three functions: The second goal is to deliver extensive amounts of time-sensitive data. That s why it s used for voice and some forms of video. Indicates the address, known as the port, of the sending and receiving applications Records the amount of application data in the packet being transferred Provides no error check on the data being carried as that is the responsibility of the receiving application There are some notable missing characteristics to the protocol which we normally expect to see in data transfers. Specifically, the absence of sequence numbers makes it difficult to determine the correct order in which packets should have been received. In addition, there is no method to control the rate of flow between the two UDP partners. This is the reason that certain protocols are often used in conjunction with UDP. Most notably, Real-Time Protocol (RTP) is partnered with UDP to add sequencing, timing, and payload type information. Figure 2: DNS queries Figure 1: A VoIP packet Sequence number Audio source VoIP packets use RTP in conjunction with UDP so that loss rates can be detected, separate sound sources in stereo can be identified, and packets arriving out of order can be re-ordered. Videoconferencing usually uses RTP/UDP for the same reasons. Applications usually have two goals that UDP serves to meet. First, the application needs short answers to questions such as with Domain Name Services (DNS) requests. A query can be sent to a DNS server asking what address corresponds to the IP address x.x.x.x. In Figure 2, you can see this in the Observer Analyzer screen shot of captured data, where a series of DNS queries were executed within a few minutes. However, in Figure 3, the Analyzer screen shows that none of these queries used more than several thousand kilobits of bandwidth. Figure 3: DNS queries bandwidth consumption The UDP software is a part of the operating system, and it s also present in Linux, Windows, Android, OSX, and so forth. For the most part, because it is such a simple protocol, various implementations of UDP interoperate very successfully. Figure 4 shows the behavior of a VoIP call. Some variable bandwidth was used when the call was established utilizing the H.323 protocol (a TCP-based protocol). At about t = , the actual transfer of voice and the bandwidth used is nearly constant at about 80 kbps. This is low partly because the G.729 codec is compressing the voice packets. Figure 4: A VoIP call 2 Understanding UC, Adaptive Video, and Data Traffic Interaction

3 The TCP Protocol TCP is similar to UDP in a few ways. For example, it sits in the middle of the protocol stack under the application and over the network. It also uses port numbers to identify the sending and receiving applications. To support transporting the application data across the network, TCP provides the following: Sequence numbers to: Indicate the correct order of the delivered packets, which are called segments Record the actual number of bytes transferred Receive TCP responses to determine that data was lost or not yet delivered All current versions of TCP begin a formal session with a three-way handshake to negotiate the exchange of parameters, as shown in Figure 5. These parameters include: The sending and receiving of port numbers that will be used to identify the respective application processes The maximum and initial receiving window for each or how much data can be accepted in the receive buffer Where explicit congestion notification (ECN) will be used Each entity s initial sequence number Each entity s maximum segment size Three-way handshake Explicit indication that a segment of data was received Means for each of the communicating entities to restrict the rate of its partner s transmission, referred to as flow control Formal negotiation of the parameters for the exchange in the session start-up (as part of the three-way handshake) A transmitting TCP station uses a sophisticated algorithm to track its relationship to the quality of the network and the receiver s ability to receive what is being sent. Over the years, the TCP algorithm has evolved through various versions such as Reno, New Reno, Compound, and Cubic. However, the goal for each of these algorithms has been to maximize the amount of data being transferred subject to the quality of the network connection and the receiver s ability to successfully get the data; therefore, TCP is adaptive. It will change its sending rate dynamically depending on changing network conditions and receiver capabilities. Like UDP, the particular implementation of TCP depends on the operating system of which it is a part. For example, Windows XP used New Reno; however, Windows 8 and 10 used Compound TCP. The differences are beyond the scope of this paper. Figure 5: The three-way handshake Nearly all TCP transfers are half-duplex, meaning one-way at a time. When a sending TCP station has negotiated the start-up of a session, it begins to send data in a phase called slow start as shown in Figure 6 from the Observer GigaStor Time Series Analysis option. Figure 6: Slow start 3 Understanding UC, Adaptive Video, and Data Traffic Interaction

4 A typical send policy might be to send two segments and wait for an acknowledgment of that data. When the acknowledgment arrives, it increases the number of segments it is allowed to send by two and now sends four segments. With each acknowledgment of a data segment, it raises the number it is allowed to send by one. Figure 7 was created using Analyzer s Connection Dynamics. By filtering on one direction in the FTP transfer (from the server to the client), we see the second step in the three-way handshake, followed by the initial transfers of data packets. A close look at the delta times reveals that the server sent four data segments separated by less than one millisecond. Then, it waits for 30 milliseconds for acknowledgments. Figure 8: Slow start accelerates Delta time This illustrates one of TCP s most important features. It is designed to saturate the link or the receiver, whichever happens first. Think of a pipe, with a certain capacity, placed through the network. TCP tries to use all of the available bandwidth in the connection. In this particular instance, the connection s maximum capacity was 20 Mbps. (20 Mbps downlink, 2 Mbps uplink). This can be seen by again referring to Figure 6. The lower half shows that FTP used TCP to saturate that connection (2.5 MBps or 20 Mbps). So, what factors can affect the rate at which a TCP sender can transmit its data? Figure 7: Slow-start initial data segments The decode screen allows us to see the segments transferred during a longer period of time. The packet capture shown in Figure 8 was created in GigaStor using a one-way filter on the file transfer. It shows that four packets (2, 3, 4, and 5) were sent. Then after a pause, frames 6 through 13 followed for a total of eight packets transmitted. It continues to raise its rate of transmission until it reaches a value called its slowstart threshold. At this point it enters a new phase called congestion avoidance. The purpose of the first phase is to aggressively increase the sending rate, while monitoring acknowledgments from its partner. The second phase serves the purpose of more gradually increasing the rate, assuming that at some point congestion will be encountered. Competition from other flows UDP flows will usually demand a fixed or nearly fixed amount of bandwidth, which lowers the amount of bandwidth available to the TCP entity (it will throttle to the amount available). TCP flows from other stations will cause variable bandwidth use depending on the current state of their flows. Errors in segments or dropped packets that require retransmission Competition for the flow in the reverse direction; while often overlooked, congestion or heavy use of the uplink will slow acknowledgments, decreasing the rate at which a TCP station can download its data. 4 Understanding UC, Adaptive Video, and Data Traffic Interaction

5 The final aspect of TCP to consider is how TCP discovers that congestion exists and its need to slow its transmission rate. It may come as a surprise, but that s the purpose of dropped segments. As TCP begins to saturate the link, buffers fill resulting in packets being discarded. While generally thought to be a bad thing, it s what TCP expects when the link is filled to capacity. Errors at the physical level will cause TCP to assume congestion is present as well and, occasionally, that may be a correct diagnosis. Though, it is not as common as buffer overfill. The typical TCP implementation follows this policy. A packet is discarded, then the sending TCP stack: Receives duplicate acknowledgment of the previous segment (called a dup ACK). Continues to send data, assuming the missing segment is still in the network somewhere. Receives dup ACK #2 and dup ACK #3. Now assumes the packet has been dropped and retransmits it. Looking again at the Stevens graph, we can see that after a few frames, the rate of transmission decreases. That is, the slope of the curve is lower. It gradually climbs back up until at about 42 seconds returns to the previous throughput rate. The Interaction of Various Traffic Types In the first example, consider how FTP/TCP interacts with an HTTP/TCP. Remember that FTP is an application that depends almost entirely on how the TCP algorithm works. Also, adaptive bit rate video typically implemented by Adobe HDS, Microsoft Smooth Streaming, and Apple HLS is a series of short file transfers that depend on the TCP algorithm. Each of these transfers carries about 10 seconds of video. The example, based on a file transfer, coincides with a Netflix adaptive bit rate transfer. Figure 10 shows a Wireshark plot where the total bandwidth uses about 20 Mbps (the black line), which is the capacity of the connection. Cuts the rate at which it is sending frames and re-implements slow start at the lowered level. Wireshark illustrates this in Figure 9 where the left part of the screen shows the packets in this TLS/TCP transfer. This was a capture from an adaptive bit rate video transfer. The client playing the video is at , and the video is being transferred toward that device. Figure 10: FTP interacts with adaptive bit rate video Figure 9: TCP reaction to lost dropped segment The right side of the screen shows a Stevens Sequence graph. It shows sequence numbers on the left axis and time along the bottom axis to the right. Since sequence numbers measure bytes transferred, this graph nicely shows the throughput rate as the slope of the curve. Since this is an adaptive bit rate video transfer, the server usually sends data in chunks representing about 10 seconds of video. At approximately t = 38.5 seconds, we see the end of the last chunk. At about t = 40.6 seconds, the transfer starts again about the same rate. However, this time frame number is out of order because a segment was dropped. The total bandwidth used is nearly what is available, at 20 Mbps. However, when Netflix is transferring data (indicated by the green line), the FTP data transfer slows (indicated by the red line). In fact, the two TCP applications share almost exactly the available connection capacity. When the green transfer data rate is higher, the red FTP data transfer rate is lower. Clearly, the FTP throughput will be limited by the fact that it is sharing the link with another TCP application. 5 Understanding UC, Adaptive Video, and Data Traffic Interaction

6 In the second example, shown in Figure 11, the same FTP application shares bandwidth with another TCP application. However, this time the second application is an upload. In this case, we have an FTP download when a Dropbox upload proceeds. Figure 12: Video conference bandwidth use The result of starting a download with the same video conference session is shown in Figure 13. Figure 11: An FTP download Interacts with an upload In the beginning of the FTP transfer, the full 20 Mbps connection capacity is used, but at about t = 16 seconds the upload of a file to a server competes for the same bandwidth, resulting in several oscillations in total throughput, including a drop in total bandwidth usage to about 6 Mbps. In the previous example, the two applications shared the connection. But why would the upload affect the throughput of the download? The answer is that the ACKs to the download are being delayed while traversing the uplink. It takes a little time until TCP can react properly. When it does at about t = 18 seconds, the total bandwidth approaches the total capacity of the connection: 20 Mbps down + 2 Mbps up. The next example involves a mix of TCP and UDP traffic. First, let s review how a video conference uses the available bandwidth. The black line in Figure 12 shows the total bandwidth used by this conference. It averages about 2 Mbps. These fluctuations primarily are due to the variability compression on each video frame. Since this conference is over a DSL 20 Mbps downlink and 2 Mbps uplink line, we can see that the video is going up (red varies around an average of 2 Mbps.) The video going down is around 500 kbps. This apparent imbalance is because the person at the opposite end from is on a wireless link. This vendor s video conferencing server selected a very low resolution to accommodate the fluctuation inherent in wireless bandwidth. Nevertheless, once the conference is established, the bandwidth fluctuates around a constant average value in each direction. Figure 13: Video conference sharing bandwidth with FTP/TCP Here, the video conference is using about 1 to 2 Mbps. The FTP file transfer adjusts its demand for bandwidth to very slightly less than 20 Mbps. Again, we see the FTP/TCP takes all the bandwidth that it can. 6 Understanding UC, Adaptive Video, and Data Traffic Interaction

7 Conclusions Cisco and others have predicted that networks will continue to carry increasingly more video. Cisco indicated in their Visual Networking Index that video is already more than half of total network traffic, and the amount of video traffic on the Internet may reach 80 percent by It is very likely that such traffic will continue to appear on corporate enterprise networks. In addition, as more employees work from home or on the road, the composition of traffic in the Internet will profoundly impact productivity. As a result, there is a growing need to understand how this traffic interacts with more traditional data and voice traffic. One trend on which to focus is the rapid increase in the use of IP technologies in the audio/video (AV) industry. At major AV trade shows like InfoComm and NAB, which far exceed the size of Interop, the buzz is constantly about IP products. Devices such as cameras, microphones, encoders, audio conference bridges, and digital video recorders (DVRs) are going to increase IP traffic even more. Just as IT absorbed the telecom function during the early part of the twenty-first century, it seems that IT will gradually absorb the AV functions with significant implications to network performance and traffic pattern behavior. This paper highlighted the following key points: IT services that use UDP traffic, such as voice and video conferencing, normally require a relatively fixed amount of bandwidth. When deployed, they will consume network resources at the expense of TCP applications that share the connection. TCP applications are generally either bursty or continually take all of the available link bandwidth. However, the total bandwidth they use will depend on competing traffic and the quality of the network. Understanding the TCP operation is important in determining whether we are seeing good or poor overall service and application performance. The Observer platform from Viavi and the Wireshark network analyzer are tools that can facilitate the understanding of these two protocols and the applications that run over them. They will also help to differentiate between normal protocol operation and performance problems. 7 Understanding UC, Adaptive Video, and Data Traffic Interaction

8 Contact Us GO VIAVI ( ) To reach the Viavi office nearest you, visit viavisolutions.com/contacts Viavi Solutions Inc. Product specifications and descriptions in this document are subject to change without notice. understandinguc-wp-ec-nse-ae viavisolutions.com