SNR – Engineering Mission Solutions

Home > Resources > Topic of Interest

Topic of Interest

Latency vs Efficiency for IP Circuit Emulation

When implementing real-time services over IP, an acceptable latency for the application to function properly must be determined in advance and met by the network infrastructure.

Last month, we introduced the three significant components of delay in a real-time service implemented over an IP network: packetization delay, transfer delay and reassembly delay. We saw that packet jitter increases the reassembly delay and concluded that some method of jitter control (IP CoS/QoS, MPLS, etc.) is beneficial in reducing application latency.

For this month’s topic, we will look more closely at the first component of the overall application latency, namely, packetization delay. We will see that increasing the IP payload size improves efficiency but increases the application latency because it increases the packetization delay (click here for last month's topic).

To simplify this discussion, we will again assume a real-time service that requires transport of a constant bit rate data stream – this time a 1.544 Mbps circuit emulated over an IP network. We will once again ignore the insignificant processing delays on each end (for example on the receive side, that would be passing the packet up the protocol stack and notifying the application that the packet is available).

Throughout the discussion we will use the analogy of transporting water from one office to another. Imagine a water cooler that creates a constant stream of water when you pull the tap. We will recreate that stream of water in another office by filling cups of water (packets of bits), carrying the cups to the second office and then pouring them into a bucket with a spigot that creates the same constant stream of water.

Definitions:

Packetization Delay – The time required for the application to fill an IP packet to a specified level. This is analogous to filling the cup in the first office. The packetization delay is calculated by dividing the packet payload size by the rate at which it is filled (the rate of the emulated circuit). In our water analogy, it is the amount of water divided by the fill rate (e.g. 8 ounces / 2 ounces per second = 4 seconds).

Figure 1 - Packetization Delay

Transfer Delay – Also, known as packet latency, this is the time elapsed from when the packet enters the IP cloud at the transmit end and when it exits the IP cloud on the receive end. In our analogy, this is the time required to deliver the cup from the first office to the second office.

Figure 2 – Transfer Delay

Reassembly Delay – The amount of time the transported data waits in a buffer at the receive side before being read out by the application. In our analogy, this is the time required to fill the bucket to a level which ensures that your output stream is constant. When can you open the spigot and be sure that you have a constant stream of water coming out of the bucket? That depends on the arrival of the cups of water that you are pouring in. If you know you will always have a cup of water ready, you don’t have to wait at all. If you are uncertain about the time the cup will be ready to pour, you should wait to open the spigot until you have enough water stored in the bucket to compensate for the delay in the arrival of the cup. The amount of time you wait to turn on the spigot is the reassembly delay.

Figure 3 – Reassembly Delay

Application Latency – The elapsed time between when an application presents data to the transmit side and when the application reads out data on the receive side. In our case, we will ignore the insignificant processing delays on each end so the application latency becomes the sum of the packetization delay, the transfer delay and the reassembly delay. In our analogy, this is the delay between when water leaves the tap of the water cooler and when it leaves the spigot in the second office.

Packet Jitter – The variation in the transfer delay of IP packets. In our analogy, it is the variation in the time it takes to carry the cup from the first office to the second. It might take, on average, one minute to walk between offices, but different trips might take less time (if someone opens doors for you) or more time (if you have to wait for an elevator).

Circuit Bandwidth Efficiency (CBE) – The efficiency of circuit transport in terms of required bandwidth, it is calculated by dividing the application bandwidth by the total bandwidth required for transport. In our analogy, you might think of this as the extra weight of the cup that is used for transporting the water. If each cup weighs one pound, and transports four pounds of water, the “weight efficiency” of our transport method is 80% (4 pounds of water divided by five pounds total transport).

Example 1:

In this example, we will examine the circuit bandwidth efficiency of an IP emulated T-1 circuit. Most IP circuit emulation implementations require some control traffic, either a byte (or several bytes) inserted into a packet or a separate control packet stream to maintain timing and synchronization of the circuit. Unless the circuit itself is very low in bandwidth, the bandwidth required for the control traffic is insignificant compared to the application traffic, so we will ignore it in this analysis.

Ignoring the control traffic, the efficiency can be calculated by dividing the IP packet payload size by the total IP packet size (including header). This is the CBE in terms of total IP bandwidth, which may not be the total transport bandwidth if, for example Packet over SONET (POS) is used for transport (more on that later). We will assume no options are used in the IPv4 header so the header size is constant at 20 bytes. We will assume no option headers are used in IPv6 so the header size is also constant but at 40 bytes. Since the header sizes are constant, the CBE becomes a function of the payload size:

CBE_(IP) = Payload Size / (Payload Size + Header Size)

The chart below shows the CBE_(IP) as a function of payload size for both IPv4 and IPv6 emulated circuits.

Figure 4 - IP Circuit Emulation CBE

Example 2:

In this example we will compare the circuit bandwidth efficiency (CBE) of a T-1 circuit carried in a time division multiplexed OC-3, to an IP emulated T-1. We’ll start with the TDM transport.

A TDM multiplexed OC-3 carries 3 STS-1s, which is the transport mechanism for a DS-3. Each DS-3 can carry 28 DS-1s so there are 28 x 3 = 84 DS-1s available for transport in the OC-3. If the entire OC-3 is full, the CBE of each T-1 circuit is:

CBE = 1.544 Mbps / (155.520 Mbps / 84) = 83.4%

While it may be strictly incorrect to say that each T-1 requires 155.52 / 84 = 1.851 Mbps, we believe it is a worthwhile comparison. In reality, each T-1 only requires 1.544 Mbps of bandwidth, then the framing and bit-stuffing for timing takes up the rest. The benefit you get from the overhead is in timing, protection and the SONET DCC.

We need to slightly modify our earlier example of IP circuit bandwidth efficiency. Let’s assume that the emulated circuit will be transported in an OC-3c packet over SONET (POS) interface. In that case, the available IP bandwidth on the link is 149.760 Mbps which is the size of the synchronous payload envelop or SPE (for simplicity, we will ignore the overhead of PPP encapsulation which should be insignificant except for very small packet sizes). The SONET overhead is used for framing, protection and the DCC. Since IP is only using 149.7/155.52 = 96.26% of the transport bandwidth, we need to take that into account to get the overall CBE of the emulated circuit.

So the CBE of an IP emulated T-1 on an OC-3 POS link can be calculated as:

CBE = 149.7/155.52 * CBE_(IP) = 0.962 * Payload Size / (Payload Size + Header Size)

The figure below shows the new total CBE of IP emulated circuits. The CBE of a T-1 carried in a fully occupied time division multiplexed OC-3 is also plotted.

Figure 5 - CBE of IP emulated circuits.

Example 3:

Now let’s look at it from a different angle. How many T-1s can you support over an OC-3 link? The transport options are TDM, IPv4 circuit emulation and IPv6 circuit emulation. With TDM, the number is constant (84), but with circuit emulation, it varies by IP payload size.

Figure 6 – Number of T-1’s supported over an OC-3 link

Example 4:

The previous example shows that it is possible to transport more T-1 circuits over an OC-3 link using IP circuit emulation than you can with SONET. The improved efficiency comes at the expense of added delay. If you recall from last month’s discussion, the delay can be approximated by adding three distinct components:

1. Packetization delay (PD) – the time it takes to fill the packet with bits, or fill the cup with water

2. Transfer delay (TD) – the time it takes to deliver the packet or cup of water.

3. Reassembly Delay (RD) – the time spent in a buffer to compensate for packet jitter (delay variation).

Since we are focused on the trade-off between efficiency and delay, we will assume that TD and RD are constant and look at the effect of packet size on the packetization delay. Packetization delay is calculated as the IP payload size divided by the rate at which the packet is filled. Assuming that the fill rate is constant (1.544 Mbps in our example), PD becomes a function of IP payload size:

PD = (IP payload size) / 1.544 Mbps

Figure 7 – Efficiency (blue) versus Delay (red)

Example 5:

So far we have looked at utilization of T-1 circuits only. The packetization delay increases as the circuit rate decreases (weaker stream of water to fill the cup), so it’s useful to look at efficiency of lower speed circuits as well.

In this example, we will choose our packet size to meet a required efficiency. Let’s set the required efficiency to equal that of our T-1 transported in a TDM OC-3 (83.4%, calculated in example 2). We will again assume that the circuits will be carried in IP over an OC-3 POS link. So after doing a little algebra, our required payload size is:

Payload_(IPv4) = 0.834 * 20 / (149.7/155.52 – 0.834) = 130 bytes (rounded up)

Payload_(IPv6) = 0.834 * 40 / (149.7/155.52 – 0.834) = 260 bytes (rounded up)

A quick check of Figure 5 confirms these numbers. Now we’ll plot the packetization delay for different circuit speeds using these payload sizes. Remember PD = (Payload Size) / (Circuit Rate).

Figure 8 – Packetization Delay for different Circuit Rates

Results:

In the examples above, we have seen that it is possible to achieve great efficiency using IP circuit emulation for circuit transport. Unlike with TDM technologies, you can determine the amount of overhead by varying the packet size. However, this improvement comes at the expense of additional delay. To achieve better than SONET efficiency for T-1 transport, this delay is less than 1 ms for IPv4 and a bit over for IPv6. Given that transfer delay and reassembly delay are likely to be much higher than this, the added delay is a small price to pay for the added efficiency.

When implementing real-time services, it is important to take an end-to-end approach in the design phase. The requirements of the application (e.g. latency) and the capabilities of the network infrastructure (e.g. IP QoS) will determine the optimal choice for variables such as packet size.

We hope this information was useful to you. If you would like to discuss an engineering project or have feedback on this page, please click here. For a pdf version of this discussion, please click here.




Industry Publications Government Web Sites Topic of Interest Archive	Home > Resources > Topic of Interest Topic of Interest Latency vs Efficiency for IP Circuit Emulation When implementing real-time services over IP, an acceptable latency for the application to function properly must be determined in advance and met by the network infrastructure. Last month, we introduced the three significant components of delay in a real-time service implemented over an IP network: packetization delay, transfer delay and reassembly delay. We saw that packet jitter increases the reassembly delay and concluded that some method of jitter control (IP CoS/QoS, MPLS, etc.) is beneficial in reducing application latency. For this month’s topic, we will look more closely at the first component of the overall application latency, namely, packetization delay. We will see that increasing the IP payload size improves efficiency but increases the application latency because it increases the packetization delay (click here for last month's topic). To simplify this discussion, we will again assume a real-time service that requires transport of a constant bit rate data stream – this time a 1.544 Mbps circuit emulated over an IP network. We will once again ignore the insignificant processing delays on each end (for example on the receive side, that would be passing the packet up the protocol stack and notifying the application that the packet is available). Throughout the discussion we will use the analogy of transporting water from one office to another. Imagine a water cooler that creates a constant stream of water when you pull the tap. We will recreate that stream of water in another office by filling cups of water (packets of bits), carrying the cups to the second office and then pouring them into a bucket with a spigot that creates the same constant stream of water. Definitions: Packetization Delay – The time required for the application to fill an IP packet to a specified level. This is analogous to filling the cup in the first office. The packetization delay is calculated by dividing the packet payload size by the rate at which it is filled (the rate of the emulated circuit). In our water analogy, it is the amount of water divided by the fill rate (e.g. 8 ounces / 2 ounces per second = 4 seconds). Figure 1 - Packetization Delay Transfer Delay – Also, known as packet latency, this is the time elapsed from when the packet enters the IP cloud at the transmit end and when it exits the IP cloud on the receive end. In our analogy, this is the time required to deliver the cup from the first office to the second office. Figure 2 – Transfer Delay Reassembly Delay – The amount of time the transported data waits in a buffer at the receive side before being read out by the application. In our analogy, this is the time required to fill the bucket to a level which ensures that your output stream is constant. When can you open the spigot and be sure that you have a constant stream of water coming out of the bucket? That depends on the arrival of the cups of water that you are pouring in. If you know you will always have a cup of water ready, you don’t have to wait at all. If you are uncertain about the time the cup will be ready to pour, you should wait to open the spigot until you have enough water stored in the bucket to compensate for the delay in the arrival of the cup. The amount of time you wait to turn on the spigot is the reassembly delay. Figure 3 – Reassembly Delay Application Latency – The elapsed time between when an application presents data to the transmit side and when the application reads out data on the receive side. In our case, we will ignore the insignificant processing delays on each end so the application latency becomes the sum of the packetization delay, the transfer delay and the reassembly delay. In our analogy, this is the delay between when water leaves the tap of the water cooler and when it leaves the spigot in the second office. Packet Jitter – The variation in the transfer delay of IP packets. In our analogy, it is the variation in the time it takes to carry the cup from the first office to the second. It might take, on average, one minute to walk between offices, but different trips might take less time (if someone opens doors for you) or more time (if you have to wait for an elevator). Circuit Bandwidth Efficiency (CBE) – The efficiency of circuit transport in terms of required bandwidth, it is calculated by dividing the application bandwidth by the total bandwidth required for transport. In our analogy, you might think of this as the extra weight of the cup that is used for transporting the water. If each cup weighs one pound, and transports four pounds of water, the “weight efficiency” of our transport method is 80% (4 pounds of water divided by five pounds total transport). Example 1: In this example, we will examine the circuit bandwidth efficiency of an IP emulated T-1 circuit. Most IP circuit emulation implementations require some control traffic, either a byte (or several bytes) inserted into a packet or a separate control packet stream to maintain timing and synchronization of the circuit. Unless the circuit itself is very low in bandwidth, the bandwidth required for the control traffic is insignificant compared to the application traffic, so we will ignore it in this analysis. Ignoring the control traffic, the efficiency can be calculated by dividing the IP packet payload size by the total IP packet size (including header). This is the CBE in terms of total IP bandwidth, which may not be the total transport bandwidth if, for example Packet over SONET (POS) is used for transport (more on that later). We will assume no options are used in the IPv4 header so the header size is constant at 20 bytes. We will assume no option headers are used in IPv6 so the header size is also constant but at 40 bytes. Since the header sizes are constant, the CBE becomes a function of the payload size: CBE_(IP) = Payload Size / (Payload Size + Header Size) The chart below shows the CBE_(IP) as a function of payload size for both IPv4 and IPv6 emulated circuits. Figure 4 - IP Circuit Emulation CBE Example 2: In this example we will compare the circuit bandwidth efficiency (CBE) of a T-1 circuit carried in a time division multiplexed OC-3, to an IP emulated T-1. We’ll start with the TDM transport. A TDM multiplexed OC-3 carries 3 STS-1s, which is the transport mechanism for a DS-3. Each DS-3 can carry 28 DS-1s so there are 28 x 3 = 84 DS-1s available for transport in the OC-3. If the entire OC-3 is full, the CBE of each T-1 circuit is: CBE = 1.544 Mbps / (155.520 Mbps / 84) = 83.4% While it may be strictly incorrect to say that each T-1 requires 155.52 / 84 = 1.851 Mbps, we believe it is a worthwhile comparison. In reality, each T-1 only requires 1.544 Mbps of bandwidth, then the framing and bit-stuffing for timing takes up the rest. The benefit you get from the overhead is in timing, protection and the SONET DCC. We need to slightly modify our earlier example of IP circuit bandwidth efficiency. Let’s assume that the emulated circuit will be transported in an OC-3c packet over SONET (POS) interface. In that case, the available IP bandwidth on the link is 149.760 Mbps which is the size of the synchronous payload envelop or SPE (for simplicity, we will ignore the overhead of PPP encapsulation which should be insignificant except for very small packet sizes). The SONET overhead is used for framing, protection and the DCC. Since IP is only using 149.7/155.52 = 96.26% of the transport bandwidth, we need to take that into account to get the overall CBE of the emulated circuit. So the CBE of an IP emulated T-1 on an OC-3 POS link can be calculated as: CBE = 149.7/155.52 * CBE_(IP) = 0.962 * Payload Size / (Payload Size + Header Size) The figure below shows the new total CBE of IP emulated circuits. The CBE of a T-1 carried in a fully occupied time division multiplexed OC-3 is also plotted. Figure 5 - CBE of IP emulated circuits. Example 3: Now let’s look at it from a different angle. How many T-1s can you support over an OC-3 link? The transport options are TDM, IPv4 circuit emulation and IPv6 circuit emulation. With TDM, the number is constant (84), but with circuit emulation, it varies by IP payload size. Figure 6 – Number of T-1’s supported over an OC-3 link Example 4: The previous example shows that it is possible to transport more T-1 circuits over an OC-3 link using IP circuit emulation than you can with SONET. The improved efficiency comes at the expense of added delay. If you recall from last month’s discussion, the delay can be approximated by adding three distinct components: 1. Packetization delay (PD) – the time it takes to fill the packet with bits, or fill the cup with water 2. Transfer delay (TD) – the time it takes to deliver the packet or cup of water. 3. Reassembly Delay (RD) – the time spent in a buffer to compensate for packet jitter (delay variation). Since we are focused on the trade-off between efficiency and delay, we will assume that TD and RD are constant and look at the effect of packet size on the packetization delay. Packetization delay is calculated as the IP payload size divided by the rate at which the packet is filled. Assuming that the fill rate is constant (1.544 Mbps in our example), PD becomes a function of IP payload size: PD = (IP payload size) / 1.544 Mbps Figure 7 – Efficiency (blue) versus Delay (red) Example 5: So far we have looked at utilization of T-1 circuits only. The packetization delay increases as the circuit rate decreases (weaker stream of water to fill the cup), so it’s useful to look at efficiency of lower speed circuits as well. In this example, we will choose our packet size to meet a required efficiency. Let’s set the required efficiency to equal that of our T-1 transported in a TDM OC-3 (83.4%, calculated in example 2). We will again assume that the circuits will be carried in IP over an OC-3 POS link. So after doing a little algebra, our required payload size is: Payload_(IPv4) = 0.834 * 20 / (149.7/155.52 – 0.834) = 130 bytes (rounded up) Payload_(IPv6) = 0.834 * 40 / (149.7/155.52 – 0.834) = 260 bytes (rounded up) A quick check of Figure 5 confirms these numbers. Now we’ll plot the packetization delay for different circuit speeds using these payload sizes. Remember PD = (Payload Size) / (Circuit Rate). Figure 8 – Packetization Delay for different Circuit Rates Results: In the examples above, we have seen that it is possible to achieve great efficiency using IP circuit emulation for circuit transport. Unlike with TDM technologies, you can determine the amount of overhead by varying the packet size. However, this improvement comes at the expense of additional delay. To achieve better than SONET efficiency for T-1 transport, this delay is less than 1 ms for IPv4 and a bit over for IPv6. Given that transfer delay and reassembly delay are likely to be much higher than this, the added delay is a small price to pay for the added efficiency. When implementing real-time services, it is important to take an end-to-end approach in the design phase. The requirements of the application (e.g. latency) and the capabilities of the network infrastructure (e.g. IP QoS) will determine the optimal choice for variables such as packet size. We hope this information was useful to you. If you would like to discuss an engineering project or have feedback on this page, please click here. For a pdf version of this discussion, please click here.