draft-ietf-tsvwg-le-phb-02.txt   draft-ietf-tsvwg-le-phb-03.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) June 30, 2017 Obsoletes: 3662 (if approved) February 5, 2018
Updates: 4594 (if approved) Updates: 4594 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: January 1, 2018 Expires: August 9, 2018
A Lower Effort Per-Hop Behavior (LE PHB) A Lower Effort Per-Hop Behavior (LE PHB)
draft-ietf-tsvwg-le-phb-02 draft-ietf-tsvwg-le-phb-03
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. There are numerous uses for this PHB, traffic and may preempt it. There are numerous uses for this PHB,
e.g., for background traffic of low precedence, such as bulk data e.g., for background traffic of low precedence, such as bulk data
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 1, 2018. This Internet-Draft will expire on August 9, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 40 skipping to change at page 2, line 40
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Deployment Considerations . . . . . . . . . . . . . . . . 5 1.2. Deployment Considerations . . . . . . . . . . . . . . . . 5
1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 6
2. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 6 2. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 6
3. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 7 3. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 7
4. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 7 4. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 7
5. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 7 5. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 7
6. Changes to RFC 4594 . . . . . . . . . . . . . . . . . . . . . 8 6. Changes to RFC 4594 . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 11 Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 11
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 11 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 12
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 11 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 12
Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 12 Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
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 of [RFC2474] called "Lower Effort" (LE) which is intended for traffic of
sufficiently low urgency that all other traffic takes precedence over sufficiently low urgency that all other traffic takes precedence over
LE traffic in consumption of network link bandwidth. Low urgency LE traffic in consumption of network link bandwidth. Low urgency
traffic has a low priority for timely forwarding, which does not traffic has a low priority for timely forwarding, which does not
necessarily imply that it is generally of minor importance. From 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
skipping to change at page 5, line 11 skipping to change at page 5, line 11
flows. flows.
Example uses for the LE PHB: Example uses for the LE PHB:
o For traffic caused by world-wide web search engines while they o For traffic caused by world-wide web search engines while they
gather information from web servers. gather information from web servers.
o For software updates or dissemination of new releases of operating o For software updates or dissemination of new releases of operating
systems. systems.
o For reporting errors or telemetry data from operating systems or
applications.
o For backup traffic or non-time critical synchronization or o For backup traffic or non-time critical synchronization or
mirroring traffic. mirroring traffic.
o For content distribution transfers between caches. o For content distribution transfers between caches.
o For preloading or prefetching objects from web sites. o For preloading or prefetching objects from web sites.
o For Netnews and other "bulk mail" of the Internet. o For Network news and other "bulk mail" of the Internet.
o For "downgraded" traffic from some other PHB when this does not o For "downgraded" traffic from some other PHB when this does not
violate the operational objectives of the other PHB or the overall violate the operational objectives of the other PHB or the overall
network. network.
o For multicast traffic from untrusted (e.g., non-local) sources. o For multicast traffic from untrusted (e.g., non-local) sources.
1.2. Deployment Considerations 1.2. Deployment Considerations
In order to enable LE support, DS nodes typically only need In order to enable LE support, DS nodes typically only need
skipping to change at page 7, line 23 skipping to change at page 7, line 27
As for most other PHBs an initial classification and marking can be As for most other PHBs an initial classification and marking can be
also performed at the first DS boundary node according to the DS also performed at the first DS boundary node according to the DS
domain's own policies (e.g., as protection measure against untrusted domain's own policies (e.g., as protection measure against untrusted
sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to LE on a regular basis without consent or knowledge of the remarked to LE on a regular basis without consent or knowledge of the
user. See also remarks with respect to downgrading in Section 1.1. user. See also remarks with respect to downgrading in Section 1.1.
4. Recommended DS Codepoint 4. Recommended DS Codepoint
The RECOMMENDED codepoint for the LE PHB is '000010'. The RECOMMENDED codepoint for the LE PHB is '000001'.
Earlier specifications [RFC4594] recommended to use CS1 as codepoint Earlier specifications [RFC4594] recommended to use CS1 as codepoint
(as mentioned in [RFC3662]). This is problematic since it may cause (as mentioned in [RFC3662]). This is problematic since it may cause
a priority inversion in DiffServ domains that treat CS1 as originally a priority inversion in DiffServ domains that treat CS1 as originally
proposed in [RFC2474], resulting in forwarding LE packets with higher proposed in [RFC2474], resulting in forwarding LE packets with higher
precedence than BE packets. Existing implementations SHOULD precedence than BE packets. Existing implementations SHOULD
therefore use the unambiguous LE codepoint '000010' whenever therefore use the unambiguous LE codepoint '000001' whenever
possible. possible.
This particular codepoint was chosen due to measurements on the
currently observable DSCP remarking behavior in the Internet. Since
some network domains set the former IP precedence bits to zero, it is
possible that some other standardized DSCPs get mapped to the LE PHB
DSCP if it were taken from the DSCP standards action pool 1 (xxxxx0).
5. Remarking to other DSCPs/PHBs 5. Remarking to other DSCPs/PHBs
"DSCP bleaching", i.e., setting the DSCP to '000000' (default PHB) is "DSCP bleaching", i.e., setting the DSCP to '000000' (default PHB) is
NOT RECOMMENDED for this PHB. This may cause effects that are in NOT RECOMMENDED for this PHB. This may cause effects that are in
contrast to the original intent in protecting BE traffic from LE contrast to the original intent in protecting BE traffic from LE
traffic (no harm property). In case DS domains do not support the LE traffic (no harm property). In case DS domains do not support the LE
PHB, they SHOULD treat LE marked packets with the default PHB instead PHB, they SHOULD treat LE marked packets with the default PHB instead
(by mapping the LE DSCP to the default PHB), but they SHOULD do so (by mapping the LE DSCP to the default PHB), but they SHOULD do so
without remarking to DSCP '000000'. The reason for this is that without remarking to DSCP '000000'. The reason for this is that
later traversed DS domains may then have still the possibility to later traversed DS domains may then have still the possibility to
skipping to change at page 8, line 12 skipping to change at page 8, line 22
In case LE marked packets are effectively carried within the default In case LE marked packets are effectively carried within the default
PHB (i.e., forwarded as best-effort traffic) they get a better PHB (i.e., forwarded as best-effort traffic) they get a better
forwarding treatment than expected. For some applications and forwarding treatment than expected. For some applications and
services, it is favorable if the transmission is finished earlier services, it is favorable if the transmission is finished earlier
than expected. However, in some cases it may be against the original than expected. However, in some cases it may be against the original
intention of the LE PHB user to strictly send the traffic only if intention of the LE PHB user to strictly send the traffic only if
otherwise unused resources are available, i.e., LE traffic may otherwise unused resources are available, i.e., LE traffic may
compete with BE traffic for the same resources and thus adversely compete with BE traffic for the same resources and thus adversely
affect the original BE aggregate. In some cases users want to be affect the original BE aggregate. In some cases users want to be
sure that their LE marked traffic actually fulfills the "no harm" sure that their LE marked traffic actually fulfills the "no harm"
property. property. Applications that want to ensure the lower precedence
compared to BE traffic SHOULD use additionally a corresponding Lower-
One possible solution for a clear distinction in such cases would be than-Best-Effort transport protocol [RFC6297], e.g., LEDBAT
to use two different codepoints, "LE-min = LE, better treatment [RFC6817].
allowed", "LE-strict = LE, better treatment NOT allowed". However,
since DSCPs are a scarce resource, applications that want to ensure
the lower precedence compared to BE traffic SHOULD use additionally a
corresponding Lower-than-Best-Effort transport protocol [RFC6297],
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]) MUST remark traffic to the LE DSCP '000010' definition in [RFC3662]) MUST remark traffic to the LE DSCP '000001'
at the egress to the next DS domain. This increases the probability at the egress to the next DS domain. This increases the probability
that the DSCP is preserved end-to-end, whereas a CS1 marked packet that the DSCP is preserved end-to-end, whereas a CS1 marked packet
may be remarked by the default DSCP if the next domain is applying may be remarked by the default DSCP if the next domain is applying
DiffServ-intercon [RFC8100]. DiffServ-intercon [RFC8100].
6. Changes to RFC 4594 6. Changes 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:
o The Low-Priority Data row in Figure 3 is updated as follows: o The Low-Priority Data row in Figure 3 is updated as follows:
|---------------+---------+-------------+--------------------------| |---------------+---------+-------------+--------------------------|
| Low-Priority | LE | 000010 | Any flow that has no BW | | Low-Priority | LE | 000001 | Any flow that has no BW |
| Data | | | assurance | | Data | | | assurance |
------------------------------------------------------------------ ------------------------------------------------------------------
o The Low-Priority Data row in Figure 4 is updated as follows: o The Low-Priority Data row in Figure 4 is updated as follows:
|---------------+------+-------------------+---------+--------+----| |---------------+------+-------------------+---------+--------+----|
| Low-Priority | LE | Not applicable | RFCXXXX | Rate | Yes| | Low-Priority | LE | Not applicable | RFCXXXX | Rate | Yes|
| Data | | | | | | | Data | | | | | |
------------------------------------------------------------------ ------------------------------------------------------------------
skipping to change at page 9, line 22 skipping to change at page 9, line 29
o [RFC4594] recommended to remark Low-Priority Data to DSCP '000001' o [RFC4594] recommended to remark Low-Priority Data to DSCP '000001'
inside a DS domain that uses IP precedence marking. By using the inside a DS domain that uses IP precedence marking. By using the
herein defined LE DSCP such remarking is not necessary, so even if herein defined LE DSCP such remarking is not necessary, so even if
Low-Priority Data is unsupported (i.e., mapped to the default PHB) Low-Priority Data is unsupported (i.e., mapped to the default PHB)
the LE DSCP should be kept across the domain as RECOMMENDED in the LE DSCP should be kept across the domain as RECOMMENDED in
Section 5. Section 5.
7. IANA Considerations 7. IANA Considerations
This document assigns the Differentiated Services Field Codepoint This document assigns the Differentiated Services Field Codepoint
(DSCP) '000010' 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.xml) to the LE PHB. IANA is requested to update the registry.xhtml) (Pool 3, Codepoint Space xxxx01, Standards Action) to
registry as follows: 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
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-
classify Pool 3 for Standards Action.
IANA is requested to update the registry as follows:
o Name: LE o Name: LE
o Value (Binary): 000010 o Value (Binary): 000001
o Value (Decimal): 2 o Value (Decimal): 1
o Reference: [RFC number of this memo] o Reference: [RFC number of this memo]
8. Security Considerations 8. 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
the DSCP to infer that the transferred (probably even encrypted)
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
information is only useful if some form of identification happened at
the same time, see [RFC6973] for further details on general privacy
threats.
9. References 9. References
9.1. Normative References 9.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,
skipping to change at page 10, line 24 skipping to change at page 10, line 44
<http://www.rfc-editor.org/info/rfc2475>. <http://www.rfc-editor.org/info/rfc2475>.
9.2. Informative References 9.2. Informative References
[draft-bless-diffserv-lbe-phb-00] [draft-bless-diffserv-lbe-phb-00]
Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop
Behavior", draft-bless-diffserv-lbe-phb-00 (work in Behavior", draft-bless-diffserv-lbe-phb-00 (work in
progress), September 1999, <https://tools.ietf.org/html/ progress), September 1999, <https://tools.ietf.org/html/
draft-bless-diffserv-lbe-phb-00>. draft-bless-diffserv-lbe-phb-00>.
[I-D.ietf-tsvwg-iana-dscp-registry]
Fairhurst, G., "IANA Assignment of DSCP Pool 3 (xxxx01)
Values to require Publication of a Standards Track or Best
Current Practice RFC", draft-ietf-tsvwg-iana-dscp-
registry-00 (work in progress), February 2018.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>. <http://www.rfc-editor.org/info/rfc3168>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003, RFC 3662, DOI 10.17487/RFC3662, December 2003,
<http://www.rfc-editor.org/info/rfc3662>. <http://www.rfc-editor.org/info/rfc3662>.
skipping to change at page 11, line 5 skipping to change at page 11, line 33
[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.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
editor.org/info/rfc6973>.
[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection [RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
Classes and Practice", RFC 8100, DOI 10.17487/RFC8100, Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
March 2017, <http://www.rfc-editor.org/info/rfc8100>. March 2017, <http://www.rfc-editor.org/info/rfc8100>.
Appendix A. History of the LE PHB Appendix A. History of the LE PHB
A first version of this PHB was suggested by Roland Bless and Klaus A first version of this PHB was suggested by Roland Bless and Klaus
Wehrle in 1999 [draft-bless-diffserv-lbe-phb-00]. After some Wehrle in 1999 [draft-bless-diffserv-lbe-phb-00]. After some
discussion in the DiffServ Working Group Brian Carpenter and Kathie discussion in the DiffServ Working Group Brian Carpenter and Kathie
Nichols proposed a bulk handling per-domain behavior and believed a Nichols proposed a bulk handling per-domain behavior and believed a
skipping to change at page 11, line 32 skipping to change at page 12, line 17
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 and Ruediger Geib provided Nichols and Klaus Wehrle. David Black and Ruediger Geib provided
helpful comments and suggestions. helpful comments and 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 03:
o Changed recommended codepoint to 000001
o Added text to explain the reasons for the DSCP choice
o Removed LE-min,LE-strict discussion
o Added one more potential use case: reporting errors or telemetry
data from OSs
o Added privacy considerations to the security section (not worth an
own section I think)
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
 End of changes. 23 change blocks. 
30 lines changed or deleted 76 lines changed or added

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