Network Working Group Z. Sarker
Internet-Draft I. Johansson
Intended status: Standards Track Ericsson AB
Expires: May 24, 2009 November 20, 2008
Usecases and Benefits of end to end ECN support in PCN Domains
draft-sarker-pcn-ecn-pcn-usecases-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 24, 2009.
Abstract
This document provides an informative overview of possible use cases
where ECN marking can be used for inelastic traffic. It outlines
benefits of preserving the ECN support in a PCN domain. As ECN
provides with a simple mechanism for network nodes to inform the end
points about possible upcoming congestion and resulting packet losses
and delay increase, the scheme can be useful for adaptive real-time
media applications, thus enabling them to adjust the transmission
rate to avoid quality degradation due to congestion. By showing the
benefits of ECN this memo asks the working group to consider end to
end ECN support in PCN domain.
Sarker & Johansson Expires May 24, 2009 [Page 1]
Internet-Draft End to end ECN in PCN Domain November 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Real-time conversation . . . . . . . . . . . . . . . . . . 4
3.2. Semi real-time/content based streaming . . . . . . . . . . 5
3.3. Online multiplayer gaming network control . . . . . . . . 5
3.4. 3GPP scenario/issues (cellular network) . . . . . . . . . 5
3.5. Traffic engineering and prioritized flows . . . . . . . . 7
4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Downgrading to DF class . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Securitiy Considerations . . . . . . . . . . . . . . . . . . . 9
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Informative References . . . . . . . . . . . . . . . . . . 10
10.2. Normative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Sarker & Johansson Expires May 24, 2009 [Page 2]
Internet-Draft End to end ECN in PCN Domain November 2008
1. Introduction
ECN (Explicit Congestion Notification) described in [RFC3168]
provides an alternative behavior for the routers to react on
congestion. With the ECN concept, ECN capable routers with active
queue management can detect congestion before the queues overflow and
mark the packets in the IP header to indicate congestion to the end
points of communication. The end points are expected to react on the
congestion indication and take necessary actions to avoid the packet
loss. ECN is an end to end schema that may be used with any traffic
class that is using IP. The ECN mechanism needs transport layer
support for signaling and [RFC3168] defines a mechanism that can be
used with TCP. A recent study [ZVA] has shown that ECN can also be
beneficial for other transport protocols such as UDP. Additionally
DCCP [RFC4340] and SCTP [RFC4960] has specific support for ECN.
The PCN (Pre-Congestion Notification) [I-D.ietf-pcn-architecture]
concept proposes an "architecture for flow admission and termination
based on aggregated (pre-) congestion information in order to protect
the quality of service" in a PCN domain. PCN aims to work within a
diffserv domain and current document defines an architecture for
established inelastic flows within that diffserv domain. If a
catastrophic failure occurs such that the available bandwidth within
the PCN domain is reduced, the flow termination mechanism can be used
to restrict the damage inflicted by the failing node or link. There
has been discussion going on within the IETF PCN working group to use
the DSCP and/or ECN field to encode the PCN marking in the IP header.
Even though the current RFC [RFC3168] only defines the ECN mechanism
for elastic traffic, ECN can still be useful for congestion
management for inelastic traffic. The main goal of this memo is to
highlight use cases where ECN can be useful for inelastic traffic
classes, thus reconsidering the encoding of PCN flow marking in ECN
fields of the IP header. This document neither suggests any
alternative for PCN marking nor defines any fields for such marking.
2. Glossary
A list of the terms used in this document.
ECN - Explicit Congestion Notification
PCN - (Pre-) Congestion Notification
QoS - Quality of Service
Sarker & Johansson Expires May 24, 2009 [Page 3]
Internet-Draft End to end ECN in PCN Domain November 2008
MBR - Maximum Bit Rate
GBR - Guaranteed Bit Rate
eNB - Evolved Node B
HSPA - High Speed Packet Access
RAB - Radio Access Bearer
RAN - Radio Access Network
LTE - (UTRA & UTRAN) Long Term Evolution
HD - High Definition
3. Use cases
This section lists some use cases where support for end to end ECN
over PCN domains is beneficial.
3.1. Real-time conversation
High quality real-time conversational services require high bitrate
and short delay. This impose high requirements on transport channels
as maintaining higher bitrate and shorter delay is often expensive
especially in cellular networks. For this reason, media codecs are
carefully selected for real-time conversational services to ensure
that high quality media can be delivered even at low bitrate and with
low delay. Real-time conversational media can include text, speech
and video. Video transmission requires more bandwidth than other
media. In a low bitrate video stream, which usually has low intra
refresh rate, packet losses can cause significant quality
degradation. Similar issues apply for speech. To maintain
sufficiently high quality in a real-time conversational session, the
transport channels need to be close to congestion-free to prevent
packet losses and to provide with short delay. In these cases ECN
can play a vital role for real time traffic by reducing the
likelihood of packet losses by allowing the end points to adapt to
the load in the network. For real time traffic, RTP over UDP is
used. Profiles like RTP/AVPF, which allows for immediate reporting
of events, can be useful to use together with ECN for adaptation
signaling for real time traffic.
Sarker & Johansson Expires May 24, 2009 [Page 4]
Internet-Draft End to end ECN in PCN Domain November 2008
3.2. Semi real-time/content based streaming
Semi real-time services like streaming, a.k.a content services are
services like Video on Demand (VoD), IPTV, Mobile TV etc. The user
subscribes to the content provided by content providers and expects
to receive high quality (e.g HD quality) media. These types of
services use client/server architectures and can allow some delay in
the content delivery. As users expect to receive high quality media,
the need to avoid packet losses becomes significant. Here, ECN
capabilities can be used to monitor network conditions and make
possible to adjust the transmission rate to avoid packet losses in
the network. This can ensure uninterrupted high quality content to
the viewers/users.
ECN could also trigger the use of application or transport layer FEC
to compensate for downstream packet drop. FEC packets typically add
delay and more load to the end-to-end flows, but this can be
compensated for by decreasing transmission rate and constraining its
operation to near-realtime streams.
3.3. Online multiplayer gaming network control
Due to their timely delivery nature, UDP is the preferred transport
protocol for online multi player gaming. Online multi player gaming
generally uses Client/Server architecture where the server is
responsible for game rules, environment change and input processing
and the client is usually the player's computer or gaming device.
Client and server communicate with each other using high packet rates
(30-40 packets per second). As the network bandwidth is limited,
keeping the latency low is a big and crucial factor in multi player
online gaming. Even an extra delay in the range of milliseconds can
make it difficult to hit other players or interact with moving or
fast running objects.
As packet losses can cause loss of information about user input,
world change etc. dropping packets during congestion periods may not
be a good idea for these kind of services. Rather, marking the
packets as congestion experienced (CE) and letting the server and
client to adjust their sending rate and even packet size is more
efficient. An end to end scheme like ECN can be applicable here
especially since it can be proactive and fast.
3.4. 3GPP scenario/issues (cellular network)
A cellular environment is more complicated than a wireline ditto
since it seeks to provide services in the context of variable
available bandwidth, location dependencies, wireless link errors and
user mobilities at different speeds. Here, the user may reach the
Sarker & Johansson Expires May 24, 2009 [Page 5]
Internet-Draft End to end ECN in PCN Domain November 2008
cell edge which may lead to a significant amount of retransmissions
to deliver the data from the base station to the destination and vice
versa. These network links or radio links will often act as a
bottleneck for the rest of the network which will eventually lead to
excess delays or packet drops. An efficient retransmission or link
adaptation mechanism can reduce the packet loss probability but there
will still be some packet loss and delay variations. Moreover, with
increased cell load or handover to a congested cell, transport
network level congestion will become even worse. Thus ensuring the
maximum network utilization and providing constant level of QoS is a
big challenge.
Additionally, future communication applications and systems will
impose higher QoS requirements than that of the current state of the
art. Especially, in next generation cellular systems like LTE, call
blocking and forced call termination needs to be kept at an absolute
minimum. Under these circumstances, adaptive applications or
services can play a vital role to provide better quality of
experience. The QoS schema in LTE defines two rate specific QoS
attributes; Guaranteed Bit Rate (GBR) and Maximum Bit Rate (MBR).
GBR denotes the bit rate on which the admission decision is based
while MBR denotes the maximum bit rate which the user can utilize if
available. A granted GBR confirms that the network admits one call
and has reserved enough resources to provide at least the bit rate
specified in GBR. The call can then use bit rates up to the MBR.
GBR and MBR can be used by the adaptive application for a better
utilization of resources and improved QoS.
Rate adaptive codec utilization is not new within 3GPP nor are the
RAB attributes GBR and MBR. Previously however, it has been deemed
unsuitable to utilize the area above GBR but below MBR since that
area is treated as pure best effort traffic in the mobile network.
Hence, any RAB attribute setting such as targeted packet loss rate is
only applicable to the GBR, not the area above GBR. In other words,
the traffic going above GBR can at any moment experience severe
packet losses. Loss rates high enough to render e.g. a
conversational video media stream useless.
The basic requirement to start to utilize the area above GBR is that
the application either has some idea about the amount of losses it
can expect or that it can receive some warning that congestion is
imminent and that the probability of congestion related losses is
high. The most future proof solution in this context is a network
originated pre-warning about forthcoming congestion related packet
losses.
The new RAN architecture proposed for 3GPP release 8 has made it
possible to access the IP layer all the way down into the LTE base
Sarker & Johansson Expires May 24, 2009 [Page 6]
Internet-Draft End to end ECN in PCN Domain November 2008
station, the eNB. This makes it possible to utilize IP layer
functionality to signal messages from the RAN to the UE from the node
in the network where the traffic bottleneck is most likely to occur.
Using the IP layer to signal this kind of information also makes the
schema more future proof and access technology transparent. Looking
at the standards track RFCs available in IETF, the option of applying
ECN to achieve this kind of pre-warning seems appropriate.
Signaling in the IP layer can also be useful in other scenarios where
a combination of wired and wireless interfaces is available. For
example, let us consider an HSPA micro/femto basestation at home
which is connected to some radio basestation. The base station can
be connected to another basestation via the air interface. In this
particular case nothing will be visible above the IP header at these
basestations but they will still be possible to signal congestion
notification to the end points via the IP header.
Thus, a real need of an end to end early congestion notification
mechanism like ECN can be seen for real time multimedia applications.
If ECN to be used in the described scenarios then ECN marking need to
be protected all the way to the endpoints. PCN domains will reside
in between the end points. Any modification to ECN bits within the
PCN domain without restoring them will cause definite harm to the
negotiated adaptaion procedure in the applications.
3.5. Traffic engineering and prioritized flows
The term prioritized traffic has been typically associated with flows
that are exempt or least likely to experience packet loss during
times of congestion in relation to other flows transiting the same
node. Prioritized flows are either explicitly labeled in one or more
layers, or they are identified by an external signaling protocol like
RSVP.
Given the underlying goal of ECN to reduce the load of a flow,
prioritization would initially seem counter productive from both an
end-to-end and local PCN perspective. However, recent work within
the IETF on the subject of prioritization presents scenarios where
labels or installed state via signaling can trigger specific traffic
engineering techniques beneficial to PCN domains.
[RFC4190] presents the case where different virtual paths may be used
for prioritized traffic, thereby potentially increasing the
probability of that traffic being forwarded to its destination as
well as decreasing load of other flows along the previously shared
path. In the case of [I-D.ietf-tsvwg-emergency-rsvp] and its
Priority By-Pass Model, signaling can be used to free up resources
set aside for certain types of flows. In this latter example,
Sarker & Johansson Expires May 24, 2009 [Page 7]
Internet-Draft End to end ECN in PCN Domain November 2008
probability is increased for certain flows to be forwarded without
additional load or disruptive impact incurred on other non-
prioritized flows.
Within the context of ECN and PCN domains, ECN can act as an end-to-
end trigger of both prioritization and subsequent traffic engineering
on an as-needed basis instead of through the entire lifespan of flows
considered to be important. This as-needed traffic engineering
capability can be symbiotic in a PCN domain attempting to address
disruptive conditions (e.g., flash crowds).
4. Benefits
The benefits from considering end to end support for ECN in a PCN
domain can be summarized as follows:
o By signaling ECN in the IP header, adaptation can be agnostic to
the underlying network technology.
o End to end congestion signaling will allow adaptive applications
to adjust their sending rate, packet size etc. during congestion
period in a proactive, preventive way, which will eventually keep
the network in a more stable state
o In 3GPP cellular networks no control plane overhead is associated
with ECN since it is based on user plane packet marking
Additionally, when transport support for ECN signaling is available
for inelastic traffic and if end points negotiate to use ECN, lack of
support for end to end ECN in a PCN domain may cause malfunction in
the applications.
5. Downgrading to DF class
There has been some discussion in the PCN working group to downgrade
ECN capable EF class traffic to DF class (best effort). This means
that if the PCN ingress node captures any packet in with the ECN-CE
mark set it will simply modify the DSCP and downgrade that packet to
DF class. The EF class traffic certainly requires some QoS support
from transport channels as they are inelastic by nature. Depending
on location of PCN domain the downgraded packet might need to
traverse the rest of its transmission path as DF class traffic. In
this case, the downside of doing such kind of downgrading is listed
below.
Sarker & Johansson Expires May 24, 2009 [Page 8]
Internet-Draft End to end ECN in PCN Domain November 2008
o Downgraded traffic flow will not get any QoS in the core network
which might cause longer delay, more jitter and increased packet
loss.
o Downgraded traffic has to compete with TCP and other proprietary
non QoS access traffic.
o Downgraded traffic may also affect TCP performance as TCP by its
nature will be generous to inelastic traffic during congestion.
Thus TCP can suffer from bandwidth scarceness.
6. IANA Considerations
This memo includes no request to IANA.
7. Securitiy Considerations
This memo does not arise any new security issues. This document is
based on [RFC3168] and security considerations discussed in [RFC3168]
are also applicable while treating this document.
8. Conclusions
In this draft the use cases where ECN can be beneficial for EF class
traffic have been discussed. The discussion reveals some benefits of
supporting ECN capabilities in PCN domain. Using an end to end
scheme like ECN, adaptive real time applications will be able to
provide high quality services even in hostile network conditions.
ECN can help these applications to reduce packet loss and delay. As
the current PCN architecture is not intended to extend down towards
the end points we believe keeping the ECN support in PCN domain will
make the PCN concept stronger.
9. Acknowledgements
This document has been benefited from discussions with many people.
The authors would like to thank all the people who gave feedback on
this document especially Daniel Enstrom, Magnus Westerlund, Reiner
Ludwig, Lars Westberg and Stefan Hakansson for their detailed review
and comments. Thanks also to Ken Carlberg for suggested additions.
10. References
Sarker & Johansson Expires May 24, 2009 [Page 9]
Internet-Draft End to end ECN in PCN Domain November 2008
10.1. Informative References
[I-D.ietf-tsvwg-emergency-rsvp]
Faucheur, F., Polk, J., and K. Carlberg, "Resource
ReSerVation Protovol (RSVP) Extensions for Emergency
Services", draft-ietf-tsvwg-emergency-rsvp-09 (work in
progress), October 2008.
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
Supporting Emergency Telecommunications Service (ETS) in
IP Telephony", RFC 4190, November 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[ZVA] Sarker, S., ""Adaptive Real Time Video over LTE", MS
thesis, Lulea University of Technology,
Sweden,November,2007.
http://epubl.ltu.se/1653-0187/2007/064/index-en.html".
10.2. Normative References
[I-D.ietf-pcn-architecture]
Eardley, P., "Pre-Congestion Notification Architecture",
draft-ietf-pcn-architecture-03 (work in progress),
February 2008.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
Authors' Addresses
Zaheduzzaman Sarker
Ericsson AB
Laboratoriegrand 11
SE-971 28 Lulea
SWEDEN
Phone: +46 10 7173743
Email: Zaheduzzaman.Sarker@ericsson.com
Sarker & Johansson Expires May 24, 2009 [Page 10]
Internet-Draft End to end ECN in PCN Domain November 2008
Ingemar Johansson
Ericsson AB
Laboratoriegrand 11
SE-971 28 Lulea
SWEDEN
Phone: +46 73 0783289
Email: ingemar.s.johansson@ericsson.com
Sarker & Johansson Expires May 24, 2009 [Page 11]
Internet-Draft End to end ECN in PCN Domain November 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Sarker & Johansson Expires May 24, 2009 [Page 12]