Cross-Protect
A new QoS architecture for IP networks
A combination of flow-aware QoS control
mechanisms in an IP router
Effective control of Quality of Service (QoS) in IP networks is a priority for
operators like France Telecom. Our evaluation of currently available QoS
solutions (Intserv, Diffserv,?) reveals inadequacies which have led us to
propose an alternative flow-aware QoS architecture called Cross-Protect.
Cross-Protect represents a new direction for QoS. Its originality resides in its
ability to offer adequate quality of service to both data flows and real-time
flows without the need for explicit class of service differentiation
(no packet marking as in Diffserv, no resource reservation as in Intserv).
Cross-Protect performs implicit differentiation. This results in much simpler
network operations leading to potentially significant cost reductions in the IP
backbone.
Principle
Cross-Protect combines two flow-aware control mechanisms to be implemented in an IP router:
- per-flow fair queueing ensures that
link bandwidth is shared equitably between contending flows
- per-flow admission control ensures
the scheduler performs correctly even under heavy traffic (utilisation
greater than 90%) by maintaining the fair rate above a minimum
threshold.
On very high capacity links (2.5 Gbit/s and above), fair queueing is enough to
guarantee low packet delay and loss for real-time flows (whose rate is less
than the fair rate). However, Cross-Protect implements a novel enhancement
whereby packets of flows emitting at less than the current fair rate are given
priority. This enables useful performance guarantees for a range of real-time
services even on links of lower capacity and with no requirement for packet
marking.
Prototype
We have developed a prototype that implements the Cross-Protect mechanisms in a
Linux router. The double objective is to demonstrate the feasibility of the
architecture and to convince network operators and equipment vendors of its
utility.
Advantages for an operator
The introduction of Cross-Protect would bring a number of significant advantages
for the network operator. It increases network efficiency. It avoids the current
requirement to rely on users correctly implementing TCP to ensure fair bandwidth
sharing. It requires no change to existing protocols and no new protocols. It
can be introduced incrementally starting, for example, with routers that control
strategically important links such as peering links. Preliminary trials and
experiments performed with our Networking Division, discussions with equipment
vendors and the emergence of commercial "flow-aware" products demonstrate that
there are no technological barriers to the deployment of Cross-Protect.
Publications
- Minimizing the Overhead in Implementing Flow-aware Networking,
A. Kortebi, L. Muscariello, S. Oueslati and J. Roberts,
to appear in ANCS'05,
Princeton, USA, October 2005. [preprint: .pdf]
- Implicit Service Differentiation using Deficit Round Robin,
A. Kortebi, S. Oueslati and J. Roberts,
ITC19,
Beijing, August 29-September 2, 2005. [.pdf]
- Evaluating the number of Active Flows in a Schedular Realizing Fair Statistical Bandwidth Sharing,
A. Kortebi, L. Muscariello, S. Oueslati and J. Roberts,
SIGMETRICS'05, Banff, Canada, June 2005.
[.pdf]
- A new direction for quality of service: Flow aware networking,
S. Oueslati and J. Roberts.
NGI 2005, Rome, April 18-20, 2005.
[.pdf]
- On the scalability of fair queueing,
A. Kortebi, L. Muscariello, S. Oueslati and J. Roberts.
ACM HotNets-III, San Diego, USA, November 2004.
[.pdf]
- Internet Traffic, QoS and Pricing,
J. Roberts. Proceedings of the IEEE, Volume: 92 , Issue: 9 , Sept. 2004, Pages:1389 - 1399.
[.pdf]
- MBAC algorithms for streaming flows in Cross-protect,
A. Kortebi, S. Oueslati and J. Roberts.
EuroNGI Workshop, Lund, Sweden, June 2004.
[.pdf]
- Cross-protect: implicit service differentiation and admission control,
A. Kortebi, S. Oueslati and J. Roberts.
IEEE HPSR 2004, Phoenix, USA, April 2004.
[.pdf]
- Flow-aware networking
- Why does the network need to be flow-aware?
- Does flow-aware imply a solution like Intserv or ATM?
- What service guarantees are provided by Cross-protect?
- FAN has been designed with current services and technology in mind; is it necessarily future proof?
- Have all the problems to do with implementing FAN been solved?
- Fair queueing
- Is per-flow fair queuing sufficient?
- Why not increase "utility" by using weighted fair sharing?
- Why not improve elastic flow performance using size-based scheduling?
- Is it also possible to provide hard bandwidth guarantees for certain flows?
- Admission control
- What is the role of admission control?
- Don't users generally prefer reduced throughput rather than no throughput at all due to blocking?
- Why would users accept the implicit blocking signal of packet discard and not continue to send additional packets?
- Doesn't distributed admission control lead to inconsistencies with flows admitted on some links and blocked on others?
- What key can be used to distinguish priority flows in a system with discriminatory blocking?
- Complexity, implementation
- Is per-flow fair queuing scalable?
- Is implicit per-flow admission control scalable?
- Is it necessary to implement Cross-protect on every link?
- Can Cross-protect be combined advantageously with other traffic control mechanisms?
- Does FAN/Cross-protect bring additional operational expenditure?
- Can Cross-protect be implemented in an input-queued switch fabric?
- How can we perform flow-aware networking if flows are masked by tunnels?
- Is FAN compatible with the implementation of VPNs?
- Denial of service
- Can users avoid flow blocking by maintaining a stream of keep-alive packets between a given source and destination?
- Can users saturate the protected flow table by sending a lot of single packet flows (e.g., by using a different flow id for every packet)?
- Can users gain more than a fair share by setting up several flows in parallel?
- Can users ensure low latency for a high rate flow by disguising it as multiple lower rate flows?
Les informations de cette page n'engagent que son auteur et ne constituent en rien une information émanant de France Télécom
Ces pages sont hébergées par France Télécom R&D 38-40 Av. du Général Leclerc 92794 Issy les Moulineaux CEDEX
