Sophisticated scheduling required to deliver tiered services
As operators continue to develop higher-margin services, the ability to provision and support multiple services becomes an increasingly critical priority. The DOCSIS 1.1 standard does not fully define the scheduling algorithms to be used in the cable headend, so cable operators face the challenge of ensuring that the Cable Modem Termination System (CMTS) architectures selected can deliver the Quality of Service (QoS) support required.
Sophisticated scheduling is required so that customers receive the prescribed bandwidth even when congestion appears on the cable network, and strict isolation and policing is required to enable premium pricing for tiered services. By evaluating the flexibility and robustness offered by different scheduling implementations, operators can deliver the Service Level Agreement (SLA) requirements and successfully police traffic flows to ensure compliance.
Subscribers want to be sure they are receiving the services for which they are paying. These needs give rise to the concept of QoS, which is represented in contractual terms by SLAs. The SLA can describe the manner in which QoS compliance will be measured and monitored, and can be used to constitute a legally binding agreement. Effective QoS is based on the DOCSIS scheduler that a CMTS implements, and this in turn determines the ability of a system to deliver SLA guarantees.
SLAs can be defined between an operator and multiple service providers, who in turn will develop SLAs with their own customers. To deliver tiered services, the scheduling implementation needs to ensure that SLAs are met at each level. For example, a service provider could have an SLA with an operator and also have SLAs with each of its subscribers. It is incumbent on the service provider to ensure that its SLA with the operator is more than adequate to meet its commitments to subscribers.
DOCSIS describes the functional capabilities that are required of the CMTS and cable modems but does not address the scheduling algorithms that are embedded in the headend. The QoS capability is determined by the implementation of the downstream scheduling algorithms employed by each CMTS vendor. Therefore, the range of credible SLAs that can be supported is determined by the sophistication of the schedulers implemented within each CMTS.DOCSIS-based cable networks
In the DOCSIS system, the transmission path over the cable network is controlled by the cable CMTS at the headend and the cable modem at the customer premises. The primary function of DOCSIS is the end-to-end delivery of IP packets, and the QoS capabilities supported by DOCSIS 1.1 are:
- Concatenation - the packing together of multiple packets into a single Medium Access Control (MAC) data frame;
- Fragmentation - the segmenting of a packet into multiple MAC data frames;
- Unsolicited Grant Service (UGS) - reserved upstream bandwidth for real-time traffic flows;
- Real-time Polling Service (rtPS) - reserved upstream bandwidth for real-time traffic flows but releases these if the flow is not active;
- Non-real-time Polling Service (nrtPS) - upstream transmission bandwidth allocation without latency constraints;
Best Effort Service - the key service elements are reserved minimum traffic rate, the maximum allowed traffic rate, and the traffic priority;
- Committed Information Rate (CIR) - defined as either a best effort with a guaranteed minimum data rate or an nrtPS with a guaranteed minimum data rate (a vendor implementation option).
In terms of DOCSIS, the QoS is defined for the service between the CMTS and the cable modem. However, tiered services may also require the ability to support multiple providers of content, applications, and services delivered via multiple backbone networks. Therefore, the CMTS must efficiently deliver QoS requirements end-to-end from the subscriber premises to the core network of multiple providers. DOCSIS is essential, but in itself not sufficient, because cable networks need to be able to support complementary technologies such as Multiprotocol Label Switching (MPLS) or Diff-Serv to ensure QoS across the cable network and multiple backbone networks.
Bandwidth management and service level agreements
Figure 1: Hierarchical per-flow queuing provides maximum control for bandwidth management and SLAs.
In DOCSIS 1.1, every incoming packet is matched to a classifier that determines to which QoS service flow it will be forwarded. The classifier examines different header fields of the packet to determine the corresponding action. In the case that no classifier is matched, the packet is forwarded to the primary service flow. Operators can augment DOCSIS by selecting CMTS equipment that offers incremental functionality for supporting QoS requirements.
They can manage the relationships between the service levels agreed for a user–and therefore tariffed at an agreed rate–and the ways in which those agreements are mapped onto the available bandwidths. Consider this schematic representation of the different conceptual service flows that need to be considered from a system and user perspective (See Figure 1).
In this graphic representation, there are four flow concepts; namely, broadband system, service provider, subscriber and application. Each flow can be considered as an established SLA in terms of parameters such as minimum bandwidth, peak bandwidth, average latency, loss characteristics, etc. These flows have a hierarchical relationship, and so tiered SLAs are possible at each level of the hierarchy. Tiering means that policing of the agreement is constrained to the tier and its immediate parent, thereby ensuring that potential service abuse is contained within the parent tier. Each of these flows is allocated on the basis of:
- Broadband system flow - this is the bandwidth that is available to the operator. This is, in effect, the bandwidth that is available for the downstream and upstream in individual channels or backbone connection.
- Service provider flow - this is the bandwidth that has been assigned by the operator for a particular service provider.
- Subscriber flow - the bandwidth that is allocated to each individual flow for each subscriber.
- Application flow - the bandwidth that is required for a particular application, e.g. Voice-over-IP (VoIP), Web browsing, etc. It is at this level that the nature of the flow needs to be defined in terms of whether the service needs to be isochronous, best effort, etc., so the appropriate QoS treatment can be provided to each application.
While the provision of the agreed SLA is important, an operator is also responsible for preventing service abuse, particularly if that abuse causes degradation in service provision to other users. Service abuse takes the form of attempting to exceed the requested characteristics of the agreed SLA, such as exceeding an agreed-upon average on a regular basis. Service abuse may or may not be intentional, but in either case, the policing of the service class provision is essential. This policing can be provided either explicitly or implicitly:
Explicit policing is the use of filtering algorithms that either shape the traffic to prevent excess loading or inspect the content to determine the nature of the load before entering the main scheduling algorithms.
Implicit policing is when the scheduling algorithms themselves are designed to prevent one class of user exceeding their SLA either intentionally or accidentally.
In many cases both techniques are used together to create a more robust system. In some cases, the service abuse can be tolerated if an appropriate tariff can be assigned to the excess portions, but only if this does not degrade other SLAs–including those that are less demanding of system capabilities. For example, an operator could decide to offer excess bandwidth at a premium price if a provider exceeds his SLA, as long as the bandwidth is available without imposing on other flows.
Operators can extend the benefits of DOCSIS 1.1 by selecting next-generation CMTS and routing solutions that offer increased intelligence to classify and treat traffic flows. Vendor implementations range from simply dividing traffic into a handful of queues with limited policing capabilities to per-flow queuing and policing that enable end-to-end QoS control across the HFC access network and the core networks of multiple providers.
An analysis of scheduling alternatives
Figure 2: Mean downstream throughput per-service level using a round robin scheduler.
Nettonics performed an analysis of various scheduling techniques to best understand the scheduling requirements for tiered services. A scenario was developed where a cable operator supported three classes of services: a Bronze service with guaranteed minimum bandwidth; a Silver service with a higher minimum bandwidth guarantee; and a Gold service with both a guaranteed minimum bandwidth and preferential access to unused bandwidth. In each scenario, the offered load of the Gold service is continuously increased to evaluate the impact on bandwidth allocation to all three services. Each service is allocated its own queue, and the scheduling algorithm services each queue according to the appropriate discipline.
A computer simulation was used to compare performance characteristics of basic round robin scheduling, First-In First-Out (FIFO) scheduling, and hierarchical, per-flow queuing. Analysis showed that round robin scheduling was adequate only for best-effort services and offered no real capability for delivering tiered services (See Figure 2).
Figure 3: Mean throughput per-service level using an Exhaustive First-In-First-Out (FIFO) scheduler.
FIFO queuing is both a queuing and scheduling mechanism in which all packets stored in a queue are transmitted in the order in which they are received. The FIFO scheduling was adequate for Gold services, but when the Gold services required additional bandwidth, it was delivered at the expense of Silver and Bronze services. The Silver Service was also capable of consuming bandwidth at the expense of the Bronze service, demonstrating that FIFO is also inadequate for delivering tiered services because lower priority services may never receive even minimal bandwidth requirements (See Figure 3). It is only appropriate for use in systems where provisioning priorities can be clearly identified and where it is acceptable to deny bandwidth to lower priority applications.
Figure 4: Mean downstream throughput per-service level using hierarchical per-flow queuing.
Hierarchical per-flow queuing was shown to meet at least minimum guaranteed bandwidth requirements for each service class (See Figure 4). As the offered load on the Gold service class increases, the others are managed until their minimum thresholds are reached. This ensures that all service classes receive their guaranteed bandwidth requirements and that any extra available bandwidth could be allocated to the more premium services.
While these simulations focused on only three tiers of service, hierarchical per-flow queuing can support any number of service classes, and the scheduling mechanism can go beyond focusing on average and minimum service classes to incorporate other allocation characteristics, such as peak bandwidth, latency considerations, etc.Per-flow packet treatments
The implementation of hierarchical per-flow queuing in combination with backbone QoS mechanisms such as MPLS, ATM, or Diff-Serv can accommodate the complex scheduling requirements of tiered services. Simple scheduling algorithms cannot guarantee minimum throughput requirements for more than one class of service. They do not have the functional capability to support service classes with even the most trivial differences such as minimum bandwidth requirements.
Other scheduling implementations also lack the granularity required to effectively support tiered services. For example, class-based queuing is often used, but it provides limited QoS control. This approach sorts traffic into different classes by examining the packet header–and sometimes the content as well–to try to determine the type of traffic to which the packet belongs. Once the packet has been classified, it is placed in a FIFO queue that contains only other packets of the same type. In theory, this allows the FIFO of each class to provide the desired type of service, but in practice, there are a number of problems with this approach. It requires a constant, heavy configuration burden because the operator has to configure the allocation of service to the different classes.
In a dynamic network environment, the class-based queuing method of allocating service is impractical because the allocation is independent of the number of users of a given class. It provides minimum flexibility for delivering premium services and creating new revenue streams.
The class-based queuing approach assumes that it is possible to determine the type of traffic–and therefore the type of service desired–simply by looking at a packet. The theory is that the type of the packet can be determined by simple properties of the packet, such as its port number. However, today many types of applications run over HTTP, and there is no way to tell if a Web connection is carrying a business-critical outsourced business application or a casual Web browsing session. As end-to-end encryption becomes more widespread, it will become impossible to look inside the packet for clues to determine the class of the packet. Operators therefore lose traffic visibility when flows are encrypted, thus preventing the application of any meaningful QoS parameters. Because encryption will only become more widespread, class-based queuing will become an even less optimal approach for QoS in the future.
With per-flow queuing, systems can track individual traffic flows and ensure that users are within their SLA requirements, and they can take active control to implement packet discard policies that first discard traffic flows violating SLA agreements. While basic round robin or FIFO queuing can be implemented in software, hierarchical per-flow queuing requires hardware-based processing for real-time packet inspection and filtering. Implementations require a high-powered QoS routing engine and a DOCSIS 1.1-compliant CMTS. The QoS on the HFC network is provided by mapping IP flows to DOCSIS 1.1 service flows, and the QoS on the metropolitan network is provided by mapping IP flows to independent physical networks, IP Diff-Serv networks, or MPLS networks.
DOCSIS 1.1 defines several methods for the support of data transmission using different access methods, and SLAs represent the mapping of these access methods into measurable, end-to-end characteristics. Operators delivering tiered services will be able to offer many SLAs that are then automatically provisioned by the CMTS/router. Tiered SLAs can therefore be supported so that new services can be offered within an established framework, thereby ensuring that attempted service abuse on one SLA does not affect other SLA commitments, and allowing operators to make measurable guarantees to both subscribers and revenue-sharing partners.
|About the authors|
|Gerry White is Chief Technical Officer of RiverDelta Networks, a supplier of CMTS/routers that can be found on the Web at www.riverdelta.com. Dr. Colin Smythe is CEO of Nettonics Ltd., a specialist consultancy company providing products and services for the performance analysis and evaluation of digital communications networks. More information on the firm can be found at www.nettonics.com.|