draft-ietf-tsvwg-le-phb-05.txt   draft-ietf-tsvwg-le-phb-06.txt 
Internet Engineering Task Force R. Bless Internet Engineering Task Force R. Bless
Internet-Draft Karlsruhe Institute of Technology (KIT) Internet-Draft Karlsruhe Institute of Technology (KIT)
Obsoletes: 3662 (if approved) July 3, 2018 Obsoletes: 3662 (if approved) October 11, 2018
Updates: 4594,8325 (if approved) Updates: 4594,8325 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 4, 2019 Expires: April 14, 2019
A Lower Effort Per-Hop Behavior (LE PHB) A Lower Effort Per-Hop Behavior (LE PHB)
draft-ietf-tsvwg-le-phb-05 draft-ietf-tsvwg-le-phb-06
Abstract Abstract
This document specifies properties and characteristics of a Lower This document specifies properties and characteristics of a Lower
Effort (LE) per-hop behavior (PHB). The primary objective of this LE Effort (LE) per-hop behavior (PHB). The primary objective of this LE
PHB is to protect best-effort (BE) traffic (packets forwarded with PHB is to protect best-effort (BE) traffic (packets forwarded with
the default PHB) from LE traffic in congestion situations, i.e., when the default PHB) from LE traffic in congestion situations, i.e., when
resources become scarce, best-effort traffic has precedence over LE resources become scarce, best-effort traffic has precedence over LE
traffic and may preempt it. Alternatively, packets forwarded by the traffic and may preempt it. Alternatively, packets forwarded by the
LE PHB can be associated with a scavenger service class, i.e., they LE PHB can be associated with a scavenger service class, i.e., they
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
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 any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference 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 Internet-Draft will expire on January 4, 2019. This Internet-Draft will expire on April 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
4. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 5 4. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 5
5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 6 5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 6
6. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 6 6. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 6
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
8. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 8 8. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 8
9. The Update to RFC 4594 . . . . . . . . . . . . . . . . . . . 8 9. Multicast Considerations . . . . . . . . . . . . . . . . . . 9
10. The Update to RFC 8325 . . . . . . . . . . . . . . . . . . . 10 10. The Update to RFC 4594 . . . . . . . . . . . . . . . . . . . 10
11. The Update to draft-ietf-tsvwg-rtcweb-qos . . . . . . . . . . 10 11. The Update to RFC 8325 . . . . . . . . . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12. The Update to draft-ietf-tsvwg-rtcweb-qos . . . . . . . . . . 12
13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . 12 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . 13 15.1. Normative References . . . . . . . . . . . . . . . . . . 14
Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 15 15.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 17
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 15 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 17
Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 17 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document defines a Differentiated Services per-hop behavior This document defines a Differentiated Services per-hop behavior
[RFC2474] called "Lower Effort" (LE), which is intended for traffic [RFC2474] called "Lower Effort" (LE), which is intended for traffic
of sufficiently low urgency that all other traffic takes precedence of sufficiently low urgency that all other traffic takes precedence
over the LE traffic in consumption of network link bandwidth. Low over the LE traffic in consumption of network link bandwidth. Low
urgency traffic has a low priority for timely forwarding, which does urgency traffic has a low priority for timely forwarding, which does
not necessarily imply that it is generally of minor importance. From not necessarily imply that it is generally of minor importance. From
this viewpoint, it can be considered as a network equivalent to a this viewpoint, it can be considered as a network equivalent to a
background priority for processes in an operating system. There may background priority for processes in an operating system. There may
or may not be memory (buffer) resources allocated for this type of or may not be memory (buffer) resources allocated for this type of
traffic. traffic.
Some networks carry traffic for which delivery is considered Some networks carry traffic for which delivery is considered
optional; that is, packets of this type of traffic ought to consume optional; that is, packets of this type of traffic ought to consume
network resources only when no other traffic is present. In this network resources only when no other traffic is present. In this
point of view, packets forwarded by the LE PHB scavenge otherwise point of view, packets forwarded by the LE PHB scavenge otherwise
unused resources only, which led to the name "scavenger service" in unused resources only, which led to the name "scavenger service" in
early Internet2 deployments (Appendix A). Other commonly used names early Internet2 deployments (see Appendix A). Other commonly used
for LE PHB type services are "Lower-than-best-effort" or "Less-than- names for LE PHB type services are "Lower-than-best-effort" or "Less-
best-effort". Alternatively, the effect of this type of traffic on than-best-effort". Alternatively, the effect of this type of traffic
all other network traffic is strictly limited ("no harm" property). on all other network traffic is strictly limited ("no harm"
This is distinct from "best-effort" (BE) traffic since the network property). This is distinct from "best-effort" (BE) traffic since
makes no commitment to deliver LE packets. In contrast, BE traffic the network makes no commitment to deliver LE packets. In contrast,
receives an implied "good faith" commitment of at least some BE traffic receives an implied "good faith" commitment of at least
available network resources. This document proposes a Lower Effort some available network resources. This document proposes a Lower
Differentiated Services per-hop behavior (LE PHB) for handling this Effort Differentiated Services per-hop behavior (LE PHB) for handling
"optional" traffic in a differentiated services node. this "optional" traffic in a differentiated services node.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Applicability 3. Applicability
skipping to change at page 8, line 46 skipping to change at page 9, line 5
e.g., LEDBAT [RFC6817]. e.g., LEDBAT [RFC6817].
A DS domain that still uses DSCP CS1 for marking LE traffic A DS domain that still uses DSCP CS1 for marking LE traffic
(including Low Priority-Data as defined in [RFC4594] or the old (including Low Priority-Data as defined in [RFC4594] or the old
definition in [RFC3662]) SHOULD remark traffic to the LE DSCP definition in [RFC3662]) SHOULD remark traffic to the LE DSCP
'000001' at the egress to the next DS domain. This increases the '000001' at the egress to the next DS domain. This increases the
probability that the DSCP is preserved end-to-end, whereas a CS1 probability that the DSCP is preserved end-to-end, whereas a CS1
marked packet may be remarked by the default DSCP if the next domain marked packet may be remarked by the default DSCP if the next domain
is applying DiffServ-intercon [RFC8100]. is applying DiffServ-intercon [RFC8100].
9. The Update to RFC 4594 9. Multicast Considerations
Basically the multicast considerations in [RFC3754] apply. However,
using the Lower Effort PHB for multicast requires to pay special
attention to the way how packets get replicated inside routers. Due
to multicast packet replication, resource contention may actually
occur even before a packet is forwarded to its output port and in the
worst case, these forwarding resources are missing for higher
prioritized multicast or even unicast packets.
Several forwarding error correction coding schemes such as fountain
codes (e.g., [RFC5053]) allow reliable data delivery even in
environments with a potential high amount of packet loss in
transmission. When used for example over satellite links or other
broadcast media, this means that receivers that loose 80% of packets
in transmission simply need 5 times as long to receive the complete
data than those receivers experiencing no loss (without any receiver
feedback required).
Superficially viewed, it may sound very attractive to use IP
multicast with the LE PHB to build this type of opportunistic
reliable distribution in IP networks, but it can only be usefully
deployed with routers that do not experience forwarding/replication
resource starvation when a large amount of packets (virtually) need
to be replicated to links where the LE queue is full.
Thus, packet replication of LE marked packets should consider the
situation at the respective output links: it is a waste of internal
forwarding resources if a packet is replicated to output links that
have no resources left for LE forwarding. In those cases a packet
would have been replicated just to be dropped immediately after
finding a filled LE queue at the respective output port. Such
behavior could be avoided for example by using a conditional internal
packet replication: a packet would then only be replicated in case
the output link is not fully used. This conditional replication,
however, is probably not widely implemented.
While the resource contention problem caused by multicast packet
replication is also true for other DiffServ PHBs, LE forwarding is
special, because often it is assumed that LE packets get only
forwarded in case of available resources at the output ports. The
previously mentioned redundancy data traffic could nicely use the
varying available residual bandwidth being utilized the by LE PHB,
but only if the previously specific requirements in the internal
implementation of the network devices are considered.
10. The Update to RFC 4594
[RFC4594] recommended to use CS1 as codepoint in section 4.10, [RFC4594] recommended to use CS1 as codepoint in section 4.10,
whereas CS1 was defined in [RFC2474] to have a higher precedence than whereas CS1 was defined in [RFC2474] to have a higher precedence than
CS0, i.e., the default PHB. Consequently, DiffServ domains CS0, i.e., the default PHB. Consequently, DiffServ domains
implementing CS1 according to [RFC2474] will cause a priority implementing CS1 according to [RFC2474] will cause a priority
inversion for LE packets that contradicts with the original purpose inversion for LE packets that contradicts with the original purpose
of LE. Therefore, every occurrence of the CS1 DSCP is replaced by of LE. Therefore, every occurrence of the CS1 DSCP is replaced by
the LE DSCP. the LE DSCP.
Changes: Changes:
skipping to change at page 9, line 23 skipping to change at page 10, line 31
| Data | | | assurance | | Data | | | assurance |
------------------------------------------------------------------ ------------------------------------------------------------------
and replaces this by the following entry: and replaces this by the following entry:
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Low-Priority | LE | 000001 | Any flow that has no BW | | Low-Priority | LE | 000001 | Any flow that has no BW |
| Data | | | assurance | | Data | | | assurance |
------------------------------------------------------------------ ------------------------------------------------------------------
o This update to RFC 4594 extends the Notes text below figure 3 that
currently states "Notes for Figure 3: Default Forwarding (DF) and
Class Selector 0 (CS0) provide equivalent behavior and use the
same DS codepoint, '000000'." to state "Notes for Figure 3:
Default Forwarding (DF) and Class Selector 0 (CS0) provide
equivalent behavior and use the same DS codepoint, '000000'. The
prior recommendation to use the CS1 DSCP for Low-Priority Data has
been replaced by the current recommendation to use the LE DSCP,
'000001'."
o This update to RFC 4594 removes the following entry from figure 4: o This update to RFC 4594 removes the following entry from figure 4:
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes| | Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | | | Data | | | | | |
------------------------------------------------------------------ ------------------------------------------------------------------
and replaces this by the following entry: and replaces this by the following entry:
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
skipping to change at page 9, line 49 skipping to change at page 11, line 22
supported, High-Throughput Data or Low-Priority Data. We supported, High-Throughput Data or Low-Priority Data. We
RECOMMEND that the DSCP value(s) of the unsupported service class RECOMMEND that the DSCP value(s) of the unsupported service class
be changed to 000xx1 on ingress and changed back to original be changed to 000xx1 on ingress and changed back to original
value(s) on egress of the network segment that uses precedence value(s) on egress of the network segment that uses precedence
marking. For example, if Low-Priority Data is mapped to Standard marking. For example, if Low-Priority Data is mapped to Standard
service class, then 000001 DSCP marking MAY be used to distinguish service class, then 000001 DSCP marking MAY be used to distinguish
it from Standard marked packets on egress." This document removes it from Standard marked packets on egress." This document removes
this recommendation, because by using the herein defined LE DSCP this recommendation, because by using the herein defined LE DSCP
such remarking is not necessary. So even if Low-Priority Data is such remarking is not necessary. So even if Low-Priority Data is
unsupported (i.e., mapped to the default PHB) the LE DSCP should unsupported (i.e., mapped to the default PHB) the LE DSCP should
be kept across the domain as RECOMMENDED in Section 8. be kept across the domain as RECOMMENDED in Section 8. That
removed text is replaced by: "In network segments that use IP
Precedence marking, the Low-Priority Data service class receives
the same Diffserv QoS as the Standard service class when the LE
DSCP is used for Low-Priority Data traffic. This is acceptable
behavior for the Low-Priority Data service class, although it is
not the preferred behavior."
o This document removes the following line of RFC 4594, o This document removes the following line of RFC 4594,
Section 4.10: "The RECOMMENDED DSCP marking is CS1 (Class Selector Section 4.10: "The RECOMMENDED DSCP marking is CS1 (Class Selector
1)." and replaces this with the following text: "The RECOMMENDED 1)." and replaces this with the following text: "The RECOMMENDED
DSCP marking is LE (Lower Effort)." DSCP marking is LE (Lower Effort), which replaces the prior
recommendation for CS1 (Class Selector 1) marking."
10. The Update to RFC 8325 11. The Update to RFC 8325
Section 4.2.10 of RFC 8325 [RFC8325] specifies "[RFC3662] and
[RFC4594] both recommend Low-Priority Data be marked CS1 DSCP."
which is updated to "[RFC3662] recommends that Low-Priority Data be
marked CS1 DSCP. [RFC4594] as updated by [RFCXXXX] recommends Low-
Priority Data be marked LE DSCP."
This document removes the following paragraph of RFC 8325,
Section 4.2.10 because this document makes the anticipated change:
"Note: This marking recommendation may change in the future, as [LE-
PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic
and recommends an additional DSCP for this traffic."
Section 4.2.10 of RFC 8325 [RFC8325] specifies "therefore, it is Section 4.2.10 of RFC 8325 [RFC8325] specifies "therefore, it is
RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1" RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1"
which is updated to "therefore, it is RECOMMENDED to map Low-Priority which is updated to "therefore, it is RECOMMENDED to map Low-Priority
Data traffic marked with LE DSCP or CS1 DSCP to UP 1" Data traffic marked with LE DSCP or legacy CS1 DSCP to UP 1"
This update to RFC 8325 removes the following entry from figure 1: This update to RFC 8325 replaces the following entry from figure 1:
+---------------+------+----------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) | | Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data | | | | | | Data | | | | |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
and replaces this by the following entry: by the following entries:
+---------------+------+----------+-------------+--------------------+ +---------------+------+----------+-------------+--------------------+
| Low-Priority | LE | RFCXXXX | 1 | AC_BK (Background) | | Low-Priority | LE | RFCXXXX | 1 | AC_BK (Background) |
| Data | | | | | | Data | | | | |
+--------------------------------------------------------------------+ +--------------------------------------------------------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data (legacy) | | | | |
+--------------------------------------------------------------------+
11. The Update to draft-ietf-tsvwg-rtcweb-qos 12. The Update to draft-ietf-tsvwg-rtcweb-qos
Section 5 of [I-D.ietf-tsvwg-rtcweb-qos] describes the Recommended Section 5 of [I-D.ietf-tsvwg-rtcweb-qos] describes the Recommended
DSCP Values for WebRTC Applications DSCP Values for WebRTC Applications
This update to [I-D.ietf-tsvwg-rtcweb-qos] replaces all occurences of This update to [I-D.ietf-tsvwg-rtcweb-qos] replaces all occurences of
CS1 with LE in Table 1: CS1 with LE in Table 1:
+------------------------+-------+------+-------------+-------------+ +------------------------+-------+------+-------------+-------------+
| Flow Type | Very | Low | Medium | High | | Flow Type | Very | Low | Medium | High |
| | Low | | | | | | Low | | | |
skipping to change at page 11, line 48 skipping to change at page 13, line 29
as follows: as follows:
"The above table assumes that packets marked with LE are treated as "The above table assumes that packets marked with LE are treated as
lower effort (i.e., "less than best effort"), such as the LE behavior lower effort (i.e., "less than best effort"), such as the LE behavior
described in [RFCXXXX]. However, the treatment of LE is described in [RFCXXXX]. However, the treatment of LE is
implementation dependent. If an implementation treats LE as other implementation dependent. If an implementation treats LE as other
than "less than best effort", then the actual priority (or, more than "less than best effort", then the actual priority (or, more
precisely, the per- hop-behavior) of the packets may be changed from precisely, the per- hop-behavior) of the packets may be changed from
what is intended. It is common for LE to be treated the same as DF, what is intended. It is common for LE to be treated the same as DF,
so applications and browsers using LE cannot assume that LE will be so applications and browsers using LE cannot assume that LE will be
treated differently than DF [RFC7657]." treated differently than DF [RFC7657]. During development of this
document, the CS1 DSCP was recommended for "very low" application
priority traffic; implementations that followed that recommendation
SHOULD be updated to use the LE DSCP instead of the CS1 DSCP."
12. IANA Considerations 13. IANA Considerations
This document assigns the Differentiated Services Field Codepoint This document assigns the Differentiated Services Field Codepoint
(DSCP) '000001' from the Differentiated Services Field Codepoints (DSCP) '000001' from the Differentiated Services Field Codepoints
(DSCP) registry (https://www.iana.org/assignments/dscp-registry/dscp- (DSCP) registry (https://www.iana.org/assignments/dscp-registry/dscp-
registry.xhtml) (Pool 3, Codepoint Space xxxx01, Standards Action) to registry.xhtml) (Pool 3, Codepoint Space xxxx01, Standards Action) to
the LE PHB. This document suggests to use a DSCP from Pool 3 in the LE PHB. This document suggests to use a DSCP from Pool 3 in
order to avoid problems for other PHB marked flows to become order to avoid problems for other PHB marked flows to become
accidentally remarked as LE PHB, e.g., due to partial DSCP bleaching. accidentally remarked as LE PHB, e.g., due to partial DSCP bleaching.
See [I-D.ietf-tsvwg-iana-dscp-registry] for the request to re- See [I-D.ietf-tsvwg-iana-dscp-registry] for the request to re-
classify Pool 3 for Standards Action. classify Pool 3 for Standards Action.
skipping to change at page 12, line 24 skipping to change at page 14, line 4
See [I-D.ietf-tsvwg-iana-dscp-registry] for the request to re- See [I-D.ietf-tsvwg-iana-dscp-registry] for the request to re-
classify Pool 3 for Standards Action. classify Pool 3 for Standards Action.
IANA is requested to update the registry as follows: IANA is requested to update the registry as follows:
o Name: LE o Name: LE
o Value (Binary): 000001 o Value (Binary): 000001
o Value (Decimal): 1 o Value (Decimal): 1
o Reference: [RFC number of this memo] o Reference: [RFC number of this memo]
13. Security Considerations 14. Security Considerations
There are no specific security exposures for this PHB. Since it There are no specific security exposures for this PHB. Since it
defines a new class of low forwarding priority, remarking other defines a new class of low forwarding priority, remarking other
traffic as LE traffic may lead to quality-of-service degradation of traffic as LE traffic may lead to quality-of-service degradation of
such traffic. Thus, any attacker that is able to modify the DSCP of such traffic. Thus, any attacker that is able to modify the DSCP of
a packet to LE may carry out a downgrade attack. See the general a packet to LE may carry out a downgrade attack. See the general
security considerations in [RFC2474] and [RFC2475]. security considerations in [RFC2474] and [RFC2475].
With respect to privacy, an attacker could use the information from With respect to privacy, an attacker could use the information from
the DSCP to infer that the transferred (probably even encrypted) the DSCP to infer that the transferred (probably even encrypted)
content is considered of low priority or low urgency by a user, in content is considered of low priority or low urgency by a user, in
case the DSCP was set on the user's request. However, this disclosed case the DSCP was set on the user's request. However, this disclosed
information is only useful if some form of identification happened at information is only useful if some form of identification happened at
the same time, see [RFC6973] for further details on general privacy the same time, see [RFC6973] for further details on general privacy
threats. threats.
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998, DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>. <http://www.rfc-editor.org/info/rfc2475>.
14.2. Informative References 15.2. Informative References
[carlberg-lbe-2001] [carlberg-lbe-2001]
Carlberg, K., Gevros, P., and J. Crowcroft, "Lower than Carlberg, K., Gevros, P., and J. Crowcroft, "Lower than
best effort: a design and implementation", SIGCOMM best effort: a design and implementation", SIGCOMM
Computer Communications Review Volume 31, Issue 2 Computer Communications Review Volume 31, Issue 2
supplement, April 2001, supplement, April 2001,
<https://doi.org/10.1145/844193.844208>. <https://doi.org/10.1145/844193.844208>.
[chown-lbe-2003] [chown-lbe-2003]
Chown, T., Ferrari, T., Leinen, S., Sabatino, R., Simar, Chown, T., Ferrari, T., Leinen, S., Sabatino, R., Simar,
skipping to change at page 14, line 37 skipping to change at page 16, line 19
[RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated [RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated
Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754, Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754,
April 2004, <http://www.rfc-editor.org/info/rfc3754>. April 2004, <http://www.rfc-editor.org/info/rfc3754>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006, DOI 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>. <http://www.rfc-editor.org/info/rfc4594>.
[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
"Raptor Forward Error Correction Scheme for Object
Delivery", RFC 5053, DOI 10.17487/RFC5053, October 2007,
<https://www.rfc-editor.org/info/rfc5053>.
[RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort [RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort
Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June
2011, <http://www.rfc-editor.org/info/rfc6297>. 2011, <http://www.rfc-editor.org/info/rfc6297>.
[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, [RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817, "Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012, DOI 10.17487/RFC6817, December 2012,
<http://www.rfc-editor.org/info/rfc6817>. <http://www.rfc-editor.org/info/rfc6817>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
skipping to change at page 15, line 43 skipping to change at page 17, line 31
There are several other names in use for this type of PHB or There are several other names in use for this type of PHB or
associated service classes. Well-known is the QBone Scavenger associated service classes. Well-known is the QBone Scavenger
Service (QBSS) that was proposed in March 2001 within the Internet2 Service (QBSS) that was proposed in March 2001 within the Internet2
QoS Working Group. Alternative names are "Lower-than-best-effort" QoS Working Group. Alternative names are "Lower-than-best-effort"
[carlberg-lbe-2001] or "Less-than-best-effort" [chown-lbe-2003]. [carlberg-lbe-2001] or "Less-than-best-effort" [chown-lbe-2003].
Appendix B. Acknowledgments Appendix B. Acknowledgments
Since text is borrowed from earlier Internet-Drafts and RFCs the co- Since text is borrowed from earlier Internet-Drafts and RFCs the co-
authors of previous specifications are acknowledged here: Kathie authors of previous specifications are acknowledged here: Kathie
Nichols and Klaus Wehrle. David Black, Gorry Fairhurst, and Ruediger Nichols and Klaus Wehrle. David Black, Toerless Eckert, Gorry
Geib provided helpful comments and suggestions. Fairhurst, and Ruediger Geib provided helpful comments and (also
text) suggestions.
Appendix C. Change History Appendix C. Change History
This section briefly lists changes between Internet-Draft versions This section briefly lists changes between Internet-Draft versions
for convenience. for convenience.
Changes in Version 06:
o added Multicast Considerations section with input from Toerless
Eckert
o incorporated suggestions by David Black with respect to better
reflect legacy CS1 handling
Changes in Version 05: Changes in Version 05:
o added scavenger service class into abstract o added scavenger service class into abstract
o added some more history o added some more history
o added reference for "Myth of Over-Provisioning" in RFC3439 and o added reference for "Myth of Over-Provisioning" in RFC3439 and
references to presentations w.r.t. codepoint choices references to presentations w.r.t. codepoint choices
o added text to update draft-ietf-tsvwg-rtcweb-qos o added text to update draft-ietf-tsvwg-rtcweb-qos
o revised text on congestion control in case of remarking to BE o revised text on congestion control in case of remarking to BE
o added reference to DSCP measurement talk @IETF99 o added reference to DSCP measurement talk @IETF99
o small typo fixes o small typo fixes
skipping to change at page 17, line 4 skipping to change at page 18, line 48
data from OSs data from OSs
o Added privacy considerations to the security section (not worth an o Added privacy considerations to the security section (not worth an
own section I think) own section I think)
o Changed IANA considerations section o Changed IANA considerations section
Changes in Version 02: Changes in Version 02:
o Applied many editorial suggestions from David Black o Applied many editorial suggestions from David Black
o Added Multicast traffic use case
o Added Multicast traffic use case
o Clarified what is required for deployment in section 1.2 o Clarified what is required for deployment in section 1.2
(Deployment Considerations) (Deployment Considerations)
o Added text about implementations using AQMs and ECN usage o Added text about implementations using AQMs and ECN usage
o Updated IANA section according to David Black's suggestions o Updated IANA section according to David Black's suggestions
o Revised text in the security section o Revised text in the security section
o Changed copyright Notice to pre5378Trust200902 o Changed copyright Notice to pre5378Trust200902
skipping to change at page 17, line 33 skipping to change at page 19, line 31
text about congestion control text about congestion control
o Change section 2 (PHB Description) according to R. Geib's o Change section 2 (PHB Description) according to R. Geib's
suggestions. suggestions.
o Added RFC 2119 language to several sentences. o Added RFC 2119 language to several sentences.
o Detailed the description of remarking implications and o Detailed the description of remarking implications and
recommendations in Section 8. recommendations in Section 8.
o Added Section 9 to explicitly list changes with respect to RFC o Added Section 10 to explicitly list changes with respect to RFC
4594, because this document will update it. 4594, because this document will update it.
Appendix D. Note to RFC Editor Appendix D. Note to RFC Editor
This section lists actions for the RFC editor during final This section lists actions for the RFC editor during final
formatting. formatting.
o Please replace the occurrences of RFCXXXX in Section 9 and o Please replace the occurrences of RFCXXXX in Section 10 and
Section 10 with the assigned RFC number for this document. Section 11 with the assigned RFC number for this document.
o Delete Appendix C. o Delete Appendix C.
o Delete this section. o Delete this section.
Author's Address Author's Address
Roland Bless Roland Bless
Karlsruhe Institute of Technology (KIT) Karlsruhe Institute of Technology (KIT)
Kaiserstr. 12 Kaiserstr. 12
Karlsruhe 76131 Karlsruhe 76131
Germany Germany
Phone: +49 721 608 46413 Phone: +49 721 608 46413
Email: roland.bless@kit.edu Email: roland.bless@kit.edu
 End of changes. 32 change blocks. 
50 lines changed or deleted 143 lines changed or added

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