Internet DRAFT - draft-tsvwg-le-phb
draft-tsvwg-le-phb
Internet Engineering Task Force R. Bless
Internet-Draft Karlsruhe Institute of Technology (KIT)
Updates: 3662,4594 (if approved) October 21, 2016
Intended status: Standards Track
Expires: April 24, 2017
A Lower Effort Per-Hop Behavior (LE PHB)
draft-tsvwg-le-phb-00
Abstract
This document specifies properties and characteristics of a Lower
Effort (LE) per-hop behavior (PHB). The primary objective of this LE
PHB is to protect best-effort (BE) traffic (packets forwarded with
the default PHB) from LE traffic in congestion situations, i.e., when
resources become scarce, best-effort traffic has precedence over LE
traffic and may preempt it. There are numerous uses for this PHB,
e.g., for background traffic of low precedence, such as bulk data
transfers with low priority in time, non time-critical backups,
larger software updates, web search engines while gathering
information from web servers and so on. This document recommends a
standard DSCP value for the LE PHB.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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 Internet-Draft will expire on April 24, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Bless Expires April 24, 2017 [Page 1]
Internet-Draft Lower Effort PHB October 2016
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Deployment Considerations . . . . . . . . . . . . . . . . 4
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 4
3. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 5
4. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 5
5. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 7
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This document defines a Differentiated Services per-hop behavior
RFC 2474 [RFC2474] called "Lower Effort" (LE) which is intended for
traffic of sufficiently low urgency, in which all other traffic takes
precedence over LE traffic in consumption of network link bandwidth.
Low urgency traffic has got a low priority in time, which does not
necessarily imply that it is generally of minor importance. From
this viewpoint, it can be considered as a network equivalent to a
background priority for processes in an operating system. 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" (BE) traffic since the network makes no commitment to deliver
LE packets. In contrast, BE traffic receives an implied "good faith"
commitment of at least some available network resources. This
Bless Expires April 24, 2017 [Page 2]
Internet-Draft Lower Effort PHB October 2016
document proposes a Lower Effort Differentiated Services per-hop
behavior (LE PHB) for handling this "optional" traffic in a
differentiated services node.
1.1. Applicability
A Lower Effort PHB is for sending extremely non-critical traffic
across a Differentiated Services (DS) domain or DS region. There
should be an expectation that packets of the LE PHB may be delayed or
dropped when any other traffic is present. Use of the LE PHB 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 LE PHB when the goal is to protect all other
packet traffic from competition with the LE aggregate while not
completely banning LE traffic from the network. An LE PHB should not
be used for a customer's "normal internet" traffic nor should packets
be "downgraded" to the LE PHB used as a substitute for dropping
packets that ought simply to be dropped as unauthorized. The LE PHB
is expected to have applicability in networks that have at least some
unused capacity at some times of day.
This is a PHB that allows networks to protect themselves from
selected types of traffic rather than giving a selected traffic
aggregate preferential treatment. Moreover, it may also exploit all
unused resources from other PHBs.
There is no intrinsic reason to limit the applicability of the LE PHB
to any particular application or type of traffic. It is intended as
an additional tool for administrators in engineering networks. For
instance, it can be used for filling up protection capacity of
transmission links which is otherwise unused. Some network providers
keep link utilization below 50% in order to being able carrying all
traffic without loss in case of rerouting due to a link failure. LE
marked traffic can utilize the normally unused capacity and will be
preempted automatically in case of link failure when 100% of the link
capacity is required for all other traffic. Ideally, applications
mark their packets as LE traffic, since they know the urgency of
flows.
Example uses for the LE PHB comprise:
o For traffic caused by world-wide web search engines while they
gather information from web servers.
o For software updates or dissemination of new releases of operating
systems.
Bless Expires April 24, 2017 [Page 3]
Internet-Draft Lower Effort PHB October 2016
o For backup traffic or non-time critical sychronization or
mirroring traffic.
o For content distribution transfers between caches.
o For Netnews and other "bulk mail" of the Internet.
o For "downgraded" traffic from some other PHB when this does not
violate the operational objectives of the other PHB or the overall
network. LE should not be used for the general case of downgraded
traffic, but may be used by design, e.g., to protect an internal
network from untrusted external traffic sources. In this case
there is no way for attackers to preempt internal (non LE) traffic
by flooding. Another use case is mentioned in [RFC3754]: non-
admitted multicast traffic.
1.2. Deployment Considerations
Internet-wide deployment of the LE PHB is eased by the following
properties:
o No harm to other traffic: since the LE PHB has got the lowest
priority it does not take resources from other PHBs. Deployment
across different provider domains causes no trust issues or attack
vectors to existing traffic.
o No parameters or configuration: the LE PHB requires no parameters
and no configuration of traffic profiles and so on.
o No traffic conditioning mechanisms: the LE PHB requires only a
queue and a scheduling mechanism, but no traffic meters, droppers
or shapers.
Since LE traffic may be starved completely for a longer period of
time, transport protocols or applications should be able to detect
such a situation and should resume the transfer as soon as possible.
1.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. PHB Description
This PHB is defined in relation to the default PHB (best-effort). A
packet forwarded with this PHB SHOULD have lower precedence than
packets forwarded with the default PHB. Ideally, LE packets should
Bless Expires April 24, 2017 [Page 4]
Internet-Draft Lower Effort PHB October 2016
be forwarded only if no best-effort packet is waiting for its
transmission. A straightforward implementation could be a simple
priority scheduler serving the default PHB queue with higher priority
than the lower-effort PHB queue. Alternative implementations may use
scheduling algorithms that assign a very small weight to the LE
class. This, however, may sometimes cause better service for LE
packets compared to BE packets in cases when the BE share is fully
utilized and the LE share not.
3. Traffic Conditioning Actions
As for most other PHBs an initial classification and marking would
usually be performed at the first DS boundary node. In many cases,
packets may also be pre-marked in DS aware end systems by
applications due to their specific knowledge about the particular
precedence of packets. There is no incentive for DS domains to
distrust this initial marking, because letting LE traffic enter a DS
domain causes no harm. In the worst case it evokes the same effect
as it would have been marked with the default PHB, i.e., as best-
effort traffic. Thus, any policing such as limiting the traffic rate
is not necessary at the DS boundary.
Usually, the amount of LE traffic is implicitly limited by queueing
mechanisms and related discard actions of the PHB. Therefore, there
is normally no need to meter and police LE traffic explicitly.
4. Recommended DS Codepoint
The recommended codepoint for the LE PHB is 000010.
RFC 4594 [RFC4594] recommended to use CS1 as codepoint (as mentioned
in [RFC3662]. This is problematic since it may cause a priority
inversion resulting in treating LE packets with higher precedence
than BE packets. Existing implementations SHOULD therefore use the
unambiguous LE codepoint 000010 whenever possible.
5. Remarking to other DSCPs/PHBs
"DSCP bleaching", i.e., setting the DSCP to 000000 (default PHB) is
not recommended for this PHB. This may cause effects that are in
contrast to the original intent in protecting BE traffic from LE
traffic. In case DS domains do not support the LE PHB, they may
treat LE marked packets with the default PHB instead, but they should
do so without remarking to the DSCP 000000. The reason for this is
that later traversed DS domains may then have still the possibility
to treat such packets according the LE PHB.
Bless Expires April 24, 2017 [Page 5]
Internet-Draft Lower Effort PHB October 2016
6. IANA Considerations
This memo includes a request to assign a Differentiated Services
Field Codepoint (DSCP) 000010 from the Differentiated Services Field
Codepoints (DSCP) registry https://www.iana.org/assignments/dscp-
registry/dscp-registry.xml
7. Security Considerations
There are no specific security exposures for this PHB. Since it
defines a new class of low forwarding priority, other traffic may be
downgraded to this LE PHB in case it is remarked as LE traffic. See
the general security considerations in RFC 2474 [RFC2474] and RFC
2475 [RFC2475].
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>.
8.2. Informative References
[draft-bless-diffserv-lbe-phb-00]
Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop
Behavior", draft-bless-diffserv-lbe-phb-00 (work in
progress), September 1999, <https://tools.ietf.org/html/
draft-bless-diffserv-lbe-phb-00>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003,
<http://www.rfc-editor.org/info/rfc3662>.
Bless Expires April 24, 2017 [Page 6]
Internet-Draft Lower Effort PHB October 2016
[RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated
Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754,
April 2004, <http://www.rfc-editor.org/info/rfc3754>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>.
Appendix A. History of the LE PHB
A first version of this PHB was suggested by Roland Bless and Klaus
Wehrle in 1999 [draft-bless-diffserv-lbe-phb-00]. After some
discussion in the DiffServ Working Group Brian Carpenter and Kathie
Nichols proposed a bulk handling per-domain behavior and believed a
PHB was not necessary. Eventually, Lower Effort was specified as
per-domain behavior and finally became [RFC3662]. More detailed
information about its history can be found in Section 10 of
[RFC3662].
Appendix B. Acknowledgments
Since text is borrowed from earlier Internet-Drafts and RFCs the co-
authors of previous specifications are acknowledged here: Kathie
Nichols and Klaus Wehrle.
Author's Address
Roland Bless
Karlsruhe Institute of Technology (KIT)
Kaiserstr. 12
Karlsruhe 76131
Germany
Phone: +49 721 608 46413
Email: roland.bless@kit.edu
Bless Expires April 24, 2017 [Page 7]
