...
Chapter 1. About Saisei Traffic Manager
This chapter contains an overview of Saisei Traffic Manager and how it works.
What is Saisei Traffic Manager?
The Saisei Traffic Manager (STM) is a real-time traffic monitor and controller for Internet traffic. It collects real-time, fine-grained statistics about all traffic flowing on a link. At the same time it controls traffic using powerful, flexible, user-defined policies.
...
In monitor mode, STM provides realtime visibility into the network, but does not apply any policies
In control mode, STM will monitor the network, but it will also manage flows by applying policies
How Saisei Traffic Manager works
STM reads data packet headers of incoming network traffic and assigns the packet to a flow. The flow is then managed according to flow control rules that are defined during STM configuration.
...
Configuration settings define how Saisei Traffic Manager operates
...
Chapter 2. Flow Concepts
The concept of network traffic 'flow' is central to understanding the operation of STM.
Flows
The first thing that the Saisei Traffic Manager does when it receives a packet is to associate it with a flow. A flow is a stream of packets corresponding to the same TCP or UDP session, identified by their IP addresses and port numbers.
...
Source IP address
Destination IP address
Layer 4 protocol
Flow Classification
When STM receives the first packet for a new flow, it classifies the flow to determine the way the flow will be handled. This classification is repeated frequently during the life of a flow.
...
The application it is serving (for example, a specific website or a protocol such as VoIP, Skype, or BitTorrent)
The external geographic location it is serving
The internal and external hosts it is connecting
The internal user it is serving (if an address-to-user database such as Microsoft Active Directory or OpenLDAP is available)
Groups (for example, a group could consist of all countries where a company has business partners, or all applications whose network usage is to be tightly controlled)
Behavioral characteristics, such as number of packets and duration
Flow Management
STM manages every flow in real-time, constantly monitoring each flow to make sure that it stays within its allocated bandwidth. This eliminates the problems that occur with traditional IP routers, where the algorithms might randomly drop packets to manage congestion, causing flows to timeout, reset, or stall.
...
Flow classification allows STM to manage flows based on higher-level characteristics, such as behavior (for example, flow duration) or type of application (for example, Skype or BitTorrent). STM can detect whether a flow represents voice traffic, video traffic, or bulk data transfers. This allows STM to enable different levels of service for different applications and users.
Management of TCP Flows
When the allotted bandwidth for a flow is approached, STM manages each flow according to the policy that applies to it. If possible, it delays packets as an indication to the hosts that transmission should slow down. If packet delay is not configured or proves ineffective, packets are selectively dropped. The TCP standard ensures that hosts react correctly to this, and also that dropped packets are retransmitted, ensuring the integrity of the data.
Management of Non-TCP Flows
Many application protocols that use UDP rather than TCP have their own congestion management mechanisms that work in ways similar to TCP. Some kinds of real-time traffic (such as VoIP and video) react badly to packet loss in a very noticeable way, such as voice or image breakup. STM can be configured to protect such traffic from packet loss.
...
Chapter 3. Saisei Traffic Manager Components
STM’s policies and attributes must be configured before STM can perform monitoring or control functions.
...
Interfaces
Access control list (ACL) and ACL entries (ACE)
Ingress flow class (IFC)
Ingress policy map (IPM) and ingress policies
Egress flow class (EFC)
Egress policy map (EPM) and egress policies
Overview of Saisei Traffic Manager Components
The configuration components of STM select other components to establish the relationships that will be used to create the rule set used for flow control.
...
In the diagram, there are two interfaces, Eth1 and Eth2. Each interface selects two policy maps; an egress policy map (EPM) and an ingress policy map (IPM)
Each policy map contains policies. Egress policies select an egress flow class (EFC) and ingress policies select an ingress flow class (IFC)
The IFC selects an EFC and an access control list (ACL)
As the same EFC is selected by the egress policy and by the IFC, a link is created between the ingress policy and the egress policy. These two linked policies are then used by STM to create the rule set for implementing flow control
...
Interfaces
Interfaces are STM's connection to the rest of the network.
...
An interface specifies a rate, which is the maximum total bandwidth that will be used for all flows that use the interface as an egress interface. For a physical interface this rate will normally be the physical bandwidth (either 10G or 1G), though a lower value can be configured.
Access Control Lists
An ACL is used to match the five-tuple addressing information in a flow. An ACL contains one or more access control list entries (ACE). Each ACE matches a specific set of addressing information, taken from the five-tuple in the packet header.
The configuration attributes of an ACL and its ACEs are the same in the CLI, GUI, and REST API. All screenshots are from the GUI.
...
ACL in STM GUI
Multiple ingress flow classes (IFC)s can select the same ACL. The rules in the ACL (as defined in the ACEs) and the classification information in the IFC are used to match the packet with a flow class.
...
The following screen capture of the STM GUI shows an ACE rule called 10.1.2.10-24.
...
ACE in STM GUI
An ACE has the attributes listed below:
...
Symmetric:
If this attribute is selected, the ACE will also match a flow in which the source and destination are reversed, that is, if the entry says the source subnet and port are 1.2.3.0/24 port 80, it will match a flow in which these are the destination subnet and port.
Ingress Flow Classes
IFCs are the heart of the classification method of STM. An IFC specifies all the characteristics that a flow must have in order to be selected as belonging to a class. These characteristics are defined in the ACL selected in the IFC and in the IFC itself.
...
The configuration attributes of an IFC are the same in the CLI, GUI, and REST API. All screenshots are from the GUI.
...
Ingress Flow Class in STM GUI
When creating an IFC, you must include an ACL. If the packet header information does not match the ACL, the IFC will not be selected.
...
Minimum or maximum duration of a flow
Minimum or maximum number of bytes for a flow
Minimum or maximum number of packets for a flow
Minimum or maximum rate over flow lifetime
Ingress Policy Maps and Ingress Policies
Each interface specifies an ingress policy map (IPM) that contains the policies to be applied to a flow based on the matching IFC. The same IPM can be attached to multiple interfaces, or if different policies are required (for example, for different VLANs), separate IPMs can be used.
...
The configuration attributes of an IPM are the same in the CLI, GUI, and REST API. All screenshots are from the GUI.
...
IPM in STM GUI
An IPM contains one or more policies, each of which is associated with a single IFC. An IPM also specifies a sequence number. If a flow matches more than one IFC (which will often be the case), the ingress policy with the lowest sequence number is selected. In effect, STM scans the policies beginning with the lowest sequence number and works toward the highest sequence number.
...
The figure below shows the ingress policy ‘base’. The name of an ingress policy also indicates the name of the IFC that contains it.
...
Ingress Policy in STM GUI
The following attributes are defined in the ingress policy associated with the IFC:
...
There are further attributes of specialized use, which are listed in the CLI documentation.
Egress Flow Classes
An egress flow class creates a link between one or more ingress flow classes, and the egress policy associated with it for a particular interface. An egress flow class must be created before it can be associated with an ingress flow class or have an egress policy configured for it.
The configuration attributes of an EFC are the same in the CLI, GUI, and REST API. All screenshots are from the GUI.
...
EFC in STM GUI
For ease of management, the EFC and the egress policy should have the same name, for example, ‘mobile’. The 'EFC-egress policy' pair can be selected by multiple IFCs. An EFC must be applied to an interface in order to allocate bandwidth for an egress flow on that interface. If no EFCs are selected by an IFC, the IFC performs an automatic drop of ALL packets in any flows associated with the IFC.
Egress Policy Maps and Egress Policies
Each interface specifies an EPM that contains the policies to be applied to a flow based on the matching EFC, as specified in the selected IFC. The same EPM can be attached to more than one interface, or if different policies are required (for example, for different VLANs), separate EPMs can be used.
The configuration attributes of an egress policy map and and an egress policy are the same in the CLI, GUI, and REST API. All screenshots are from the GUI.
...
EPM in STM GUI
An EPM contains one or more egress policies, each of which is associated with a single EFC.
...
Egress policy in STM GUI
An egress policy specifies how a flow is to be handled during its lifetime. Egress policies specify aspects of flow handling that relate to collections of flows of the same kind, rather than individual flows. In particular, they allow the bandwidth allocated to a collection of flows to be managed for the combination of all the flows.
...
Other attributes are used to manage hierarchies of EFCs. For more information, see the CLI documentation.
...
Chapter 4. Additional Concepts
This section provides more information about applications, geolocations, groups, configuration, and dynamic bandwidth management.
...
An application object keeps statistics that track its usage, for example the current traffic rates and the total traffic for the application.
Configuration and Partitions
Although only one configuration can be running at a time, several configurations can be stored and activated as required. All manageable elements of the software are contained within a configuration.
...
When the system restarts, the former alternate partition becomes current and the former current partition becomes alternate. If the upgrade has been successful, the now alternate partition can also be upgraded. But if there is a problem, it's possible to revert to the former partition.
Dynamic Bandwidth Management
The bandwidth allotment for each flow is not static. The amount of bandwidth available will vary as network flows are started and stopped.
...
STM maintains the bandwidth used at an egress interface at the specified rate, by controlling the individual flows assigned to the EFC.
Delay is minimized so that the time delay from ingress to egress for flows that are allowed to proceed without dropped packets is less than 10 micro seconds.
Uncontrolled packet loss is eliminated.
Voice, video and other critical applications can be allocated a guaranteed bandwidth.
Geolocations
A geolocation is a geographic location that is associated with one or more IP address ranges.
...
A geolocation keeps information about current and historical traffic rates and flows.
Groups
Groups allow a policy to be applied to a number of entities (applications, users, or geolocations) without configuring each one explicitly.
...
Groups can also be nested, to a depth of one. For example, a group could be defined for each department in an organization, with users assigned to those groups. Then a group could be defined for each executive-level function, with the departments assigned a function. This would allow policies to be assigned at either the department or function level, and will collect usage information at both levels.
...
Host Management
STM manages bandwidth separately for flows and for hosts. It can also manage bandwidth for flows associated wth each host, using host equalization (HE) and host policy maps (HPM).
Host Equalization
The simplest form of host management is host equalization (HE). When host equalization is enabled for an egress flow class (EFC), its bandwidth is divided equally among all hosts. Then, for each host, the bandwidth is divided equally among the flows.
...
This is a powerful way to control “greedy” hosts, which try to get the maximum bandwidth by using a very large number of flows. Suppose there are two hosts, one with just a single flow (for example, a Netflix download) and another with 100 flows (for example, a BitTorrent download). Without HE each flow will get equal bandwidth, so the host with 100 flows gets virtually all the available bandwidth. But with HE, the bandwidth is divided equally among the two hosts. Each of the 100 BitTorrent flows get just one hundredth of the bandwidth given to the Netflix download.
Using the Rate Multiplier
In some cases, STM may be required to share bandwidth among hosts unequally, while still taking advantage of the benefits of host equalization. This can be done using the rate_multiplier attribute of the host. For example, if there are three hosts, A, B and C, with rate multipliers of 2, 1, and 0.5 respectively, then A will get double the bandwidth of B, who will get double the bandwidth of C, regardless of the absolute amount of bandwidth available.
Host Policy Maps
Generally, many hosts will be treated the same way. For example, there may be a few “rate plans” with different properties, and all hosts will be assigned to one of these rate plans.
...
For example, suppose that within an organization, desktop users are assigned to one subnet: 10.1.0.0/16. Externally accessible servers are assigned to another: 10.2.0.0/16. IFCs can be created that automatically assign hosts in the first group to a policy appropriate to desktop users, and hosts in the second group to a policy appropriate to servers.
Using Host Policy Maps to Determine Flow Policy
A host's HPM assignment can also be used to influence the policy applied to flows for that host. This is done using the 'match_host_policy_map' attribute of an ingress flow class.
...
For example, this could be used to allow incoming sessions only for designated servers. If servers are assigned to the HPM 'server', while desktop users are assigned to 'desktop', an IFC and ingress policy can be defined to block such flows unless the HPM is 'server'.
Using Host Policy Maps to Implement Per-Host Flow Classes
Sometimes it is required to manage bandwidth for different traffic types within a host. For example, it may be required to protect voice and video, to give preferred service to some applications, and to restrict others to a limited bandwidth regardless of what is available. This is exactly analogous to using egress flow classes to manage different traffic classes, and the solution is very similar.
...
As an example, the policy outlined above could be implemented with the following set of host policies.
video: assured, maximum bandwidth (rate) 6 Mbit/sec
voice: assured, maximum bandwidth 250 kbit/sec
preferred: no rate limit (rate set to something very large), rate_multiplier=4
normal: no rate limit, rate_multiplier=1
restricted: rate limit 2 Mbit/sec, rate_multiplier=0.5
Traffic is associated with the appropriate policy by the definition of suitable ingress flow classes, in exactly the same way as for egress flow classes.
Setting Limits on Host Policies
Host policies have two additional attributes, compared to egress policies, which allow limits to be set on flows associated with those policies.
flow_limit: sets a maximum number of flows that will be permitted for each host in this class. For example, the number of video flows could be limited to 3, ensuring that each of them receives a minimum opf 2 Mbit/sec
flow_rate_cap: sets the maximum rate for a single flow in this class
Sharing Bandwidth Between Different Host Policy Maps
By default, a host policy map gets its bandwidth share from the total bandwidth at the interface. For example, if an interface has a configured bandwidth of 1 Gbit/sec and has 100 active hosts, each host will receive at least 10 Mbit/sec. In practice, not all hosts will be using their available bandwidth, and the remainder will be shared amongst those that are able to use it.
...
Sometimes, it may be required to control the way the interface bandwidth is shared amongst different classes of hosts. For example:
an upper limit (less than the interface bandwidth) is to be made available to the class of hosts
available bandwidth is to be explicitly distributed among different classes of host
...
For example, suppose that there are two types of host. The first, called 'sp-abc', is to be limited collectively to 300 Mbit/sec, while the second, 'sp-def', is to be limited to 500 Mbit/ sec. The steps involved to implement this are:
Create EFCs called efc-sp-abc and efc-sp-def
Create egress policies for these, with 'rate' set to 300 and 500 Mbit/sec respectively
Create a host policy map hpm-sp-abc, with root_efc set to efc-sp-abc
Create a host policy map hpm-sp-def, with root_efc set to efc-sp-def
...