Internet DRAFT - draft-you-tsvwg-latency-loss-tradeoff
draft-you-tsvwg-latency-loss-tradeoff
Tsvwg Working Group J. You
Internet-Draft Huawei
Intended status: Standards Track M. Welzl
Expires: September 14, 2016 University of Oslo
B. Trammell
M. Kuehlewind
ETH Zurich
K. Smith
Vodafone Group
March 13, 2016
Latency Loss Tradeoff PHB Group
draft-you-tsvwg-latency-loss-tradeoff-00
Abstract
This document defines a PHB (Per-Hop Behavior) group called Latency
Loss Tradeoff (LLT). The LLT group is intended to provide delivery
of IP packets in two classes of services: a low-loss service (Lo
service) and a low-latency service (La service). The LLT group
enables an application to request treatment for either low-loss or
low-latency at a congested network link.
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 [RFC2119].
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 September 14, 2016.
You, et al. Expires September 14, 2016 [Page 1]
Internet-Draft Latency Loss Tradeoff March 2016
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
(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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Abbreviations and acronyms . . . . . . . . . . . . . . . 3
2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Existing DSCP PHBs . . . . . . . . . . . . . . . . . . . 5
3.1.1. Default PHB . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Class Selector PHB . . . . . . . . . . . . . . . . . 5
3.1.3. Assured Forwarding PHB Group . . . . . . . . . . . . 5
3.1.4. Expedited Forwarding PHB . . . . . . . . . . . . . . 6
3.1.5. Voice Admit PHB . . . . . . . . . . . . . . . . . . . 6
3.1.6. Delay Bound PHB . . . . . . . . . . . . . . . . . . . 6
3.2. Incentives . . . . . . . . . . . . . . . . . . . . . . . 6
4. Definition of LLT PHB . . . . . . . . . . . . . . . . . . . . 7
4.1. Goal and Scope of LLT . . . . . . . . . . . . . . . . . . 7
4.2. Description of LLT behavior . . . . . . . . . . . . . . . 8
4.2.1. Implementation Considerations . . . . . . . . . . . . 8
4.3. Microflow misordering . . . . . . . . . . . . . . . . . . 9
4.4. Recommended Codepoints . . . . . . . . . . . . . . . . . 9
4.5. Mutability . . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 9
4.7. Interaction with other PHBs . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
You, et al. Expires September 14, 2016 [Page 2]
Internet-Draft Latency Loss Tradeoff March 2016
1. Introduction
Different applications have different communication requirements
[QoS]. In interactive applications of real-time sound transmission,
as well as in virtual reality, the overall one-way delay needs to be
short in order to give the user an impression of a real-time
response. Yet, these applications may be able to tolerate high loss
rates. In conventional text and data networking, delay thresholds
are the least stringent. The response time in these types of
applications can increase from 2 to 5 seconds before becoming
unacceptable. However, given that increased loss reduces the
throughput of TCP, these applications desire minimal loss.
The network resources consist primarily of buffers and link
bandwidth. Operators often favor high utilization of bottleneck
links at the price of high queuing delay. This is beneficial for
non-real time applications. However, this may be considered
unacceptable for some real-time applications. The proposed LLT group
enables an application to choose between low-latency and low-loss at
a congested network link [ABE] [RD]. Typically, an interactive
application with real-time deadlines, such as audio, will mark most
of its packets as a low-latency service. In contrast, an application
that transfers bulk data will mark most of its packets as a low-loss
service. The LLT group can be thought of as allowing an application
to trade loss for delay by marking packets low-latency service (La)
or to trade delay for loss by marking packets low-loss service (Lo).
2. Terminology
This section contains definitions for terms used frequently
throughout this document.
2.1. Abbreviations and acronyms
DS: Differentiated Service
PHB: Per-Hop Behavior
LLT: Latency Loss Tradeoff
TCA: Traffic Conditioning Agreement
TCP: Transmission Control Protocol
You, et al. Expires September 14, 2016 [Page 3]
Internet-Draft Latency Loss Tradeoff March 2016
2.2. Definitions
DS-capable: capable of implementing differentiated services as
described in this architecture; usually used in reference to a
domain consisting of DS-compliant nodes.
DS codepoint: a specific value of the DSCP portion of the DS
field, used to select a PHB.
DS-compliant: enabled to support differentiated services functions
and behaviors as defined in [RFC2474], this document, and other
differentiated services documents; usually used in reference to a
node or device.
DS field: the IPv4 header TOS octet or the IPv6 Traffic Class
octet when interpreted in conformance with the definition given in
[RFC2474]. The bits of the DSCP field encode the DS codepoint,
while the remaining bits are currently unused.
Low-latency service (La service): puts an emphasis on low queuing
delay at a congested network link. It allows an application to
trade loss for delay.
Low-loss service (Lo service): puts an emphasis on low packet loss
rate at a congested network link. It allows an application to
trade delay for loss.
Per-Hop-Behavior (PHB): the externally observable forwarding
behavior applied at a DS-compliant node to a DS behavior
aggregate.
PHB group: a set of one or more PHBs that can only be meaningfully
specified and implemented simultaneously, due to a common
constraint applying to all PHBs in the set such as a queue
servicing or queue management policy. A PHB group provides a
service building block that allows a set of related forwarding
behaviors to be specified together (e.g., four dropping
priorities). A single PHB is a special case of a PHB group.
Traffic Conditioning Agreement (TCA): an agreement specifying
classifier rules and any corresponding traffic profiles and
metering, marking, discarding and/or shaping rules which are to
apply to the traffic streams selected by the classifier. A TCA
encompasses all of the traffic conditioning rules explicitly
specified within a SLA along with all of the rules implicit from
the relevant service requirements and/or from a DS domain's
service provisioning policy.
You, et al. Expires September 14, 2016 [Page 4]
Internet-Draft Latency Loss Tradeoff March 2016
3. Problem Statement
3.1. Existing DSCP PHBs
3.1.1. Default PHB
A default Per-Hop Behavior (PHB) [RFC2474] MUST be available in a
DiffServ (DS)-compliant node. This is the common, best-effort
forwarding behavior available in existing routers as standardized in
[RFC1812]. Codepoint '000000' from Pool 1 is used as the default PHB
value. In this document, packets received with the Default PHB is
treated as Lo service on the LLT-compliant router.
3.1.2. Class Selector PHB
The Class Selector (CS) PHB [RFC2474] is introduced for backwards
compatibility with use of the IPv4 Precedence field. Any of the
eight codepoints in the range 'xxx000' (where 'x' may equal '0' or
'1') from Pool 1 is assigned as Class Selector codepoint. The CS PHB
does not match the services that LLT PHB is trying to deliver.
3.1.3. Assured Forwarding PHB Group
The Assured Forwarding (AF) PHB group [RFC2597] allows the operator
to provide assured forwarding of IP packets as long as the aggregate
traffic does not exceed the subscribed rate. Traffic that exceeds
the subscribed rate is not delivered with as high a probability as
the traffic that is within the rate.
The AF PHB group provides delivery of IP packets in four
independently forwarded AF classes. Within each AF class, an IP
packet can be assigned one of three different levels of drop
precedence. The combination of classes and drop precedence yields
twelve separate DSCP encodings from AF11 through AF43 as follows:
Class 1 Class 2 Class 3 Class 4
+----------+-----------+-----------+----------+
Low Drop Prec | 001010 | 010010 | 011010 | 100010 |
Medium Drop Prec | 001100 | 010100 | 011100 | 100100 |
High Drop Prec | 001110 | 010110 | 011110 | 100110 |
+----------+-----------+-----------+----------+
The AF PHB does not match the services that LLT PHB is trying to
deliver.
You, et al. Expires September 14, 2016 [Page 5]
Internet-Draft Latency Loss Tradeoff March 2016
3.1.4. Expedited Forwarding PHB
Expedited Forwarding (EF) PHB [RFC3246] is intended to provide a
building block for low delay, low jitter and low loss services by
ensuring that the EF aggregate is served at a certain configured
rate. EF traffic requires a strict admission control mechanism.
Codepoint '101110' is recommended for the EF PHB. The EF PHB does
not match the services that LLT PHB is trying to deliver.
3.1.5. Voice Admit PHB
The Voice Admit (VA) PHB [RFC5865] has identical characteristics to
the Expedited Forwarding PHB. However Voice Admit traffic is also
admitted by the network using a Call Admission Control (CAC)
procedure. The recommended DSCP for Voice Admit is '101100',
parallel with the existing EF codepoint '101110'. The VA PHB does
not match the services that LLT PHB is trying to deliver.
3.1.6. Delay Bound PHB
The Delay Bound (DB) PHB [RFC3248] requires a bound on the delay of
packets due to other traffic in the network. Two parameters - capped
arrival rate (R) and a 'score' (S), are defined and related to the
target delay variation bound. An experimental codepoint '101111' is
suggested for DB behavior. In this document, there's no specific
bound on the delay, the LLT PHB only indicates the tradeoff.
3.2. Incentives
The primary goal of differentiated services is to allow different
levels of service to be provided for traffic streams on a common
network infrastructure. Hence, an adversary may be able to obtain
better service by modifying the DS field to codepoints indicating
behaviors used for enhanced services or by injecting packets with the
DS field set to such codepoints. Such theft-of-service ([RFC2474],
[RFC2475]) becomes a denial-of-service attack when the modified or
injected traffic depletes the resources available to forward it and
other traffic streams.
DS ingress nodes must condition all traffic entering a DS domain to
ensure that it has acceptable DS codepoints. This means that the
codepoints must conform to the applicable TCA(s) (Traffic
Conditioning Agreement) [RFC2475] and the domain's service
provisioning policy. Packets received with an unacceptable
codepoints must either be discarded or must have their DS codepoints
modified to acceptable values before being forwarded. For example,
an ingress node receiving traffic from a domain with which no
enhanced service agreement exists may reset the DS codepoint to the
You, et al. Expires September 14, 2016 [Page 6]
Internet-Draft Latency Loss Tradeoff March 2016
Default PHB codepoint. However, the Default PHB (i.e. best-effort
forwarding) cannot meet the diverse needs of different Internet
applications.
The objective of the LLT PHB group is to retain the best-effort
service while providing low delay to real-time applications at the
expense of increased loss or providing low loss to non real-time
applications at the expense of increased delay. This requires
Internet applications to mark their traffic with appropriate
codepoint values. Since the low-loss service is neither better nor
worse than the low-latency service but is merely different, there is
no incentive for Internet applications to abuse such codepoints, and
no need for admission control.
4. Definition of LLT PHB
The LLT group provides forwarding of IP packets in two classes of
service: a low-loss service (Lo) and a low-latency service (La). The
LLT group enables an application to choose between low latency and
low loss at a congested network link. The packets marked as low-
latency service receive little queuing delay. The packets marked as
low-loss service receive at least as much throughput as they would in
a legacy best effort network. La-marked packets are more likely to
be dropped during periods of congestion than the Lo-marked packets.
Note that among the two services, neither of the two has priority
over the other.
4.1. Goal and Scope of LLT
The LLT group may be used by a network operator in two distinct ways:
either as a separate service, or as a replacement of the flat
(existing) best-effort IP service.
A DS (Differentiated Services) node SHOULD implement the LLT group.
It MAY allocate a configurable, minimum amount of forwarding
resources (buffer space and bandwidth) to LLT group.
The LLT group MAY also be configurable to receive more forwarding
resources than the minimum when excess resources are available from
other PHB groups. This is beyond the scope of this document.
The LLT PHB definition does NOT mandate or recommend any particular
method for achieving LLT behavior.
You, et al. Expires September 14, 2016 [Page 7]
Internet-Draft Latency Loss Tradeoff March 2016
4.2. Description of LLT behavior
To support the LLT group on an output link, the router can maintain
two FIFO (First-In First-Out) queues referred to as a Lo (Loss-
sensitive) queue and La (Latency-sensitive) queue for packets
destined to the link. Depending on whether an incoming packet is
marked for the low-loss or low-latency service, the router appends
the packet to the Lo or La queue respectively. The packets within
each queue are served in the FIFO order. The scheduling is work-
conserving.
A router can support the desired delay differentiation between the Lo
and La services through buffer sizing for the Lo and La queues, and
by ensuring that the La queue does not grow larger than the Lo queue.
As common in current Internet routers, the size of the Lo buffer is
chosen large enough so that the oscillating transmission of TCP
(Transmission Control Protocol) and other legacy end-to-end
congestion control protocols utilizes the available link rate fully.
The La buffer is configured to a much smaller dynamic size to ensure
that queuing delay for each forwarded packet of the La class is low.
The assurance of low maximum queuing delay is attractive for delay-
sensitive applications and easily verifiable by outside parties.
4.2.1. Implementation Considerations
This document does not specify any particular implementation method
for achieving LLT behavior. Some LLT-like implementations may refer
to [I-D.hurley-alternative-best-effort], [RD] and
[I-D.briscoe-aqm-dualq-coupled].
[I-D.hurley-alternative-best-effort] marks every best effort packet
as either green or blue. Green packets receive a low, bounded delay
at every hop, the value of the per-hop delay bound configured by the
operator. However, when transmitting more aggressively, the green
users can enjoy both a higher rate and lower queuing delay than those
of the blue users, which weakens the incentives for incremental
deployment. [RD] proposes Rate-Delay (RD) service enabling a user to
choose either a higher transmission rate or low queuing delay. The R
(Rate) service is like Lo service while D (Delay) service is like La
service.
Note that both classes defined in this document do not provide any
absolute guarantees on the loss rate or delay a packet will
experience. Using these classes only provides a relative treatment
compared to the other class. Depending on the amount of traffic
arriving per class, it is possible for traffic in the La class to
experience more delay than traffic in the Lo class. However, this
may be circumvented by using scheduling mechanisms, for example, by
You, et al. Expires September 14, 2016 [Page 8]
Internet-Draft Latency Loss Tradeoff March 2016
adjusting the scheduling function that assigns traffic to the Lo and
La queues, or by adjusting the scheduling weight based on the average
load in each class. Moreover, the delay experienced by La traffic is
always bounded by the length of the La queue. The particular
implementation is beyond the scope of this document.
When a DS-compliant node claims to implement the LLT PHB, the
implementation MUST conform to the specification given in this
document.
4.3. Microflow misordering
The packets within each queue are served in the FIFO order. Packets
belonging to a single microflow within the LLT aggregate SHOULD NOT
experience re-ordering in normal operation of the device when passing
through.
4.4. Recommended Codepoints
Recommended codepoints for the LLT PHB group are given below.
Low-loss service: 000001
Low-latency service:000101
4.5. Mutability
Packets marked for LLT PHB MAY be remarked at a DS domain boundary
only to other codepoints that satisfy the LLT PHB. Packets marked
for LLT PHBs SHOULD NOT be demoted or promoted to another PHB by a DS
domain.
4.6. Tunneling
When LLT packets are tunneled, the tunneling packets must be marked
as LLT.
4.7. Interaction with other PHBs
Other PHBs and PHB groups may be deployed in the same DS node or
domain with the LLT PHB.
Packets received with the Default PHB SHOULD be treated as Lo service
as default by the LLT PHB aware device. [RD] has proved that La
service does not hurt Lo service.
Packets received with the LLT PHB SHOULD be treated as Default PHB as
default by the LLT PHB unaware device.
You, et al. Expires September 14, 2016 [Page 9]
Internet-Draft Latency Loss Tradeoff March 2016
5. Security Considerations
Internet applications cannot benefit from wrongly indicating low-loss
or low-latency as they have to pay the expense of high delay or high
loss as a tradeoff. Hence there is no incentive for Internet
applications to set the wrong codepoints.
6. IANA Considerations
This document suggests two experimental codepoints, 000001/000101, in
Pool 3 of the code space defined by [RFC2474].
7. References
7.1. Normative References
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
RFC 1812, DOI 10.17487/RFC1812, June 1995,
<http://www.rfc-editor.org/info/rfc1812>.
[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>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999,
<http://www.rfc-editor.org/info/rfc2597>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<http://www.rfc-editor.org/info/rfc3246>.
You, et al. Expires September 14, 2016 [Page 10]
Internet-Draft Latency Loss Tradeoff March 2016
[RFC3248] Armitage, G., Carpenter, B., Casati, A., Crowcroft, J.,
Halpern, J., Kumar, B., and J. Schnizlein, "A Delay Bound
alternative revision of RFC 2598", RFC 3248,
DOI 10.17487/RFC3248, March 2002,
<http://www.rfc-editor.org/info/rfc3248>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, DOI 10.17487/RFC5865, May 2010,
<http://www.rfc-editor.org/info/rfc5865>.
7.2. Informative References
[ABE] Hurley, P., Le Boudec, J., Thiran, P., and M. Kara, "ABE:
Providing a Low-Delay Service within Best Effort", IEEE
Network Magazine 15(3): 60-69, May 2001.
[I-D.briscoe-aqm-dualq-coupled]
Schepper, K., Briscoe, B., Bondarenko, O., and I. Tsang,
"DualQ Coupled AQM for Low Latency, Low Loss and Scalable
Throughput", draft-briscoe-aqm-dualq-coupled-00 (work in
progress), August 2015.
[I-D.hurley-alternative-best-effort]
Hurley, P., Iannaccone , G., Kara , M., Le Boudec , J.,
Thiran , P., and C. Diot , "The ABE Service", November
2000.
[QoS] Chen, C., Farley, T., and N. Ye, "QoS Requirements of
Network Applications on the Internet", Information
Knowledge Systems Management 2004, 4(1): 55-76, 2004.
[RD] Podlesny, M. and S. Gorinsky, "RD network services:
differentiation through performance incentives", ACM
SIGCOMM Computer Communication Review, 38(4): 255-266,
2008.
Authors' Addresses
Jianjie You
Huawei
101 Software Avenue, Yuhua District
Nanjing 210012
China
Email: youjianjie@huawei.com
You, et al. Expires September 14, 2016 [Page 11]
Internet-Draft Latency Loss Tradeoff March 2016
Michael Welzl
University of Oslo
PO Box 1080 Blindern
Oslo N-0316
Norway
Email: michawe@ifi.uio.no
Brian Trammell
ETH Zurich
Zurich
Switzerland
Email: ietf@trammell.ch
Mirja Kuehlewind
ETH Zurich
Zurich
Switzerland
Email: mirja.kuehlewind@tik.ee.ethz.ch
Kevin Smith
Vodafone Group
One Kingdom Street,
London
UK
Email: kevin.smith@vodafone.com
You, et al. Expires September 14, 2016 [Page 12]
