Ethernet Test
To successfully exchange information, two networked devices need a series of protocols allowing the applications to communicate. This protocol suite, called TCP/IP, consists of a series of stacked protocols, layered one on top of the other. Each layer has a specific function and will provide services to the upper layers. The top layer — the Application Layer — uses the layers underneath it to communicate with another end-device. One of the most important layers in this process is the Transport Layer, as it is the entry point to the Host category of layers and it is responsible for the end-to-end connections; i.e., the Transport Layer ensures that the data segments are transfered from the network toward the application.
Applications use two types of transport protocols to communicate between all of their locations; User Datagram Protocol (UDP) and Transport Control Protocol (TCP). These protocols are part of the TCP/IP protocol stack that provides the complete architecture to exchange data between two networked devices. Depending on the application being run, the transport protocol will be different. If the application is used in real time and the loss of information is not critical, UDP will be used, as this protocol is simple, efficient and faster than TCP. For applications such as IPTV, VoIP or online gaming, it is the perfect protocol. On the down side, this protocol does not provide the reliability and ordering guarantees that TCP does. Information may arrive out of order or go missing without notice.
TCP performance across a network is dependent on multiple parameters, so what are the testing options? Historically, service providers have used a test methodology based on RFC 2544 (Benchmarking Methodology for Network Interconnect Devices). This methodology provides a great way to assess the performance of a network if the applications running on it are UDP-based. The throughput, frame loss, burstability and latency tests provide a thorough snapshot of the quality of the network and are at the base of all current SLAs. That being said, if the applications are running on TCP, this methodology will only provide a general idea of how good the network is, but it cannot assess the quality of service an end-user will experience.
By having a tool that can send TCP traffic across the network from each demarcation point in the network and should that tool be based on a neutral TCP/IP implementation, service providers would have the perfect methodology to actually prove that their network is not at fault. After that, they can provide the parameters measured to the end-users so they can try to replicate the test results from their test methodology.