[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
Internet Engineering Task Force                 B. Carpenter
Differentiated Services Working Group           IBM
Internet Draft                                  K. Nichols
Expires in July, 2001                           Packet Design
draft-ietf-diffserv-pdb-bh-02                   January, 2001

        A Bulk Handling Per-Domain Behavior for Differentiated Services

Status of this Memo

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This document is a product of the Diffserv working group. Comments
on this draft should be directed to the Diffserv mailing list
<diffserv@ietf.org>.  The list of current Internet-Drafts can be
accessed at www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
www.ietf.org/shadow.html. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2001). All Rights Reserved.


This document proposes a differentiated services per-domain behavior
whose traffic may be "starved" (although starvation is not strictly
required) in a properly functioning network. This is in contrast
to the Internet's "best-effort" or "normal Internet traffic" model.
The name, "bulk handling" is loosely based on the United States'
Postal Service term for very low priority mail, sent at a reduced
rate. This document gives some example uses, but does not propose
constraining the PDB's use to any particular type of traffic.

1 Description of the Bulk Handling PDB

This document proposes a differentiated services per-domain behavior
[PDBDEF] called bulk handling (BH) which makes it possible to admit
traffic of sufficiently low value (where "value" may be interpreted
in any useful way by the network operator) that any other traffic
should take precedence over this traffic in consumption of network
link bandwidth. There may or may not be memory (buffer) resources
allocated for this type of traffic.

Some networks carry traffic for which delivery is considered optional;
that is, packets of this type of traffic ought to consume network
resources only when no other traffic is present. Alternatively,
the effect of this type of traffic on all other network traffic
is strictly limited. This is distinct from "best-effort" traffic
since the network makes no committment to delivering these packets
while, in the best-effort case, an implied "good faith" committment
that there are at least some network resources available is assumed.
This document proposes a Bulk Handling Differentiated Dervices
per-domain behavior [PDBDEF] for handling this "optional" traffic
in a differentiated services domain.

The name, "bulk handling" is loosely based on the United States
Postal Service's Bulk Handling deliver for mail: a lower-cost delivery
where the items are not handled with the same care or delivered
with the same timeliness as items with first-class postage. There
is no intrinsic reason to limit the applicability of the BH PDB
to any particular application or type of traffic. It is intended
as an additional tool for administrators in engineering networks.

Note: where not otherwise defined, terminology used in this document
is defined in [RFC2474].

2 Applicability

A Bulk Handling (BH) PDB is for sending extremely non-critical traffic
across a DS domain or DS region. There should be an expectation
that packets of the BH PDB may be delayed or dropped when any other
traffic is present. Its use might assist a network operator in
moving certain kinds of traffic or users to off-peak times.
Alternatively, or in addition, packets can be designated for the BH PDB
where the goal is to protect all other packet traffic from competition
with the BH aggregate while not completely banning BH traffic from
the network. A BH PDB should not be used for a customer's "normal
internet" traffic nor for packets that ought to simply be dropped
as unauthorized. The BH PDB is expected to have applicability in
networks that have at least some unused capacity at some times
of day.

This is a PDB that allows for protecting networks from some types
of traffic rather than giving a traffic aggregate preferential

3 Technical Specification

 Classification and Traffic Conditioning

There are no required traffic profiles governing rate and bursts
of packets beyond the limits imposed by the ingress link. It is
not necessary to limit the BH aggregate using edge techniques since
its PHB is to be configured such that packets of the aggregate
will be dropped in the network if no forwarding resources are available.
The Differentiated Services Architecture [RFC2475] allows packets
to be marked upstream of the DS domain or at the DS domain's edge.
When packets arrive pre-marked with the DSCP used by the BH PDB,
it should not be necessary for the DS domain boundary to police
that marking; further (MF) classification for such packets would
only be required if there was some reason to suspect the packets
should be marked with some other DSCP.

If there is not an agreement on DSCP marking with the upstream domain,
when a DS domain is using the BH PDB, the boundary must include
a classifier that selects the appropriate BH target group of packets
out of all arriving packets and steers them to a marker which sets
the appropriate DSCP. No other traffic conditioning is required.

 PHB configuration

Either a Class Selector (CS) PHB [RFC2474], an Experimental/ Local
Use (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597]
may be used as the PHB for the BH traffic aggregate. This document
does not specify the exact DSCP to use inside a domain, but instead
specifies the necessary properties of the PHB selected by the DSCP.
If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested.

The PHB used by the BH aggregate inside a DS domain should be configured
so that its packets are forwarded onto the node output link when
the link would otherwise be idle; conceptually, the behavior of
a weighted round-robin scheduler with a weight of zero. An operator
might choose to configure a very small link share for the BH aggregate
and still achieve the desired goals. That is, if the output link
scheduler permits, a small fixed rate might be assigned to the
PHB, but the behavior beyond that configured rate should be that
packets are forwarded only when the link would otherwise be idle.
This behavior could be obtained, for example, by using a CBQ [CBQ]
scheduler with a small share and with borrowing permited. A PHB
that allows packets of the BH aggregate to send more than the configured
rate when packets of other traffic aggregates are waiting for the
link is not recommended.

