How to use QoS in NSX

Introduction

Quality of Service (QoS) is a critical aspect of network performance management, especially in complex environments where NSX is deployed. NSX provides powerful QoS capabilities at both the gateway and segment levels, enabling fine-grained control over traffic prioritization and bandwidth allocation. However, understanding the differences between these two levels of QoS implementation is essential for optimizing network performance.

In this article, we’ll delve into how QoS functions on the gateway versus the segment in NSX, explore their respective use cases, and provide insights into selecting the right approach for your network needs. Whether you’re managing inter-tenant traffic or fine-tuning internal traffic flows, mastering these distinctions will empower you to make informed decisions and maximize the efficiency of your NSX deployment.

QoS on an NSX Segment

Quality of Service (QoS) on an NSX segment focuses on managing traffic flows within a specific segment, providing comprehensive control over bandwidth and traffic priorities. Unlike gateway-level QoS, which typically manages north-south traffic at the boundary of the network, segment-level QoS applies to all traffic associated with virtual machines (VMs) on the segment, regardless of direction.

To implement QoS at this level, you must first create a Segment Profile, which defines the QoS policies. This includes settings such as ingress and egress traffic shaping, bandwidth guarantees, and DSCP marking. Once configured, this profile is attached to the segment, ensuring that the specified QoS policies are applied consistently to all VMs on that segment.

Explanation of Segment QoS Profile Parameters in NSX

Mode

Defines how DSCP (Differentiated Services Code Point) values are handled for traffic originating from or destined for a logical port.

• Trusted Mode:

  • The DSCP value from the inner packet header (original header) is copied to the outer IP header (tunnel header) for IP/IPv6 traffic.
  • For non-IP/IPv6 traffic, the default DSCP value (0) is used for the outer IP header.
  • Supported only on overlay-based logical ports.

• Untrusted Mode:

  • For overlay-based logical ports, the configured DSCP value is applied to the outer IP header, regardless of the inner packet type.
  • For VLAN-based logical ports, the configured DSCP value is applied to the IP/IPv6 packets’ outer IP header.
  • DSCP values can range from 0 to 63.

Priority

Specifies the DSCP priority value, which determines the level of importance for packets. The DSCP priority values range from 0 to 63, with higher values indicating higher priority traffic.

Class of Service (CoS)

Defines the CoS value, applicable to VLAN-based logical ports.

• CoS groups similar traffic types and assigns a service priority level for each type.
• Lower-priority traffic may experience reduced throughput or be dropped to ensure better performance for higher-priority traffic.
• CoS can also be configured for VLAN ID 0 packets.
• The CoS value ranges from 0 to 7, where 0 indicates best-effort service.

Ingress

Configures traffic shaping for outbound traffic from the VM to the logical network.

• Average Bandwidth: The average rate of outbound traffic to prevent network congestion.
• Peak Bandwidth: The maximum traffic rate allowed to support bursts.
• Burst Size: Defines the maximum data size for a traffic burst, calculated as:

$$ \frac{\text{Peak Bandwidth (in bits per second)} \times \text{Burst Duration (in seconds)}}{8} = \text{Burst Size (in Bytes)} $$

For example, with an average bandwidth of 30 Mbps, a peak of 60 Mbps, and a burst duration of 0.1 seconds, the burst size would be:

$$ \frac{{60000000} \text{(bits per second)} \times {0.1} \text{(seconds)}}{8} = 750000 \text{ bytes} $$

Default value is 0, which disables rate limiting.

Ingress Broadcast

Configures traffic shaping for broadcast traffic sent from the VM to the logical network. Works similarly to the general ingress settings, allowing custom limits for average bandwidth, peak bandwidth, and burst size for broadcast traffic. Default value is 0, which disables rate limiting for ingress broadcast traffic.

Egress

Configures traffic shaping for inbound traffic from the logical network to the VM. Allows setting limits on the average bandwidth, peak bandwidth, and burst size for inbound traffic. Default value is 0, which disables rate limiting on egress traffic. By configuring these parameters effectively, you can ensure traffic prioritization, manage congestion, and optimize bandwidth usage for both overlay-based and VLAN-based logical ports in NSX environments.

