This revision to the Standard defines managed IPTV, IPTV and VoIP stream for Well Managed, Partially Managed and Un-Managed Network conditions. It also defines the remaining residual unmanaged bandwidth (Internet Services) which are typically used for TCP applications. The main difference between this revision and the previous revision is that this version is a Layer 4 (TCP) aware network model that can be used to evaluate TCP traffic.

This revision of the Recommendation utilizes the publicly available ns-3 network simulator which incorporates layer 4 TCP models. It allows more accurate characterization of bandwidth and delay for networks that carry TCP traffic because congestion causes TCP streams to back off and use less network bandwidth. The model is limited in that it is based on a single (Cubic) TCP flow. Different TCP stacks have different behaviors. however, the macroscopic behavior of TCP flows should be similar.

This Standard¹ is broadly applicable to the evaluation of any equipment that terminates or routes traffic using the Internet Protocol. This Standard can also be used to evaluate media streams or other protocols carried over IP networks. Examples of the types of equipment that can be evaluated using this model include:

• IP-connected endpoints:

- IP network devices (such as: user agents, call agents, media servers, media gateways, application servers, routers, switches, etc.);

- IP video (IPTV, video conferencing, telepresence, etc.);

- IP phones (including soft phones);

- IAF (Internet-aware fax).

• IP/TCP connected endpoints:

- Peer-to-peer

- HTTP

- Adaptive bit-rate video

• PSTN-connected devices through IP gateways:

-POTS through voice-over-IP (VoIP) gateways;

- ITU-T T.38 facsimile devices and gateways;

- ITU-T V.150.1 and ITU-T V.152 (voiceband data, VBD) modem-over-IP gateways;

- TIA-1001 and ITU-T V.151 textphone-over-IP gateways.

The IP network model can be used in two ways:

• to test an IP stream under simulated network conditions;

• to test an IP stream in real time using hardware emulation of the network model.

The IP network model can be used to study and to understand:

• the interaction of different traffic mixes;

• the effects of QoS and queuing on different types of traffic;

• packet delay variation and packet loss.

Whether in software simulation or real-time hardware emulation, users can select from several test cases specified in this Standard. Users can optionally define their own test cases. This model has the following limitations:

• Some VoIP networks may utilize PSTN at one or both ends of the connection through a media gateway. This model only addresses the IP portion of the network and does not address the PSTN portion of the end-to-end connection.

• The network model represented in this Standard does not model all possible connections that can be encountered between devices.

• This Standard includes GPON and DSL access technologies. Characteristics of other access technologies such as CATV and wireless are for further study.

• Abnormal events such as link failures and route flaps (and the packet reordering that such events can cause) are not included in this Standard.

• The standard test cases use streams of interfering traffic that were captured on live networks. While realistic, they are still just examples; users could substitute their own files of interfering traffic.

• The LAN-to-LAN test cases of ITU-T G.1050 are now modelled as two cascaded ITU-T G.1050 core-to-LAN segments. See clause 6.3.

• The IP network model presented herein is based on an informal survey of anonymous IP service providers and IP network equipment manufacturers in the 2010 timeframe and will continue to evolve as more statistical information becomes available and as the IP network evolves.

The most significant limitation of the previous edition of the model was that the best effort traffic (e.g. HTTP) is injected from a pcap file and does not react to congestion (as TCP normally would). As a result, the packet loss and delay statistics were somewhat higher than expected.

To address this limitation, the best effort traffic that was previously injected from a pcap file has been replaced by a single TCP flow using iPerf. The specific characteristics of the iPerf flow depend on the specific TCP congestion control algorithm, but generally TCP will tend to use as much network capacity as is available to best effort traffic. Therefore, the iPerf TCP flow characterizes the available network capacity and delay while competing with other managed flows.

In order to implement the iPerf TCP flows, the simulator described in this revised Standard has been completely rewritten to use the ns3 discrete event simulator.

The ns3 simulator has a direct code execution (DCE) virtual environment in which it is possible to run an actual iPerf application with an actual Linux network stack in each TCP network node. This makes the results more realistic. For the simulations in this Standard, the Linux network stacks are configured to use the “cubic” TCP congestion control algorithms.

The network topologies and test cases are the same as was implemented as in the previous revision of the simulator, with the exception that all best effort traffic injected from pcap files has been removed and replaced by a single iPerf TCP flow.

It should be noted that although most networks of interest carry multiple concurrent TCP flows, the aggregate goodput of the flows tends to converge to the same value as a single iPerf flow would. Therefore, it is not necessary to characterize more than one parallel iPerf TCP flow in this simulator.

Finally, as a result of interactions between downstream and upstream iPerf TCP flows, each test case is run three ways:

• iPerf downstream only

• iPerf upstream only

• iPerf bidi (runs downstream and upstream together, which interfere with each other)

¹ This Recommendation includes an electronic attachment containing the discrete event simulator source code, input packet capture files of interfering traffic, standard test cases and the simulator output.