If a CS PHB is used, note that this configuration will violate the
"SHOULD" of section of RFC 2474 [RFC2474] since CS1 will
have a less timely forwarding than CS0. An operator's goal of providing
a BH PDB provides a sufficient cause for violating the SHOULD.
If an AF PHB is used, it must be configured and a DSCP assigned
such that it does not violate the "MUST" of paragraph three of
section 2 of RFC 2597 [RFC2597] which provides for a "minimum amount
of forwarding resources".

4 Attributes

There are no quantifiable attributes of the PDB. The ingress and
egress flow of the BH aggregate can be measured but there are no
absolute or statistical metrics that arise from the PDB definition,
though a particular network operator may configure the DS domain
in such a way that a statistical metric can be associated with
that DS domain. When the DS domain is known to be heavily congested
with traffic of other PDBs, a network operator should expect to
see no (or very few) packets of the BH PDB egress from the domain.
When there is no other traffic present, the proportion of the BH
aggregate that successfully crosses the domain should be limited
only by the capacity of the network relative to the ingress BH
traffic aggregate.

5 Parameters

None required.

6 Assumptions

A properly functioning network.

7 Example uses

1. Multimedia applications [this example edited from Yoram Bernet]:

Many network managers want to protect their networks from certain
applications, in particular, from multimedia applications that
typically use such non-adaptive protocols as UDP.

Most of the focus in quality-of-service is on achieving attributes
that are better than Best Effort. These approaches can provide
network managers with the ability to control the amount of multimedia
traffic that is given this improved performance with excess relegated
to Best Effort. This excess traffic can wreak havoc with network
resources even when it is relegated to Best Effort because it is
non-adaptive and because it can be significant in volume and duration.
These characteristics permit it to sieze network resources, thereby
compromising the performance of other, more important applications
that are included in the Best Effort traffic aggregate but that
use adaptive protocols (e.g., TCP). As a result, network managers
often simply refuse to allow multimedia applications to be deployed
in resource constrained parts of their network.

The BH PDB enables a network manager to allow the deployment of
multimedia applications without losing control of network resources.
A limited amount of multimedia traffic may (or may not) be assigned
to PDBs with attributes that are better than Best Effort. Excess
multimedia traffic can be prevented from wreaking havoc with network
resources by forcing it to the BH PDB.

2. For Netnews and other "bulk mail" of the Internet.

3. For "downgraded" traffic from some other PDB.

4. For content distribution, Napster traffic, and the like.

8 Experiences

The authors solicit experiences for this section.

9 Security Considerations for BH PDB

There are no specific security exposures for this PDB. See the general
security considerations in [RFC2474] and [RFC2475].

10 Acknowledgments

The notion of having something "lower than Best Effort" was raised
in the Diffserv Working Group, most notably by Roland Bless and
Klaus Wehrle in their Internet Draft [LBE] and by Yoram Bernet
for enterprise multimedia applications. Previous discussion centered
on the creation of a new PHB which the authors believe is not required.
This document was specifically written to explain how to get less
than Best Effort without a new PHB.

Yoram Bernet contributed significant text for the "Examples" section
of this document and other useful comments that helped in editing.
Other Diffserv WG members suggested that the BH PDB is needed for
Napster traffic, particularly at universities.


[PDBDEF] "Definition of Differentiated Services Per-Domain Behaviors
and Rules for their Specification", K. Nichols, B. Carpenter,

[RFC2474] RFC 2474, "Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers", K.Nichols, S. Blake,
F. Baker, D. Black, www.ietf.org/rfc/rfc2474.txt

[RFC2475] RFC 2475, "An Architecture for Differentiated Services",
S. Blake, D. Black, M.Carlson, E.Davies, Z.Wang,W.Weiss,

[RFC2597] RFC 2597, "Assured Forwarding PHB Group", F. Baker, J.
Heinanen, W. Weiss, J. Wroclawski, www.ietf.org/rfc/rfc2597.txt

[CBQ] S. Floyd and V. Jacobson, Link-sharing and Resource Management
Models for Packet Networks, IEEE/ACM Transactions on Networking,
Vol. 3 No. 4, pp. 365-386, August 1995

[LBE] "A Lower Than Best-Effort Per-Hop Behavior",
draft-bless-diffserv-phb-lbe-00.txt, R. Bless and K. Wehrle, 1999,
(work in progress).

Authors' Addresses

 Brian Carpenter                 Kathleen Nichols
 IBM                             Packet Design
 c/o iCAIR                       66 Willow Place
 Suite 150                       Menlo Park, CA 94025
 1890 Maple Avenue               USA
 Evanston, IL 60201
 email: brian@icair.org          email: nichols@packetdesign.com