Test Scenario: Evaluating QoS at the segment level

To demonstrate the differences between a setup with and without QoS, I have created a test environment consisting of two T1 routers, each connected to its own segment and hosting VMs for testing. Both T1 routers are connected to the same Tier-0 (T0) router, providing a shared Internet connection for testing north-south traffic scenarios.

This test specifically focuses on QoS at the segment level, with the primary goal of limiting the VMs on the segment LS-10.10.20.1 to a maximum bandwidth of 30 Mbps using a QoS profile.

T1 Router 1: T1-BGP No QoS

• Segment: LS-10.10.10.1
• QoS Policy: None applied
• VM: Alpine01 IP Adress 10.10.10.10
  • Running an instance of iPerf to act as a traffic generator and receiver.

This router and segment represent a baseline configuration without any QoS policies, allowing for a comparison of unshaped and unprioritized traffic.

T1 Router 2: T1-BGP QoS

• Segment: LS-10.10.20.1
• QoS Policy: A custom QoS profile is applied to this segment, specifically configured to limit bandwidth to 30 Mbps for all associated VMs.
• VM: Alpine02 IP Adresse 10.10.20.10
  • Equipped with iPerf for traffic generation and reception.
  • Includes a browser for additional testing and validation purposes.

Purpose of the Test

The primary goal of this test is to validate QoS at the segment level, focusing on the following:

• Verifying that VMs connected to LS-10.10.20.1 are effectively limited to a bandwidth of 30 Mbps for egress traffic.
• Demonstrating that the QoS profile, configured as ingress-only, limits traffic originating from Alpine02 to other VMs or the Internet, while traffic from Alpine01 to Alpine02 remains unrestricted.
• Comparing traffic behavior between a segment with and without an applied QoS profile.
• Assessing performance consistency under traffic shaping policies.
• Measuring the impact of the 30 Mbps limit on both east-west and north-south traffic.

These behaviors will be demonstrated using iPerf measurements, highlighting the effectiveness and boundaries of the configured QoS profile. By analyzing the test results, we can confirm the effectiveness of the QoS profile in limiting segment-level bandwidth and understand its implications for overall network performance.

First Test: iPerf Test from Alpine02 to Alpine03

Test Configuration

• Source: Alpine02 (10.10.20.10) connected to the segment LS-10.10.20.1 with the QoS profile applied (ingress limited to 30 Mbps).
• Destination: Alpine03 (10.10.10.10) connected to the segment LS-10.10.10.1 with no QoS policy applied.
• Tool: iPerf3
• Command: iperf3 -c 10.10.10.10

Result Summary

• Average Sender Bitrate: 32.6 Mbps
• Average Receiver Bitrate: 30.2 Mbps
• Key Observation: The sender’s bitrate fluctuates around the 30 Mbps mark, as expected due to the QoS ingress limitation applied to the LS-10.10.20.1 segment. Receiver bitrate is consistent with the QoS configuration, confirming that the profile effectively limits traffic from Alpine02 to Alpine03.

alpine02:~# iperf3 -c 10.10.10.10
Connecting to host 10.10.10.10, port 5201
[  5] local 10.10.20.10 port 40468 connected to 10.10.10.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  6.12 MBytes  51.3 Mbits/sec    0    522 KBytes       
[  5]   1.00-2.00   sec  4.25 MBytes  35.7 Mbits/sec    0    522 KBytes       
[  5]   2.00-3.00   sec  3.25 MBytes  27.3 Mbits/sec    0    522 KBytes       
[  5]   3.00-4.00   sec  3.12 MBytes  26.2 Mbits/sec    0    522 KBytes       
[  5]   4.00-5.00   sec  4.25 MBytes  35.7 Mbits/sec    0    522 KBytes       
[  5]   5.00-6.00   sec  3.12 MBytes  26.2 Mbits/sec    0    522 KBytes       
[  5]   6.00-7.00   sec  4.25 MBytes  35.6 Mbits/sec    0    522 KBytes       
[  5]   7.00-8.00   sec  3.12 MBytes  26.2 Mbits/sec    2    365 KBytes       
[  5]   8.00-9.00   sec  3.25 MBytes  27.3 Mbits/sec    0    365 KBytes       
[  5]   9.00-10.00  sec  4.12 MBytes  34.6 Mbits/sec    0    365 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  38.9 MBytes  32.6 Mbits/sec    2        sender
[  5]   0.00-10.00  sec  36.0 MBytes  30.2 Mbits/sec             receiver

