Closing the turn-up gap

As Sam Darwish of Microlease and Samuel Bureau, Director-SSO Broadband Networks EMEA, Viavi (formerly JDSU), explain, a major gap in installation testing is the omission of transmission control protocol (TCP) layer tests. Without these, providers cannot replicate the network performance experienced by customers.

Above: illustration of TCP in-flight data bytes on a 45Mbps WAN link with 25ms RTD

Network and CPE issues

TCP operates at OSI Layer 4 and resides on top of IP Layer 3. A major feature is inherent reliability - if packets drop, TCP ensures they are retransmitted to the receiver. On a wide area network (WAN) link, TCP must be configured to adjust the number of bytes senders can transmit before receiving an acknowledgement. This number of bytes ‘in-flight’ is referred to as the TCP window, and needs tuning to achieve optimum throughput.

TCP transmits and receives data in bursts rather than a constant bit rate. A Gigabit Ethernet (GE) LAN on a 100Mbps WAN will result in several instances where the WAN improperly handles GE bursts, causing dropped packets and TCP retransmissions.

Key methods to downshift TCP from a LAN to a WAN are buffering and traffic shaping. Using RFC 6349 test methods before customer activation will optimise TCP throughput over the WAN.

RFC 6349 TCP test methodology

RFC 6349 is the new TCP throughput test methodology that provides repeatable test methods for TCP throughput analysis - with systematic processes, metrics and guidelines to optimise network and service performance.

RFC 6349 recommends conducting a Layer 2/3 turn-up test ahead of conducting path MTU detection (per RFC 4821), baseline round-trip delay and bandwidth, and finally, single and multiple TCP connection throughput tests.

Rather than simply counting the number of retransmissions, RFC 6349 defines a new metric to gain insight into the relative percentage of a network transfer used in retransmission of payloads. The TCP efficiency metric is defined as:

* ‘transmitted bytes’ includes both original and retransmitted bytes.

This metric allows comparison between various QoS mechanisms such as traffic management or congestion avoidance, and between different TCP implementations such as Windows XP and Linux. It allows network providers to establish a TCP loss threshold for various class-of-service (CoS) levels.

RFC 6349 also defines the buffer delay percentage (BDP) as the increase in round-trip time (RTT) during a TCP throughput test from the RTT inherent to the network path without congestion.

The BDP is defined as:

Such metrics fill the gap between the end user experience and the manner in which the provider tests the network. Typically, two reasons account for business customer complaints of poor application performance - business customers misconfiguring the customer equipment or running flawed ‘speed test’ procedures, and network providers failing to optimise TCP traffic.

Non-optimal TCP configuration

The first case is exemplified by a business customer with two locations who purchased a 100Mbps transparent LAN service from a business provider. RFC 2544 testing demonstrated on-spec throughput of 100Mbps, yet the customer’s speed test using FTP downloads and uploads showed just 25Mbps throughput. Naturally, the business customer was unhappy and contested the service provided. Much finger pointing followed, along with several truck rolls during which provider technicians re-ran RFC 2544 tests.

It turned out that the business provider’s long fat network (LFN) needs much larger TCP window settings in end host computers. RFC 6349 specifies the TCP window setting for such a 100Mbps, 20ms latency network as 250kB, but the end customer was not using window scaling on one of the servers, resulting in a maximum window of only 64kB - thus achieving just 25Mbps of the 100Mbps CIR.

Estimated additional OpEx costs to the provider were around $7,000, leading them to adopt the RFC 6349 test methodology in future standard service activation procedures.

Above: the business customer’s 300Mbps transparent LAN configuration

Inadequate network buffers

A second real life example involves a business customer who purchased a 300Mbps transparent LAN service with approximately 50ms latency between two locations. RFC 2544 test results confirmed the specified 300Mbps performance but, again, the customer’s speed test run by the network provider using iPerf (a commonly used network testing tool) clocked throughput at just 95Mbps.

A blame game ensued along with several truck rolls to re-run the RFC 2544 test. Lacking confidence in the provider’s results, the end customer demanded some form of TCP layer speed test from the provider.

Above: contrasting traffic shaping versus policing

This made use of RFC 6349’s parallel TCP connection testing. The Viavi TrueSpeed solution was able to replicate this test scenario, using a Viavi hardware TCP solution to remove uncertainty about whether the processing performance of the end customer’s workstation running iPerf had affected test results. This confirmed that the network could only achieve 95Mbps throughput - just as the end customer claimed. The provider identified the problem as inadequate default buffering in an edge routing device. Increasing its buffer size enabled verifiable 300Mbps TCP performance.

As with the first case, additional OpEx costs to the provider were substantial - estimated at $15,000. As before, this prompted the provider to start using RFC 6349 test methodologies in standard service activation procedures.

In both cases, augmenting RFC 2544 and/or Y.1564 service activation with an RFC 6349-based test enables providers to share the customer’s network experience, substantially save on OpEx, and dramatically increase first time customer satisfaction.