[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                          Z. Sarker
Internet-Draft                                              I. Johansson
Intended status: Standards Track                             Ericsson AB
Expires: November 21, 2008                                  May 20, 2008


     Usecases and Benefits of end to end ECN support in PCN Domains
                  draft-sarker-pcn-ecn-pcn-usecases-01

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 November 21, 2008.

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 November 21, 2008               [Page 1]


Internet-Draft        End to end ECN in PCN Domain              May 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 November 21, 2008               [Page 2]


Internet-Draft        End to end ECN in PCN Domain              May 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 [RFC4960] and SCTP [RFC4340] 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 November 21, 2008               [Page 3]


Internet-Draft        End to end ECN in PCN Domain              May 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 November 21, 2008               [Page 4]


Internet-Draft        End to end ECN in PCN Domain              May 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 November 21, 2008               [Page 5]


Internet-Draft        End to end ECN in PCN Domain              May 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 November 21, 2008               [Page 6]


Internet-Draft        End to end ECN in PCN Domain              May 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 November 21, 2008               [Page 7]


Internet-Draft        End to end ECN in PCN Domain              May 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 November 21, 2008               [Page 8]


Internet-Draft        End to end ECN in PCN Domain              May 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 November 21, 2008               [Page 9]


Internet-Draft        End to end ECN in PCN Domain              May 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-08 (work in
              progress), May 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 8 7573743
   Email: Sarker.Zaheduzzaman@ericsson.com






Sarker & Johansson      Expires November 21, 2008              [Page 10]


Internet-Draft        End to end ECN in PCN Domain              May 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 November 21, 2008              [Page 11]


Internet-Draft        End to end ECN in PCN Domain              May 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 November 21, 2008              [Page 12]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/