Second Test: iPerf Test from Alpine01 to Alpine02

Test Configuration

• Source: Alpine01 (10.10.10.10) connected to the segment LS-10.10.10.1 with no QoS policy applied.
• Destination: Alpine02 (10.10.20.10) connected to the segment LS-10.10.20.1 with the QoS profile applied (ingress limited to 30 Mbps).
• Tool: iPerf3
• Command: iperf3 -c 10.10.20.10

Result Summary

• Average Sender Bitrate: 2.25 Gbps
• Average Receiver Bitrate: 2.25 Gbps
• Key Observation: The traffic from Alpine01 to Alpine02 is not limited by the QoS profile, as expected. This confirms the QoS profile applies only to ingress traffic on the LS-10.10.20.1 segment.

alpine01:~# iperf3 -c 10.10.20.10
Connecting to host 10.10.20.10, port 5201
[  5] local 10.10.10.10 port 50482 connected to 10.10.20.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   269 MBytes  2.25 Gbits/sec  150   2.08 MBytes       
[  5]   1.00-2.00   sec   268 MBytes  2.25 Gbits/sec    0   2.19 MBytes       
[  5]   2.00-3.00   sec   268 MBytes  2.25 Gbits/sec  172   1.21 MBytes       
[  5]   3.00-4.00   sec   267 MBytes  2.24 Gbits/sec  150    997 KBytes       
[  5]   4.00-5.00   sec   267 MBytes  2.24 Gbits/sec   11    673 KBytes       
[  5]   5.00-6.00   sec   268 MBytes  2.24 Gbits/sec    0    928 KBytes       
[  5]   6.00-7.00   sec   268 MBytes  2.25 Gbits/sec    0   1.10 MBytes       
[  5]   7.00-8.00   sec   268 MBytes  2.25 Gbits/sec    0   1.27 MBytes       
[  5]   8.00-9.00   sec   269 MBytes  2.25 Gbits/sec    0   1.42 MBytes       
[  5]   9.00-10.00  sec   268 MBytes  2.25 Gbits/sec    6   1.11 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.62 GBytes  2.25 Gbits/sec  489             sender
[  5]   0.00-10.01  sec  2.62 GBytes  2.25 Gbits/sec                  receiver

iperf Done.

QoS Profiles Apply to All VMs on the Segment

QoS profiles applied at the segment level are effective for all VMs connected to that segment. In our example, this means:

• Every VM connected to the segment LS-10.10.20.1 is limited to a maximum outgoing traffic rate of 30 Mbps.
• The QoS profile ensures this bandwidth limit is enforced uniformly, regardless of the specific VM or traffic destination.

This behavior highlights the segment-wide scope of QoS policies, making them a powerful tool for managing traffic flow consistently across all connected VMs.

QoS on T1 Gateway Level

To evaluate QoS at the Tier-1 Gateway level, the test conditions remain the same as in the segment-level QoS tests. However, the QoS profile will now be applied directly to the T1 Gateway. Before proceeding, the QoS profile is removed from the segment LS-10.10.20.1.

QoS Profile Configuration on T1 Gateway

For the T1 Gateway, the QoS profile is applied with the following characteristics:

• Type: Ingress
• Committed Bandwidth: 30 Mbps
• Burst Size: Configured based on constraints (explained below).

Unlike segment-level QoS, the T1 Gateway QoS profile allows only the configuration of Committed Bandwidth and Burst Size in bytes. The direction (Ingress or Egress) is explicitly specified when applying the profile to the gateway.

Limitations of Gateway QoS Profiles

