draft-ietf-diffserv-pdb-bh-00.txt   draft-ietf-diffserv-pdb-bh-01.txt 
Internet Engineering Task Force B. Carpenter Internet Engineering Task Force B. Carpenter
Differentiated Services Working Group IBM Differentiated Services Working Group IBM
Internet Draft K. Nichols Internet Draft K. Nichols
Expires in April, 2001 Packet Design Expires in June, 2001 Packet Design
A Bulk Handling Per-Domain Behavior for Differentiated Services A Bulk Handling Per-Domain Behavior for Differentiated Services
<draft-ietf-diffserv-pdb-bh-00> <draft-ietf-diffserv-pdb-bh-01>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This document is a product of the Diffserv working group. Comments This document is a product of the Diffserv working group. Comments
on this draft should be directed to the Diffserv mailing list on this draft should be directed to the Diffserv mailing list
<diffserv@ietf.org>. The list of current Internet-Drafts can be <diffserv@ietf.org>. The list of current Internet-Drafts can be accessed
accessed at www.ietf.org/ietf/1id-abstracts.txt. The list of at www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft
Internet-Draft Shadow Directories can be accessed at Shadow Directories can be accessed at www.ietf.org/shadow.html.
www.ietf.org/shadow.html. Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
This document proposes a differentiated services per-domain behavior This document proposes a differentiated services per-domain behavior
in which it is possible, in a properly functioning network, for whose traffic may be "starved" (although starvation is not strictly
traffic of this PDB to be "starved". This is in contrast to the required) in a properly functioning network. This is in contrast
Internet's "best-effort" or "normal Internet traffic" model. 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 1 Description of the Bulk Handling PDB
This document proposes a differentiated services per-domain This document proposes a differentiated services per-domain behavior
behavior [PDBDEF] called bulk handling (BH) which makes it possible [PDBDEF] called bulk handling (BH) which makes it possible to admit
to admit traffic of sufficiently low value (where "value" traffic of sufficiently low value (where "value" may be interpreted
may be interpreted in any useful way by the network operator) that in any useful way by the network operator) that any other traffic
any other traffic should take precedence over this traffic in should take precedence over this traffic in consumption of network
consumption of network link bandwidth. There may or may not be memory link bandwidth. There may or may not be memory (buffer) resources
(buffer) resources allocated for this type of traffic. allocated for this type of traffic.
In some networks, there are types of traffic which are considered Some networks carry traffic for which delivery is considered optional;
"optional"; that is, packets of these types ought to consume network that is, packets of this type of traffic ought to consume network
resources only when no other traffic is present. This traffic type resources only when no other traffic is present. Alternatively,
is considered to be distinct from "best-effort" traffic since the the effect of this type of traffic on all other network traffic
network makes no committment to delivering the packets while in is strictly limited. This is distinct from "best-effort" traffic
the best-effort case, there is assumed to be an implied "good faith" since the network makes no committment to delivering these packets
committment that there are at least some network resources available while, in the best-effort case, an implied "good faith" committment
for this traffic. This document proposes a bulk handling differentiated that there are at least some network resources available is assumed.
services per-domain behavior to implement this "optional" This document proposes a Bulk Handling Differentiated Dervices
traffic service in a differentiated services domain. 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 2 Applicability
A Bulk Handling (BH) PDB is for sending extremely non-critical traffic A Bulk Handling (BH) PDB is for sending extremely non-critical traffic
across a diffserv network. There should be the expectation that across a DS domain or DS region. There should be an expectation
these packets may be delayed or dropped when any other traffic that packets of the BH PDB may be delayed or dropped when any other
is present. Its use might assist a network operator in moving certain traffic is present. Its use might assist a network operator in
kinds of traffic or users to off-peak times. Alternatively, or moving certain kinds of traffic or users to off-peak times.
in addition, packets can be designated for the BH PDB where the Alternatively, or in addition, packets can be designated for the BH PDB
goal is to protect all other packet traffic from competition with where the goal is to protect all other packet traffic from competition
the BH aggregate while not completely banning BH traffic from the with the BH aggregate while not completely banning BH traffic from
network. A BH PDB should not be used for a customer's "normal internet" the network. A BH PDB should not be used for a customer's "normal
traffic nor for packets that ought to simply be dropped as unauthorized. internet" traffic nor for packets that ought to simply be dropped
The BH PDB would not be usefully depolyed in a network which is as unauthorized. The BH PDB is expected to have applicability in
congested with non-BH traffic as this indicates no link resources networks that have at least some unused capacity at some times
to spare. of day.
3 Rules This is a PDB that allows for protecting networks from some types
of traffic rather than giving a traffic aggregate preferential
treatment.
3.1 Edge rules 3 Technical Specification
There are no rules governing rate and bursts of packets beyond the Classification and Traffic Conditioning
limits imposed by the ingress link. The network edge must include
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 a classifier that selects the appropriate BH target group of packets
out of all arriving packets and steers them to a marker which sets out of all arriving packets and steers them to a marker which sets
the appropriate DSCP to select a PHB configured as described in the appropriate DSCP. No other traffic conditioning is required.
the next section. No other traffic conditioning is required.
3.2 PHB configuration PHB configuration
Either a Class Selector (CS) PHB [RFC2474], an Experimental/ Either a Class Selector (CS) PHB [RFC2474], an Experimental/ Local
Local Use (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB Use (EXP/LU) PHB [RFC2474], or an Assured Forwarding (AF) PHB [RFC2597]
[RFC2597] may be used as the PHB for the BH traffic aggregate. This may be used as the PHB for the BH traffic aggregate. This document
document does not specify the exact DSCP to use inside a domain, but does not specify the exact DSCP to use inside a domain, but instead
instead specifies the necessary properties of the PHB selected by the specifies the necessary properties of the PHB selected by the DSCP.
DSCP. If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested. If a CS PHB is used, Class Selector 1 (DSCP=001000) is suggested.
The PHB used by the BH aggregate inside a DS domain must be configured The PHB used by the BH aggregate inside a DS domain should be configured
so that its behavior is that its packets are forwarded onto the so that its packets are forwarded onto the node output link when
node output link when the link would otherwise be idle. If the the link would otherwise be idle; conceptually, the behavior of
DS node uses a scheduler that is not capable of this strict starvation, a weighted round-robin scheduler with a weight of zero. An operator
an operator might choose to configure a very small link share for might choose to configure a very small link share for the BH aggregate
the BH aggregate and still acheive the desired goals. It is unlikely and still achieve the desired goals. That is, if the output link
that a "fair sharing" scheduler would be configurable to yield scheduler permits, a small fixed rate might be assigned to the
the required PHB. 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 If a CS PHB is used, note that this configuration will violate the
"SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will "SHOULD" of section 4.2.2.2 of RFC 2474 [RFC2474] since CS1 will
have a less timely forwarding than CS0. An operator's goal of providing have a less timely forwarding than CS0. An operator's goal of providing
a BH PDB provides a sufficient cause for violating the SHOULD. 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 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 such that it does not violate the "MUST" of paragraph three of
section 2 of RFC 2597 [RFC2597] which provides for a "minimum amount section 2 of RFC 2597 [RFC2597] which provides for a "minimum amount
of forwarding resources". of forwarding resources".
4 Attributes of the BH PDB 4 Attributes
There are no quantifiable attributes of the PDB. The ingress and There are no quantifiable attributes of the PDB. The ingress and
egress flow of the BH aggregate can be measured but there are no egress flow of the BH aggregate can be measured but there are no
absolute or statistical metrics that arise from the PDB definition, absolute or statistical metrics that arise from the PDB definition,
though a particular network operator may configure the DS domain though a particular network operator may configure the DS domain
in such a way that a statistical metric can be associated with 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 that DS domain. When the DS domain is known to be heavily congested
with traffic of other PDBs, a network operator should expect to 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. 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 When there is no other traffic present, the proportion of the BH
skipping to change at line 141 skipping to change at line 179
5 Parameters 5 Parameters
None required. None required.
6 Assumptions 6 Assumptions
A properly functioning network. A properly functioning network.
7 Example uses 7 Example uses
1. For Netnews and other "bulk mail" of the Internet. 1. Multimedia applications [this example edited from Yoram Bernet]:
2. For "downgraded" traffic from some other PDB. 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 8 Experiences
The authors solicit experiences for this section.
9 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 "Applications"
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.
References References
[PDBDEF] "Definition of Differentiated Services Per-Domain Behaviors [PDBDEF] "Definition of Differentiated Services Per-Domain Behaviors
and Rules for their Specification", K. Nichols, B. Carpenter, and Rules for their Specification", K. Nichols, B. Carpenter,
draft-ietf-diffserv-pdb-def-01.txt draft-ietf-diffserv-pdb-def-02.txt
[RFC2474] RFC 2474, "Definition of the Differentiated Services Field [RFC2474] RFC 2474, "Definition of the Differentiated Services Field
(DS Field) in the IPv4 and IPv6 Headers", K.Nichols, S. Blake, (DS Field) in the IPv4 and IPv6 Headers", K.Nichols, S. Blake,
F. Baker, D. Black, www.ietf.org/rfc/rfc2474.txt 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,
www.ietf.org/rfc/rfc2475.txt
[RFC2597] RFC 2597, "Assured Forwarding PHB Group", F. Baker, J. [RFC2597] RFC 2597, "Assured Forwarding PHB Group", F. Baker, J.
Heinanen, W. Weiss, J. Wroclawski, www.ietf.org/rfc/rfc2597.txt 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,
(work in progress)
Authors' Addresses Authors' Addresses
Brian Carpenter Kathleen Nichols Brian Carpenter Kathleen Nichols
IBM Packet Design, Inc. IBM Packet Design, Inc.
c/o ICAIR 66 Willow Place c/o ICAIR 66 Willow Place
Suite 150 Menlo Park, CA 94025 Suite 150 Menlo Park, CA 94025
1890 Maple Avenue USA 1890 Maple Avenue USA
Evanston, IL 60201 Evanston, IL 60201
USA USA
email: brian@icair.org email: nichols@packetdesign.com email: brian@icair.org email: nichols@packetdesign.com
 End of changes. 21 change blocks. 
63 lines changed or deleted 159 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/