QBone Premium | Scavenger | Deployment
News | Calendar | QoS Working Group

QBone Scavenger Service (QBSS)

QBone Scavenger Service (or simply ``scavenger service'') is a network mechanism to let users and applications take advantage of otherwise unused network capacity in a manner that would not substantially affect performance of the default best-effort class of service.

Mailing list: qbss-interest@internet2.edu with an open archive. Anyone interested in scavenger service is encouraged to subscribe by sending an email to listproc@internet2.edu; in the body, include the line
subscribe qbss-interest Firstname Lastname

Scavenger Service FAQ

How does scavenger service actually work?

Informally, scavenger service creates a parallel virtual network with very scarce capacity. This capacity, however, is elastic and can expand into capacity of the normal best-effort class of service whenever the network has spare cycles. The expansion happens with a very high time granularity: everything not used by the default class is available for the scavenger class.

Users (or their applications) voluntarily mark some traffic for scavenger treatment by setting differentiated services code point (DSCP) in the IP packet headers to binary 001000. Routers put this traffic into a special queue with very small allocated capacity using a queuing discipline such as weighted round-robin (WRR), modified deficit round-robin (MDRR), weighted fair queuing (WFQ), or similar.

The formal scavenger service definition should make the details more clear.

Why didn't you just make scavenger a lower priority class without minimum departure rate?

With a strict priority treatment scavenger traffic would become subject to starvation. During periods of congestion lasting for tens of minutes or more, TCP connections in the scavenger class would time out. Defining scavenger as simple priority for the default class would require application developers to make the logic of their applications more complex (by attempting to reconnect in case of a timeout). We wanted to make scavenger compatible with existing TCP applications.

Why did you have to specify a globally significant scavenger DSCP?

While within the normal differentiated services framework DSCPs have only local significance, we found it necessary to have a single codepoint in all domains. The main argument to make DSCP locally significant is, essentially: ``Since in a QoS world every domain has to police DSCPs on every domain boundary, it would not be any harder to rewrite DSCPs than it would be to police them; having local flexibility enables one to experiment with more classes of service and makes for a better use of a scarce resource---64 different DSCPs.'' The argument is mostly correct if one restricts the considered services to those that have elevated priority semantics (such as a form of premium or assured service). The antecedent of the argument is no longer correct for non-elevated priority services such as scavenger (i.e., those services that do not provide better treatment but that provide treatment that is either worse than the default, as is the case with scavenger service, or that is different, but equal, as would be the case with a service such as the alternative best-effort service). With non-elevated priority services, one no longer needs to police DSCPs at every network boundary.

DSCP policing and re-marking functionality is not available on every router; when it is available for a router, it might not be supported on every kind of interface; when it is supported, it can come with a significant performance cost (often more than 50% packet-per-second rate drop). Having to police and re-mark on every network boundary has actually been a quite significant practical hurdle to deployment of inter-domain quality of service so far. Even those networks that are built using routing equipment that can rewrite DSCPs without performance degradation on every interface still suffer from increase of operational complexity. Getting rid of this requirement has tremendous practical benefit for many networks.

Importantly, having a globally significant DSCP enables one to deploy scavenger service on a granularity of a single (congested) network interface rather than on a granularity of a whole network.

In addition, as long as they are DSCP-transparent (at least for non-elevated global codepoints), uncongested core networks can simply ignore these markings without affecting the end-to-end service.

Why would anyone possibly mark their traffic for degraded treatment?

There can be a number of reasons:

Why would a network operator support scavenger?

Why do you call it a ``QoS technique'' if the treatment is actually worse than that of best-effort traffic?

Scavenger is an application of differentiated services quality of service framework for creation of a service that gives different treatment to different packets. Some packets are treated worse; this means that some other packets are treated better. QoS isn't about treating things better (it doesn't create network capacity)---it's about treating things non-uniformly.

Did you guys come up with scavenger all by yourself?

We most definitely do not get the credit for the idea of creating a class of service that receives treatment that is worse that the normal treatment. We refined the definition, adopted it for existing routing equipment and incremental deployment properties, made decisions about the fine points, tested equipment, and deployed the service.

Earlier work includes ``A Lower Than Best-Effort Per-Hop Behavior'' internet-draft by R. Bless and K. Wehrle and ``A Bulk Handling Per-Domain Behavior for Differentiated Services'' internet-draft by B. Carpenter and K. Nichols.

Scavenger Router Configuration Examples

Scavenger Host Configuration

If a unix application with available source code wishes to mark traffic sent through a particular TCP connection for scavenger treatment, it can use a setsockopt() call as follows:
	#define IPTOS_QBSS		0x20
	int qbss = IPTOS_QBSS;
	setsockopt(sock, IPPROTO_IP, IP_TOS, (char *) &qbss, sizeof qbss);

In addition, patches to enable the configuration of scavenger service are available for the following applications:

Scavenger Deployment Status

Networks that are known to have configured a bottom-feeding queue for scavenger service traffic on one or more of their router interfaces:

Several groups are experimenting with QBSS for long-lived, high-throughput bulk transfers. We are aware of work at:

A number of Internet2 universities have begun marking portions of their traffic for QBSS. The following graph (generated as part of Internet2 NetFlow Weekly Reports) represents the percentage of scavenger traffic (octets) on the Abilene network:

In addition, NetFlow-derived AS matrices are available from Ohio ITEC Abilene NetFlow nightly reports page.

Scavenger Router Testing Results

Talks about Scavenger Service

Design Team (Concluded)

QBSS was designed by a design team working within the Internet2 QoS working group. The following people participated in design team's work: Dave Hartzell, Great Plains Networks; Simon Leinen, SWITCH; Will Murray, Cisco; Joe St Sauver, University of Oregon; Stanislav Shalunov, Internet2 (chair); Ben Teitelbaum, Internet2. The desing team has concluded.

You can look at the design team mailing list archive. As a result of its work, the following QoS WG documents were published:

Comments: Stanislav Shalunov