QBone Scavenger Service (QBSS) Definition Internet2 Technical Report, Proposed Service Definition March 16, 2001 Stanislav Shalunov Benjamin Teitelbaum QBone Scavenger Service (QBSS) is an additional class of best-effort service. A small amount of network capacity is allocated (in a non-rigid way) for this service; when the default best-effort capacity is underutilized, QBSS can expand to consume unused capacity. Since best-effort service is hard to define in positive terms, QBSS is at least as hard to describe. Hence, we elected to provide an operational description that would focus on delineating router configuration rather than categorizing the service from a point of view external to the network. Applications that are relatively tolerant of greater loss, delay, and jitter may mark their traffic for QBSS and receive a level of service that is potentially degraded compared to the default best-effort service. Marking traffic for QBSS can be thought of as roughly analogous to the Unix notion of assigning a positive "nice" value to a process. Within QBone, traffic marked with DSCP 001000 (binary) shall be considered in the QBSS class and should be given the service described in this document. Notice that while DSCP values generally have only local significance we are assigning global significance to this particular codepoint within QBone. We refer to packets marked with DSCP 001000 as being marked with the "QBSS codepoint". Requirements for participating differentiated services domains: * Any packet leaving the domain MUST be marked with the QBSS codepoint if that packet entered the domain (either from a peering domain or from an end host) marked with the QBSS codepoint * Routers in a participating domain SHOULD do one of the following: (1) forward Scavenger traffic independently from best-effort giving it a lower probability of timely forwarding than that of best-effort (DSCP 000000) traffic (2) treat Scavenger traffic in the same manner best-effort is treated NOTE: Use of WRED to provide degraded performance to QBSS traffic would result in bursts of QBSS traffic affecting best-effort jitter. This is to be avoided. However, if special treatment is required where independent forwarding is not available, breaking this "SHOULD" and using WRED could be acceptable. * For each router in a participating domain there SHOULD exist an integer constant C such that after C best-effort packets are sent from any given interface, with high probability at least one QBSS packet is sent, provided there is a continuing stream of offered QBSS packets NOTE: It is desirable to be able to run long-lived TCP flows in QBSS class. If complete starvation of QBSS were allowed, QBSS TCP connections would break if best-effort is congested for a prolonged period of time. It's not expected that QBSS flows would make much progress when best-effort is congested, but they should be able to at least get a packet through once in a few minutes. This requirement is not a MUST because one can imagine routers that implement strict priority queuing but not CBQ or WFQ. * All bandwidth not used by other types of traffic SHOULD be available to QBSS traffic NOTE: A domain that doesn't pay attention to (and doesn't change) DSCP marking of packets satisfies all QBSS requirements. This allows for incremental deployment of the service where it matters--at ends of congested links. Usage Recommendations QBSS marking may be performed by the end hosts or by edge routers on behalf of end hosts. It is anticipated that the following types of applications might utilize QBSS: * New types of distributed applications that attempt to use idle network capacity in the same manner distributed computations applications make use of users' idle CPU cycles * Bulk data transfers using TCP or employing a TCP-friendly congestion avoidance algorithm * Non-time-critical traffic, such as multimedia peer-to-peer applications, anonymous FTP, HTTP when used to distribute large files, network backups, etc. Applications that lack TCP-friendly congestion avoidance are discouraged. To avoid traffic becoming hard to characterize (HTTP/HTTPS collapse, random negotiated ports collapse, proxies to disguise real destination, etc.) all involuntary edge router marking based on layer 2+ information in the packets is discouraged. Marking all traffic coming into a particular port on a router with DSCP 001000 is permissible. NOTE: "Voluntary" in this context means that nothing in the networks forces one to mark. Stimuli can exist outside the network (e.g., administrative requirements to mark all non-mission traffic), but we don't consider this marking "involuntary".