|
Previous
|
Content |
Next
|
|
| 1.6.- Expedited Forwarding PHB |
|
|
|
| Continuing our study of Differentiated Service we are going to see now our last PHB, named "Expedited Forwarding PHB" (EF PHB). Without losing any time let's start copying here for comments the introduction taken directly from the RFC 2598 specification: |
| Network nodes that implement the differentiated services enhancements to IP use a codepoint in the IP header to select a per-hop behavior (PHB) as the specific forwarding treatment for that packet [RFC2474, RFC2475]. This memo describes a particular PHB called expedited forwarding (EF). The EF PHB can be used to build a low loss, low latency, low jitter, assured bandwidth, end-to-end service through DS domains. Such a service appears to the endpoints like a point-to-point connection or a "virtual leased line". This service has also been described as Premium service [2BIT]. |
| |
| Loss, latency and jitter are all due to the queues traffic experiences while transiting the network. Therefore providing low loss, latency and jitter for some traffic aggregate means ensuring that the aggregate sees no (or very small) queues. Queues arise when (short-term) traffic arrival rate exceeds departure rate at some node. Thus a service that ensures no queues for some aggregate is equivalent to bounding rates such that, at every transit node, the aggregate's maximum arrival rate is less than that aggregate's minimum departure rate. |
| |
| Well. This PHB is some sort of fast-track service. Low all. Guaranteed bandwidth. The golden dream of any application requiring a "First Class" service. An a lot of applications are just as demanding. Specially those of them that have to deal with real-time services. Real-time service traffic requires a very fast and safe service for the moving of data from sources to destinations. EF PHB is the answer offered by DS to these kind of demanding flows. The service is so guarantee that is as having a private pipe or "virtual leased line" to move our data. But, wait a minute. How can we offer this kind of excellent service to our VIP customers? |
| |
| As the specification assertively explains, loss, latency and jitter are all due to the queues flows
experience while transit the network. These queues are formed on routers along the path. Because is almost impossible to avoid these queues, then given to some flows this VIP service is a matter of creating for them a special path on routers that bypass the queues. Something similar as occur at custom's airports when diplomatic people have one special and priviledged attention desk that hurry up the bothering process. Sonething very disagreeable for us, normal mortals, but that in fact exists and is used. |
| |
| To ensure this special fast service we have to configure our routers such that, for these flows, the aggregate's minimum departure rate should be always greater than the aggregate's maximum arrival rate. For reaching this goal our routers have to be enough powerful to forward, as fast as possible, the total throughput that is intended to cross through them; and for class-I flows this forwarding will be done on special fast-track queues specifically designed and configured to fullfil these requirements. Do not forget this. Routers have to be enough capable. It doesn't have any sense to configure special fast-track queues on routers that do not have enough capacity to forward, comfortably, the total throughput that you are thinking to move through them. |
|
|
|
|
| Creating such a service has two parts: |
- Configuring nodes so that the aggregate has a well-defined minimum departure rate. ("Well-defined" means independent of the dynamic state of the node. In particular, independent of the intensity of other traffic at the node.)
- Conditioning the aggregate (via policing and shaping) so that its arrival rate at any node is always less than that node's configured minimum departure rate.
|
| The EF PHB provides the first part of the service. The network boundary traffic conditioners described in [RFC2475] provide the second part. |
| Okay. EF PHB will be in charge of guaranteing a minimum departure rate for some BA; this rate will be independent of the rest of the traffic to be forwarded by the router at the same time. On the other hand conditioning, as was seen when we studied RFC 2475 specification, will be in charge of controlling arriving rate to fullfil the requirement that departure rate is always greater than arrival rate. |
| The EF PHB is defined as a forwarding treatment for a particular diffserv aggregate where the departure rate of the aggregate's packets from any diffserv node must equal or exceed a configurable rate. The EF traffic SHOULD receive this rate independent of the intensity of any other traffic attempting to transit the node. It SHOULD average at least the configured rate when measured over any time interval equal to or longer than the time it takes to send an output link MTU sized packet at the configured rate. (Behavior at time scales shorter than a packet time at the configured rate is deliberately not specified.) The configured minimum rate MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration). |
| Here authors describe EF PHB behavior. Observe that specification concentrates in guaranteing a forwarding treatment for a particular BA having a departure rate that must be equal or exceed a configurable rate. Conditioning on enter will guarantee that arrival rate is going to be below this previously selected rate. |
| If the EF PHB is implemented by a mechanism that allows unlimited preemption of other traffic (e.g., a priority queue), the implementation MUST include some means to limit the damage EF traffic could inflict on other traffic (e.g., a token bucket rate limiter). Traffic that exceeds this limit MUST be discarded. This maximum EF rate, and burst size if appropriate, MUST be settable by a network administrator (using whatever mechanism the node supports for non-volatile configuration). The minimum and maximum rates may be the same and configured by a single parameter. |
| This part is very important. It's really no easy to establish quantifible settings to slippery concepts such as loss, delay and jitter. What is normally done with traffic asking for these requirements is to put them in specially designed queues with the highest priority dispatch and the lowest drop probability. Flows managed in these queues are forwarded as soon as possible having priority over other concurrent flows (preemption). They are inmmune to drop policies and only in case of extremely congestion situations could the router attempt against them. But, beware, implementing this kind of
"royalty" will certainly destroy the forwarding opportunity of other flows. If the "royalty" is not put under strict control surely it will starve the performance behavior of the rest of mortals. That's because specification calls for an upper limit for the rate, and burst size if appropriate, for these aggregates. These maximums must be settable by the network administrator. Traffic that exceeds this limit must be discarded. |
| Several types of queue scheduling mechanisms may be employed to deliver the forwarding behavior described in section 2.1 and thus implement the EF PHB. A simple priority queue will give the appropriate behavior as long as there is no higher priority queue that could preempt the EF for more than a packet time at the configured rate. (This could be accomplished by having a rate policer such as a token bucket associated with each priority queue to bound how much the queue can starve other traffic.) |
| It's also possible to use a single queue in a group of queues serviced by a weighted round robin scheduler where the share of the output bandwidth assigned to the EF queue is equal to the configured rate. This could be implemented, for example, using one PHB of a Class Selector Compliant set of PHBs [RFC2474]. |
| Another possible implementation is a CBQ [CBQ] scheduler that gives the EF queue priority up to the configured rate. |
| Here the authors try to give some ideas of how to implement the queuing discipline required to lend the EF PHB. They point out three possibilities. The simplest one is a priority queue where providences are taking to avoid starving EF for other flows or starving other flows for EF. A priority queue is a simple scheme where several queues are served in a hierarchy; as soon as there are packets in the highest priority queue they are served (forwarded) before the next priority queue is attended. When the highest priority queue is empty the next one in the hierarchy is served; following this way until the lowest one is served. As is obvious higher priority queues must have upper limits to the throughput to be forwarded as a mechanism to avoid starving lower priority queues. |
| |
| The second scheme is a weighted round robin scheduler. In this scheme the queues are served in a round robin fashion and weights are assigned to point out how much of the total time is intended for serving each queue. Playing with the weights, the share of the output bandwidth assigned to the EF queue can be set to the configured rate (minimum departure rate). More sophisticated schemes can include prioritization (preemption) of some queues. |
| |
| The last scheme is based on the
state-of-the-art CBQ (Class Based Queue) scheduler. CBQ is a highly
sophisticated scheme where several mechanism basically merge PQ (priority
queue) and fair capabilities to provide different kind of services to data
traffic. CBQ distribute bandwidth between classes in a hierarchical
link-sharing structure where each class correspond to some aggregation of
traffic. Later on we are going to see how different queuing discipline
implementations can be used to build the DS architecture. But now let's continue with the specification: |
| |
| Codepoint 101110 is recommended for the EF PHB. |
| |
| Finally the recommended codepoint is given. Just to make an analogy with AF PHB Group, observe that the class is number 5 (the next one). But the analogy borns and dies here because if we go ahead the drop precedence would be "high" and this is a contradiction. Why? Also the rightmost bit is preserved for signalling in-profile or out-of-profile traffic. |
| |
| Well. With this we finished the theoretical part of our HOWTO. Next the practical part begins. I prefered to focus the issue this way because it doesn't have any sense to talk about DS architecture, behavior aggregates, per hop behaviors, marking, shapping, dropping, classes, etc., that will confuse the lector, if we do not establish, previously, a framework where everyone can talk, listen and understand the same. Perhaps someone could say that I misunderstood the specifications and then the framework is wrong. I admit this possibility. But in this case all of it is wrong. No untied pieces as generally occurs. And the confusion grows as you try to join the different authors. |
|
|
|
|
|
|
|
|
|
Previous
|
Content |
Next
|
