Export PDF
What Is iFlow?
iFlow is a measurement technology implemented at the transport layer. It can monitor the quality of both long-flow and short-flow services, extending the full-lifecycle monitoring capability of key applications. It also provides one-stop, visualized all-flow poor-QoE analysis services for applications and networks.
Why Do We Need iFlow?
On a campus network, key services include audio and video conferencing, live streaming, screen mirroring, and collaboration. Currently, only audio and video conferencing can be effectively monitored. When an exception occurs on other key services, the fault is difficult to demarcate and causes significant deterioration to user experience. Existing application quality measurement technologies include native-IP In-situ Flow Information Telemetry (IFIT) and Application-network Quality Measurement (AQM). The following describes their advantages and limitations.
- Native-IP IFIT (iPCA2.0): a dual-end in-band flow measurement technology deployed based on real services, and can accurately reflect the service quality. However, native-IP IFIT has two limitations. One is that it applies only to long-flow services, such as audio and video conferencing, live streaming, and video on demand (VOD), but not to short-flow services, such as shared document editing, instant messaging (IM), and cloud desktop. This is because native-IP IFIT directly colors service packets for measurement, resulting in inaccurate statistics in the first two periods. The other is that native-IP IFIT cannot be extended to more applications due to limited specifications.
- AQM: a single-end simulation measurement technology that dynamically adjusts the packet sending frequency based on the network quality and simulates application characteristics to make the measurement result more accurate. However, AQM is mainly used for quality assurance of audio and video conferencing services. It presets key characteristics of top applications and cannot monitor the quality of other applications such as TCP-based shared document editing.
iFlow is developed to provide a solution to the preceding limitations in application network quality monitoring scenarios. Targeting the transport layer, iFlow performs measurement based on the TCP packet headers of real service traffic without packet modification. iFlow can monitor the quality of both long and short flows, extending the high-quality experience assurance from only audio and video conferencing to more high-value applications. iFlow supports single-node, two-node, and multi-node deployment. It measures performance indicators such as packet loss, delay, and throughput of services to provide one-stop all-flow poor-QoE analysis capabilities for applications and networks in an end-to-end manner (from terminal to WLAN, LAN, WAN, and server). iFlow can also report statistics to the NMS, which displays the statistics in the network digital map. In this way, it improves the visualized user experience and O&M efficiency, and helps build an intelligent O&M system.
iFlow is applicable to large and midsize campuses in a range of sectors such as manufacturing, finance, and government, extending the poor-QoE analysis capability to more key applications and enhancing the full-lifecycle monitoring capability for applications. The poor-QoE analysis results of iFlow can be used for application fault demarcation, enabling E2E visualization of application quality.
How Does iFlow Work?
iFlow implements all-flow poor-QoE analysis based on the delay measurement on TCP connection setup and performance measurement on TCP traffic.
Delay Measurement on TCP Connection Setup
iFlow measures the network delay of TCP applications by measuring the TCP connection setup delay. By defining a group of performance indicators, iFlow provides data support for subsequent network and server optimization.
Process of TCP connection setup delay measurement based on iFlow
The preceding figure shows the process of measuring the TCP connection setup delay using iFlow. The process involves three roles: client, server, and monitoring point.
- Client: a PC or another kind of terminal that provides applications to users.
- Server: a server, such as a file server, that provides services to clients.
- Monitoring point: collects network delay data for administrators to view.
The TCP connection setup is based on the TCP three-way handshake. On this basis, the TCP connection setup delay measurement process of iFlow includes the following steps:
- After receiving the SYN request packet sent by the client for the first handshake, the monitoring point obtains the source and destination IP addresses, creates a bidirectional flow table, records the timestamp T1, and sends the request packet to the server.
- After receiving the SYN-ACK response packet sent by the server for the second handshake, the monitoring point records the timestamp T2, calculates the server network delay TCP_SND, and sends the response packet to the client.
- After receiving the ACK response packet sent by the client for the third handshake, the monitoring point records the timestamp T3, calculates the client network delay TCP_CND, and sends the response packet to the server.
- The monitoring point generates network delay statistics for administrators to learn about the network quality. The following table describes the performance indicators.
Table 1-1 TCP connection setup delay indicators based on iFlow
Name
Description
Calculation Method and Principle Description
TCP_SND
Server network delay
TCP_SND (unit: ms) = T2 – T1
The value is the interval between the time when the monitoring point sends the SYN-ACK response packet to the client and the time when the monitoring point receives the SYN request packet from the client during the TCP three-way handshake.
TCP_CND
Client network delay
TCP_CND (unit: ms) = T3 – T2
The value is the interval between the time when the monitoring point sends the SYN-ACK response packet to the client and the time when the monitoring point receives the ACK response packet from the client during the TCP three-way handshake.
Performance Measurement on TCP Traffic
iFlow uses the TCP traffic performance measurement function to monitor specified service packets on each node of an IP network in real time and quickly demarcate the faulty network segment based on the monitoring results of multiple nodes.
Deployment modes
To monitor network quality and demarcate faults, iFlow can be deployed on a single node, two nodes, or multiple nodes on the network. The deployment modes are described as follows:
- Single-node deployment: As shown in the following figure, iFlow is deployed on a node (monitoring point) to demarcate faults on the downstream network (segment 1 in the figure) and upstream network of the monitoring point (segment 2 in the figure).
Single-node iFlow deployment - Two-node deployment: As shown in the following figure, iFlow is deployed on two boundary nodes — access switch and core switch — to demarcate faults on the downstream network of the access switch (segment 1 in the figure), the network between the access switch and core switch (segment 2 in the figure), and the upstream network of the core switch (segment 3 in the figure).
Two-node iFlow deployment - Multi-node deployment: As shown in the following figure, iFlow is deployed on multiple nodes to demarcate faults on the WLAN between terminals and the AP (segment 1 in the figure), the network between the AP and access switch (segment 2 in the figure), the network between the access switch and core switch (segment 3 in the figure), and the upstream network of the core switch (segment 4 in the figure). For example: Packet loss is detected on the access switch and core switch, but not on the AP, so it can be determined that a fault occurs on the network between the AP and access switch.
Multi-node iFlow deployment
Performance indicators
iFlow monitors the quality of TCP services and locates TCP service faults in real time. It obtains performance indicators from devices based on a specified period and periodically reports the indicators to the NMS. iFlow calculates TCP performance indicators based on TCP packet analysis. The average rate is calculated based on the length of TCP packets transmitted within a measurement period. The upstream and downstream packet loss rates are calculated based on the sequence numbers in TCP packet headers. The average two-way delay between the device and the server and client is calculated based on the timestamps and sequence numbers in the TCP packet headers.
Process of TCP traffic performance measurement based on iFlow
The preceding figure shows the process of TCP traffic performance measurement based on iFlow. The following table describes the performance indicators.
Name |
Description |
Calculation Method and Principle Description |
|---|---|---|
MFR |
Average bit rate (throughput) within a measurement period |
MFR (unit: bit/s) = Total length of packets received within the period/Actual valid flow duration |
SPLR |
Average packet loss rate on the upstream network of the monitoring point within a measurement period |
SPLR (unit: 0.01%) = Number of packets lost on the upstream network/(Total number of received packets + Total number of lost packets) If no packets are lost, the sequence number of the current packet plus the packet length is the expected sequence number of the next packet. If the sequence number of a packet is greater than expected, the device determines that packet loss occurred on the upstream network, and the number of lost packets can be calculated based on the average packet size. |
CPLR |
Average packet loss rate on the downstream network of the monitoring point within a measurement period |
CPLR (unit: 0.01%) = Number of packets lost on the downstream network/(Total number of received packets + Total number of lost packets) If no packets are lost, the sequence number of the current packet plus the packet length is the expected sequence number of the next packet. If the sequence number of a packet is smaller than expected, the device determines that the packet is a retransmitted one. The number of retransmitted packets can be considered as the total number of lost packets. Based on this, the number of packets lost on the downstream network is obtained as follows: Number of packets lost on the downstream network = Total number of lost packets – Number of packets lost on the upstream network. |
SRTT |
Average two-way delay between the monitoring point and the server within a measurement period |
SRTT (unit: ms) = T4 – T3 The monitoring point randomly selects a received non-retransmitted packet, and records its timestamp as T3. The expected sequence number of the next packet is calculated based on the sequence number and length of the current packet. If the sequence number of an ACK packet sent from the server is greater than or equal to the expected sequence number, the timestamp of this packet is recorded as T4. |
CRTT |
Average two-way delay between the monitoring point and the client within a measurement period |
CRTT (unit: ms) = T2 – T1 The monitoring point randomly selects a received non-retransmitted packet, and records its timestamp as T1. The expected sequence number of the next packet is calculated based on the sequence number and length of the current packet. If the sequence number of an ACK packet sent from the client is greater than or equal to the expected sequence number, the timestamp of this packet is recorded as T2. |
AD |
Application response time |
AD (unit: ms) = SRTT – TCP_SND |
Application Scenarios of iFlow
The following figure shows the typical networking of iFlow. iFlow is introduced to campus networks to ensure high-quality service experience of various applications in an end-to-end manner. It covers various network segments, from terminals to servers. As different types of services exist on the network, you can use the management, control, and analysis platform to deliver monitoring policies based on service types, so as to monitor service traffic in real time. For UDP services, deploying in-band flow measurement for the campus network and AQM for the WAN can implement end-to-end quality monitoring. For TCP services (in this example, high-quality experience assurance cards are deployed on core switches), iFlow monitoring points are deployed on APs, access switches, and core switches to implement all-domain fault demarcation, covering the wireless access network segment, the network between APs and access switches, the network between access switches and core switches, and the network between core switches and servers. The collected monitoring data is sent to the management-control-analysis platform through telemetry. After being analyzed and processed, the data is visualized, helping administrators accurately and efficiently maintain the service quality of applications and networks.
Typical application scenario of iFlow
