The QoSbox can enforce a "Quantitative Assured Forwarding" service. The "Quantitative Assured Forwarding" service consists of any combination of the following types of service guarantees, on a per-hop, per-class, basis over a busy period:

• Proportional Delay Differentiation between classes of traffic. For instance, Class-2 Delays = 4 Class-1 Delays. "Delay" here means "time spent at the transmission queue of the output link of the router."
• Proportional Loss Differentiation between classes of traffic. For instance, Class-2 Loss Rate = 4 Class-1 Loss Rate. "Loss rate" here means "fraction of traffic dropped since the beginning of the current busy period."
• Absolute Delay Guarantees. For instance, Class-1 Delays < 5 ms means that no Class-1 packet should spend more than 5 ms in the transmission queue of the output link of the QoSbox
• Absolute Loss Rate Guarantees. For instance, Class-2 Loss Rate < 1% means that no more than 1% of all Class-2 traffic can be dropped.
• Absolute Throughput Guarantees. For instance, Class-4 Throughput > 5 Mbps means that the aggregate throughput of Class 4 is always at least 5 Mbps during a busy period when Class 4 presents a backlog.

It is the acronym used for the "Quantitative Assured Forwarding" service described in this section.

A busy period is an interval of time during which the transmission queue of the output link is continuously backlogged. The current busy period thus started the last time the transmission queue was empty.

"Per-class, per-hop service guarantees" means that the service guarantees are provided for aggregates of traffic grouped into classes with similar quality-of-service requirements, and that the service guarantees are offered locally, at the considered QoSbox only.

Except for delay bounds (all flows in a class subject to a delay bound will be subject to this delay bound), the answer is no, at this time. We are currently working on additional fairness mechanisms that can allow to infer per-flow service guarantees in the context of a class-based service such as QAF.

You cannot get end-to-end service guarantees directly. However, if (1) you know how many QoSboxes will be traversed by a given flow, and (2) know which per-hop guarantees each QoSbox provides, you can infer which end-to-end service guarantees you will obtain. More generally, if you want to be able to provide end-to-end guarantees with a set of QoSboxes, you will need to know in advance which route packets will follow. Such route-pinning can be performed by routing mechanisms such as source-routing or MPLS, for example.

We are only getting started on this issue. We believe that the end applications should have the choice of which class they need to ask for. In such a context, as far as pricing is concerned, we envision some form of usage-based pricing, where traffic using high-performance classes would be charged more expensively than traffic using low-performance classes. This is the subject of ongoing research.

The service guarantees are deterministic, but, since we want to avoid using admission control, some "weaker" service guarantees may need to be temporarily relaxed if the traffic demand is too large. Experiments presented in our papers show that, except for pathological cases, the relaxation of service guarantees is rare.

JoBS (Joint Buffer Management and Scheduling) is the scheduling/dropping algorithm used in the QoSbox. It is really the "workhorse" of the QoSbox. JoBS is a feedback-control based algorithm, which allows its implementation at relatively high-speeds.

Yes, that is correct. Literally speaking, JoBS is indeed an "ideal" algorithm, using a non-linear optimization solver. Of course, solving a non-linear optimization problem upon each packet arrival is not feasible in practice, and we thus had to devise some heuristics that approximate the behavior of the JoBS algorithm. The latest and most efficient heuristic we devised relies on feedback-control theory, and, is abusively (even by us) referred to as JoBS, since no practical implementation of the original, optimization-based, JoBS exists. We could have called this heuristic FB-JoBS (Feedback Based-JoBS) or something like that, but we thought there were already enough acronyms used in the Internet, and so we never gave it an actual name.

Buffer management and scheduling are performed by a single algorithm, and the algorithm does not rely on admission control or policing of traffic.

We wish, we'd probably be rich by now. More seriously, the QoSbox is a research project, so the answer is no: you cannot order a QoSbox, there are no QoSboxes in production. But some prototype code is available that can transform your PC into a QoSbox. Please read on.

At this time, no, even though we are planning on implementating our algorithms on Intel IXP 1200 programmable routers. Then again, due to licensing issues (the IXP SDK is proprietary software), we do not know if and when the IXP code will be made available.