• Supported only on Tier-1 Gateways:
  • QoS profiles can only be applied to T1 Gateways, not to Tier-0 Gateways or any other components.
• Applies only to North-South Traffic:
  • QoS policies on Tier-1 Gateways are limited to north-south traffic and do not affect overlay segments or service interfaces connected to the gateway.
• Requires Active-Standby Mode:
  • The T1 Gateway must be in active-standby mode with an NSX Edge cluster for the QoS profile to function.
• Not Supported for Distributed Routing:
  • Gateways configured for distributed routing cannot have QoS profiles applied.

Burst Size Calculation

The calculation of the Burst Size for a T1 Gateway is more complex due to additional constraints. The Burst Size must satisfy the following:

1. Token Refill per Interval:

   \[B \geq \frac{R \times 1000000 \times I}{1000 \times 8} \]

   Where:

• \( B \): Burst Size in Bytes
• \( R \): Committed Bandwidth in Mbps
• \( I \): Refill Interval in milliseconds (e.g., 1 ms)

2. Minimum Refill Interval: \[ B \geq \frac{R \times 1000000 \times 1}{1,000 \times 8} \]

• The minimum interval \( I \) is 1 ms to account for dataplane CPU usage.

3. MTU Constraint: \[ B \geq MTU \] of the Service Router (SR) port.

• The Burst Size must accommodate at least one full MTU-size packet.

The effective Burst Size must satisfy all three constraints. Therefore, the configured Burst Size is determined as:

\[ B = \text{Max} \left( \frac{R \times 1000000 \times I}{1000 \times 8}, \frac{R \times 1000000 \times 1}{1000 \times 8}, MTU \right) \]

Burst Size Calculation Example

Parameters

• \( R \): Committed Bandwidth = 30 Mbps
• \( I \): Refill Interval = 1000 ms (1 second)
• \( MTU \): Maximum Transmission Unit = 1500 bytes

The Burst Size \( B \) must satisfy the following constraints:

1. Token Refill per Interval

\[ B \geq \frac{R \times 1000000 \times I}{1000 \times 8} \]

Substitute the values:

\[ B \geq \frac{30 \times 1000000 \times 1000}{1000 \times 8} \]\[ B \geq \frac{30000000000}{8000} \]\[ B \geq 3750000 \, \text{bytes} \]

2. Minimum Refill Interval

\[ B \geq \frac{R \times 1000000 \times 1000}{1000 \times 8} \]

This calculation remains the same as in the previous case since \( I = 1000 \, \text{ms} \):

\[ B \geq 3750000 \, \text{bytes} \]

3. MTU Constraint

\[ B \geq MTU \]\[ B \geq 1500 \, \text{bytes} \]

Final Burst Size

The Burst Size \( B \) must satisfy all three constraints, so:

\[ B = \text{Max}(3750000, 3750000, 1500) \]\[ B = 3750000 \, \text{bytes} \]

Result

The minimum Burst Size required is 3750000 bytes to satisfy all constraints with the given parameters.

Implementation for This Test

• The T1 Gateway is configured with a 30 Mbps Committed Bandwidth and a Burst Size that satisfies the constraints above.
• The profile is applied in Ingress mode to test incoming north-south traffic through the T1 Gateway.

This setup will help analyze how traffic shaping and rate limiting function at the T1 Gateway level compared to the segment-level QoS.

First Test: iPerf Test from Alpine01 to Alpine02 (T1 Gateway QoS)

Test Configuration

• Source: Alpine01 (10.10.10.10) connected to the segment LS-10.10.10.1 with no QoS profile applied.
• Destination: Alpine02 (10.10.20.10) connected to the segment LS-10.10.20.1.
• QoS Profile: Applied to the T1 Gateway with:
  • Type: Ingress
  • Committed Bandwidth: 30 Mbps
  • Burst Size: Configured according to the calculated constraints.
• Tool: iPerf3
• Command: iperf3 -c 10.10.20.10

