Go to main content

Managing IP Quality of Service in Oracle® Solaris 11.4

Exit Print View

Updated: August 2018
 
 

Planning Flow Control

Flow control involves measuring traffic flow for a class and then releasing packets onto the network at a defined rate. When you plan flow control, you define parameters to be used by the IPQoS metering modules. The meters determine the rate at which traffic is released onto the network. For an introduction to the metering modules, see Meter (tokenmt and tswtclmt) Overview.

Traffic is generally metered for the following reasons:

  • An SLA guarantees packets of this class greater or lesser service when the network is heavily used.

  • A class with a lower priority might have a tendency to flood the network.

You use the marker with the meter to provide differentiated services and bandwidth management to these classes.

How to Plan Flow Control

Before You Begin

Before planning flow control, you should have defined filters and selectors, as described in How to Define Filters in the QoS Policy.

  1. Determine the maximum bandwidth for your network.
  2. Review any SLAs that are supported on your network and identify customers and the type of service that is guaranteed to each customer.

    To guarantee a certain level of service, you might need to meter certain traffic classes that are generated by the customer.

  3. Review your list of classes to determine whether any classes other than those classes that are associated with SLAs need to be metered.

    For example, suppose the IPQoS system runs an application that generates a high level of traffic. After you classify the application's traffic, meter the flows to control the rate at which the packets of the flow return to the network.


    Note -  Not all classes need to be metered.
  4. Determine which filters in each class select traffic that needs flow control. Then, refine your list of classes that require metering.

    Classes that have more than one filter might require metering for only one filter. For example, if you define filters for incoming and outgoing traffic of a certain class, you might conclude that only traffic in one direction requires flow control.

  5. Choose a meter module for each class to be flow controlled and add the module name to the meter column in your QOS planning table.
  6. Add the rates for each class to be metered to the planning table.

      If you use the tokenmt module, you need to define the following rates in bits per second:

    • Committed rate

    • Peak rate

    If these rates are sufficient to meter a particular class, you can define only the committed rate and the committed burst for tokenmt.

      If needed, you can also define the following rates:

    • Committed burst

    • Peak burst

    For a complete definition of tokenmt rates, refer to Configuring tokenmt as a Two-Rate Meter. You can also find more detailed information in the tokenmt(4IPP) man page.

    If you use the tswtclmt module, you need to define the following rates in bits per second.

    • Committed rate

    • Peak rate

    You can also define the window size in milliseconds. These rates are defined in tswtclmt Metering Module and in the tswtclmt(4IPP) man page.

  7. Add traffic conformance outcomes for the metered traffic to the planning table.

    The outcomes for both metering modules are green, red, and yellow. Outcomes for the meters are fully explained in Meter Module.

    You need to determine what action should be taken on traffic that conforms, or does not conform, to the committed rate. Often, but not always, this action is to mark the packet header with a per-hop behavior. One acceptable action for green-level traffic could be to continue processing while traffic flows do not exceed the committed rate. Another action could be to drop packets of the class if flows exceed peak rate.

Example 2  Defining Meters

The following example shows meter entries for a class of email traffic. The network on which the IPQoS system is located has a total bandwidth of 100 Mbits/sec, or 10000000 bits per second. The QoS policy assigns a low priority to the email class. This class also receives best-effort forwarding behavior.

Class
Priority
Filter
Selector
Rate
email
8
mail_in
daddr10.50.50.5
dport imap
direction LOCAL_IN
email
8
mail_out
saddr10.50.50.5
sport imap
direction LOCAL_OUT
meter=tokenmt
committed rate=5000000
committed burst =5000000
peak rate =10000000
peak burst=1000000
green precedence=continue processing
yellow precedence=mark yellow PHB
red precedence=drop