Internet DRAFT - draft-polk-tsvwg-delay-vs-loss-ds-service-classes
draft-polk-tsvwg-delay-vs-loss-ds-service-classes
Network WG James Polk
Internet-Draft Toerless Eckert
Intended status: PS Cisco Systems
Expires: January 15, 2014 July 15, 2013
Differentiated Services Delay-and-Loss vs. Loss-Rate-Adaptive
Service Classes
draft-polk-tsvwg-delay-vs-loss-ds-service-classes-00.txt
Abstract
This document discusses how RTCWeb/RMCAT applications could best
leverage existing and new DiffServ assignments and why we think it
is necessary to differentiate the assignments of delay-and-loss-
based vs. just-loss-based rate-adaptive video applications.
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 January 15, 2014.
Copyright Notice
Copyright (c) 2013 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.
Polk & Eckert Expires January 15, 2014 [Page 1]
Internet-Draft DS Delay- vs. Loss-based Service Classes July 2013
1. Introduction
The current guidelines for DSCP assignments of traffic in the IETF
is the informational RFC 4594 [RFC4594]. The TSV Working Group is
currently reviewing how to update these assignments with one
proposal being [ID-4594bis].
This document discusses how RTCWeb/RMCAT applications could best
leverage [RFC4594] & [ID-4594bis] assignments and why we think it is
necessary to differentiate the assignments of video for these type
of applications from non-rate adaptive video flows (i.e., MPEG2).
The current text of [ID-4594bis] has audio flows within an
interactive communication assigned to EF. The current text of
[RFC4594] has interactive video flows would be assigned to AF4x.
The definition of AF4x directly matches the requirements for delay
and loss-based rate-adaptive, self-friendly video traffic as
targeted by RTCWeb applications and RMCAT congestion mechanisms.
Splitting audio and video this way into separate traffic classes
would specifically provide the benefit of guaranteeing no
congestion/loss for the audio part while allowing congestion in
video to cause rate adaptation where there is contention in the
network. Unfortunately, the reality of deployments of AF4x in
network in the last decade or longer does not match this original
target of [RFC4594], instead relying only on loss in the network to
indicate congestion.
2. Terminology
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] when they
appear in ALL CAPS. These words may also appear in this document in
lower case as plain English words, absent their normative meanings.
3. Rate-Adaptive Traffic is Inelastic (and often badly provisioned)
Because delay-based rate-adaptive video for conferencing has for the
most part been a fairly recent development, the majority of video
traffic deployed in many networks into AF41 or AF4x in general has
been inelastic, highly loss-sensitive video traffic at fixed
bitrates. This type of video deployment is accompanied by some form
of either
o a vendor specific "Locations CAC" (LCAC) mechanism,
o an on-path RSVP based CAC or
Polk & Eckert Expires January 15, 2014 [Page 2]
Internet-Draft DS Delay- vs. Loss-based Service Classes July 2013
o a much more commonly what is perceived to be sufficient
overprovisioning.
This is because LCAC is often considered to be too provisioning
intense and RSVP CAC is not supported on a critical mass of
application/devices to be deployable in most networks.
In addition to Video, AF4x often also carries in practice, the
(non-rate adaptive) voice part of collaborative sessions, primarily
because creating lip-sync between EF audio and AF4x video traffic
when they experiences differing jitter and latency in the network
was seen as a complexity that especially lower end hardware based
video endpoints wanted to avoid implementing. Additional reasons for
this:
o Endpoints are too lazy to mark, so network devices mark and cannot
tell what flow is video vs. audio;
o Implementers simply did not give the option to mark voice or video
differently;
o People want the same per-hop behavior for audio and video. After
all, getting one type of media there faster is of little value
since it just has to be put in a buffer and queued, waiting for
the other flow.
Alas, what might have been sufficient overprovisioning often turns
out to be "pray and suffer" in the face of often badly controllable
addition of new applications, devices, users or increased in
utilization. For example, the busy hour in large enterprises often
shrinks and becomes even more busy when expanding operations across
multiple time zones. All these problems are the primary reason to
propose the move to rate adaptive video, as seen in many recent
products and IETF RTCweb/RMCAT work, but with the often long-term
investments in a lot of this equipment in enterprises and cost of
migrating deployment designs, the issues with this current use of
AF4x is not going to go away for a long time. The recent interest in
more application or network based circuit-breaker methods
[ID-AVT-CB] for this type of inelastic traffic is also a good proof
for this pain point (including the demands within the IETF to
support them on any inelastic solution (i.e,. RTCWeb & RMCAT
efforts)).
Because of these fairly widespread deployments of AF4x and their
issues, these flows make for a fairly bad PHB to put RMCAT/RTCweb
traffic into. Rate adaptive traffic will always come up short
against non-rate adaptive, incongestible traffic when being put into
the same queue. This is especially true when provisioning for AF4x
is leveraging the above "pray and suffer + circuit breaker"
approach.
Polk & Eckert Expires January 15, 2014 [Page 3]
Internet-Draft DS Delay- vs. Loss-based Service Classes July 2013
4. Jitter from Non-Rate Adaptive Video Traffic is Bad
Even if the existing non-rate-adaptive traffic was correctly
provisioned such that there is no congestion, and even if all that
traffic is known in a particular deployment to only use AF41, it
would still not be a good idea to put rate-adaptive RTCweb/RMCAT
traffic into AF42/AF43.
The reason is that according to the definition of these traffic
classes, all AF4x traffic should be in a single queue because there
must be no reordering between AF4x packets. The permissible
differentiation between AF41/AF42/AF43 therefore are differential
drop profiles via WRED or other methods. This means that even if
there is never ongoing congestion caused by badly behaving legacy
non-rate adaptive traffic, the new rate-adaptive video traffic would
still suffer from the jitter introduced by that old video traffic
because it has to share a queue. And it would suffer proportional to
the amount of traffic in the queue, aka: it would suffer most during
the busy hours.
This jitter from unknown/legacy/bad video traffic is especially
troublesome because delay variation schemes considered for
rate-control in RMCAT will be conscious of that jitter and likely
work less well when exposed to it.
It is hard enough - even unavoidable - for RMCAT to figure out how
deal with competing TCP traffic on a single BE "Internet Queue". It
is a total waste of effort and easily avoidable for RMCAT having to
figure out how to deal with the jitter and loss introduced by legacy
non-rate-adaptive video traffic in controlled environments where
traffic can be separated by DSCP.
5. Suggested Behavior in the Network
5.1 CS4 and CS4-Discardable for rate-adaptive video
This document is therefore asking to assign a Service Class to delay
and loss-based rate-adaptive, self-friendly conversational video
traffic that is separate from AF4x.
We think that CS4 has been a traffic class that so far has seen
little use and most likely is the easiest traffic class to use for
this traffic.
In addition, it would be very helpful for future improvements in
delay and loss-based rate-adaptive video traffic in the network if
there is a second traffic class, e.g., "CS4-Discardable", for
lower-priority packets within video flows that can easily be
dropped.
Given how rate-adaptive video will not always be able to avoid all
Polk & Eckert Expires January 15, 2014 [Page 4]
Internet-Draft DS Delay- vs. Loss-based Service Classes July 2013
packet drops, video codecs can improve the visual quality in
conjunction with the network by creating discardable P-frames (e.g.,
P-frames not referenced by other P-frames) and having the network
preferentially drop those frames. This can easily achieved with two
DSCP assigned values, where one has a higher drop priority that the
other. This, of course, is exactly the logic also designated for
AF41/AF42/AF43, in other words we are simply asking for a new PHB be
assigned to the existing AF41 (suggest: CS4) and a new AF42
(suggested: CS4-Discardable).
5.2 AF4x for Non-Rate-Adaptive Video
To represent the reality of deployments in the IETF guidelines, AF41
should be re-designated for non-rate adaptive conversational video
with explicit admission control (off-path or non-path). AF42 should
be re-designated for non-rate-adaptive conversational video without
explicit admission control (e.g., relying solely on circuit
breakers).
This proposal, in effect, is suggesting the text in RFC 4594
regarding AF4X, as written, be ported/moved over to replace the text
in that same RFC that was for CS4 PHB. New text will need to be
written in the RFC4594bis document addressing AF4X taking over the
more legacy traffic behaviors from non-adaptive (based on loss)
video traffic.
6. Additional Recommendations for Other PHBs Affected
Specifying that delay and loss-based rate-adaptive video use CS4
(and 'CS4+' or 'CS4-Discardable' or 'CS4-D') means the current RFC
4594 assignment of CS4 to the Realtime-Interactive (RTI) service
class needs modification. Rather than create new definitions for
CS4, currently occupied with the Realtime Interactive (RTI) PHB
traffic according to RFC 4594, our proposal is to move the RTI
service class definitions to CS5 (as is the case in [ID-4594bis] -
where the RTI will have a minimal effect on the existing installed
base of implementations because it has few.
The CS5 PHB, which is assigned for H.323 and SIP signaling, would be
then moved to another DSCP. Perhaps near Low-Latency Data (CS2)
according to [ID-4594bis].
7. Acknowledgements
The authors would like to thank Paul Jones, Charles Eckel, Charles
Ganzhorn, Fred Baker, Mo Zanaty, Michael Ramalho for their active
participation in this effort.
Polk & Eckert Expires January 15, 2014 [Page 5]
Internet-Draft DS Delay- vs. Loss-based Service Classes July 2013
8. IANA Considerations
If the WG agrees with this effort, then there will need to be a
reassignment of AF4X and CS4, as well as the new assignment of an
additional CS4+ or CS4-discardable PHB.
9. Security Considerations
TBW
10. References
10.1 Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
[RFC4594] J. Babiarz, K. Chan, F Baker, "Configuration Guidelines for
Diffserv Service Classes", RFC 4594, August 2006
[ID-4594bis] J. Polk, "Standard Configuration of DiffServ Service
Classes", "work in progress", March 2012
[ID-AVT-CB] C. Perkins, V. Singh, "Multimedia Congestion Control:
Circuit Breakers for Unicast RTP Sessions", work in
progress, July 2013
10.2 Informative References
none at this time
Author's Addresses
James Polk
Cisco Systems, Inc.
8017 Hallmark Dr.
North Richland Hills, TX 76182
USA
Phone: +1 817 271 3552
Email: jmpolk@cisco.com
Toerless Eckert
Cisco Systems, Inc.
San Jose
US
Email: eckert@cisco.com
Polk & Eckert Expires January 15, 2014 [Page 6]