alpine01:~# iperf3 -c 10.10.20.10 
Connecting to host 10.10.20.10, port 5201
[  5] local 10.10.10.10 port 33292 connected to 10.10.20.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  7.25 MBytes  60.8 Mbits/sec  283   5.66 KBytes       
[  5]   1.00-2.00   sec  3.25 MBytes  27.3 Mbits/sec  369   5.66 KBytes       
[  5]   2.00-3.00   sec  3.00 MBytes  25.2 Mbits/sec  233   52.3 KBytes       
[  5]   3.00-4.00   sec  3.75 MBytes  31.5 Mbits/sec  392   7.07 KBytes       
[  5]   4.00-5.00   sec  3.12 MBytes  26.2 Mbits/sec  284   41.0 KBytes       
[  5]   5.00-6.00   sec  3.88 MBytes  32.5 Mbits/sec  356   8.48 KBytes       
[  5]   6.00-7.00   sec  3.25 MBytes  27.3 Mbits/sec  270   7.07 KBytes       
[  5]   7.00-8.00   sec  3.62 MBytes  30.4 Mbits/sec  315    110 KBytes       
[  5]   8.00-9.00   sec  3.50 MBytes  29.4 Mbits/sec  407   7.07 KBytes       
[  5]   9.00-10.00  sec  3.00 MBytes  25.2 Mbits/sec  245   12.7 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  37.6 MBytes  31.6 Mbits/sec  3154             sender
[  5]   0.00-10.00  sec  37.1 MBytes  31.1 Mbits/sec                  receiver

iperf Done.

Result Summary

• Average Sender Bitrate: 31.6 Mbps
• Average Receiver Bitrate: 31.1 Mbps
• Total Retransmissions: 3154

Second Test: iPerf Test from Alpine02 to Alpine03 (T1 Gateway QoS)

Test Configuration

• Source: Alpine02 (10.10.20.10) connected to the segment LS-10.10.20.1 with no QoS profile applied.
• Destination: Alpine03 (10.10.10.10) connected to the segment LS-10.10.10.1 with no QoS profile applied.
• QoS Profile: Applied to the T1 Gateway in Ingress mode, limiting traffic to 30 Mbps for ingress traffic from T0 to the T1 gateway.
• Tool: iPerf3
• Command: iperf3 -c 10.10.10.10

alpine02:~# iperf3 -c 10.10.10.10
Connecting to host 10.10.10.10, port 5201
[  5] local 10.10.20.10 port 50200 connected to 10.10.10.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   249 MBytes  2.09 Gbits/sec    5    615 KBytes       
[  5]   1.00-2.00   sec   267 MBytes  2.24 Gbits/sec    0    885 KBytes       
[  5]   2.00-3.00   sec   159 MBytes  1.34 Gbits/sec   73    290 KBytes       
[  5]   3.00-4.00   sec   248 MBytes  2.08 Gbits/sec    0    677 KBytes       
[  5]   4.00-5.00   sec   261 MBytes  2.19 Gbits/sec    0    928 KBytes       
[  5]   5.00-6.00   sec   264 MBytes  2.22 Gbits/sec    1    792 KBytes       
[  5]   6.00-7.00   sec   260 MBytes  2.18 Gbits/sec   26    441 KBytes       
[  5]   7.00-8.00   sec   257 MBytes  2.16 Gbits/sec    0    766 KBytes       
[  5]   8.00-9.00   sec   262 MBytes  2.20 Gbits/sec    7    585 KBytes       
[  5]   9.00-10.00  sec   262 MBytes  2.19 Gbits/sec    0    858 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.43 GBytes  2.09 Gbits/sec  112             sender
[  5]   0.00-10.00  sec  2.43 GBytes  2.09 Gbits/sec                  receiver

Result Summary

• Average Sender Bitrate: 2.09 Gbps
• Average Receiver Bitrate: 2.09 Gbps
• Total Retransmissions: 112

Third Test: iPerf Test from Alpine01 to Alpine02 (Concurrent Traffic)

Test Configuration

• Source: Alpine01 (10.10.10.10) connected to the segment LS-10.10.10.1 with no QoS profile applied.
• Destination: Alpine02 (10.10.20.10) connected to the segment LS-10.10.20.1.
• Additional Traffic: A second VM, connected to the same T1 Gateway as Alpine02, is concurrently receiving data to simulate shared bandwidth conditions.
• QoS Profile: Applied to the T1 Gateway in Ingress mode, limiting traffic to 30 Mbps for ingress traffic to the gateway.
• Tool: iPerf3
• Command: iperf3 -c 10.10.20.10

alpine01:~# iperf3 -c 10.10.20.10 
Connecting to host 10.10.20.10, port 5201
[  5] local 10.10.10.10 port 40898 connected to 10.10.20.10 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  2.88 MBytes  24.1 Mbits/sec  475   8.48 KBytes       
[  5]   1.00-2.00   sec  2.50 MBytes  21.0 Mbits/sec  212   53.7 KBytes       
[  5]   2.00-3.00   sec  2.12 MBytes  17.8 Mbits/sec  233   9.90 KBytes       
[  5]   3.00-4.00   sec  2.12 MBytes  17.8 Mbits/sec  145   1.41 KBytes       
[  5]   4.00-5.00   sec  2.50 MBytes  21.0 Mbits/sec  237   14.1 KBytes       
[  5]   5.00-6.00   sec  1.62 MBytes  13.6 Mbits/sec  145   22.6 KBytes       
[  5]   6.00-7.00   sec  3.12 MBytes  26.2 Mbits/sec  331   5.66 KBytes       
[  5]   7.00-8.00   sec  1.00 MBytes  8.39 Mbits/sec  155   7.07 KBytes       
[  5]   8.00-9.00   sec  2.62 MBytes  22.0 Mbits/sec  142   86.3 KBytes       
[  5]   9.00-10.00  sec  3.12 MBytes  26.2 Mbits/sec  349   22.6 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  23.6 MBytes  19.8 Mbits/sec  2424             sender
[  5]   0.00-10.00  sec  22.4 MBytes  18.8 Mbits/sec                  receiver

Result Summary

• Average Sender Bitrate: 19.8 Mbps
• Average Receiver Bitrate: 18.8 Mbps
• Total Retransmissions: 2424
• The QoS profile at the T1 Gateway effectively limits total ingress bandwidth to 30 Mbps. However, the concurrent traffic from the second VM reduces the available bandwidth for Alpine01.

Summary

When working with QoS profiles in NSX, it is important to understand the key differences and use cases for Gateway QoS Profiles and Segment QoS Profiles:

Gateway QoS Profiles

• Shared Bandwidth: The configured bandwidth applies to the total traffic for all VMs connected to the same T1 Gateway. This includes all segments attached to that gateway.
• Practical Use Case: Gateway QoS profiles are ideal for scenarios like test environments, where you want to limit the total available bandwidth across all VMs and segments.
• Traffic Direction: The QoS direction is critical:
  • Ingress QoS: Limits traffic entering the T1 Gateway (from T0 to T1), affecting ingress traffic from the VM’s perspective.
  • Egress QoS: Limits traffic leaving the T1 Gateway (from T1 to T0), affecting egress traffic from the VM’s perspective.

Segment QoS Profiles

• Individual Bandwidth Allocation: Each VM connected to the segment receives the bandwidth specified in the profile. VMs do not share the bandwidth; they each receive the assigned limit (assuming the total environment can provide the required bandwidth).
• Flexibility: Segment QoS profiles offer more granular control and can be used for more than just rate limiting. For example, they can prioritize or shape specific types of traffic.
• Traffic Direction: The direction in the profile (Ingress or Egress) must be carefully considered based on what you want to achieve.

Key Considerations

• Shared vs. Dedicated Bandwidth: Use Gateway QoS Profiles when you want to manage total bandwidth collectively for all VMs. Use Segment QoS Profiles when you need to allocate specific bandwidth to individual VMs.
• Performance Impact: Avoid using Gateway QoS Profiles in scenarios requiring high performance and scalability. The active/standby limitation can create bottlenecks, making distributed T1 Gateways the better choice for performance-critical environments.

By understanding these differences, you can effectively apply QoS profiles to achieve desired traffic shaping and bandwidth management goals in your NSX environment.