[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-jholland-mops-taxonomy) 00 01 02

MOPS                                                          J. Holland
Internet-Draft                                 Akamai Technologies, Inc.
Intended status: Informational                                  A. Begen
Expires: 13 January 2021                                 Networked Media
                                                              S. Dawkins
                                                     Tencent America LLC
                                                            12 July 2020

             Operational Considerations for Streaming Media


   This document provides an overview of operational networking issues
   that pertain to quality of experience in delivery of video and other
   high-bitrate media over the internet.

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 https://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 13 January 2021.

Copyright Notice

   Copyright (c) 2020 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 (https://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.

Holland, et al.          Expires 13 January 2021                [Page 1]

Internet-Draft             Media Streaming Ops                 July 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Notes for Contributors and Reviewers  . . . . . . . . . .   3
       1.1.1.  Venues for Contribution and Discussion  . . . . . . .   3
       1.1.2.  Template for Contributions  . . . . . . . . . . . . .   3
       1.1.3.  History of Public Discussion  . . . . . . . . . . . .   4
   2.  Bandwidth Provisioning  . . . . . . . . . . . . . . . . . . .   5
     2.1.  Scaling Requirements for Media Delivery . . . . . . . . .   5
       2.1.1.  Video Bitrates  . . . . . . . . . . . . . . . . . . .   5
       2.1.2.  Virtual Reality Bitrates  . . . . . . . . . . . . . .   5
     2.2.  Path Requirements . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Caching Systems . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Predictable Usage Profiles  . . . . . . . . . . . . . . .   6
     2.5.  Unpredictable Usage Profiles  . . . . . . . . . . . . . .   7
     2.6.  Extremely Unpredictable Usage Profiles  . . . . . . . . .   8
   3.  Adaptive Bitrate  . . . . . . . . . . . . . . . . . . . . . .   9
     3.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . .   9
     3.2.  Segmented Delivery  . . . . . . . . . . . . . . . . . . .   9
       3.2.1.  Idle Time between Segments  . . . . . . . . . . . . .   9
       3.2.2.  Head-of-Line Blocking . . . . . . . . . . . . . . . .  10
     3.3.  Unreliable Transport  . . . . . . . . . . . . . . . . . .  10
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  11
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   As the internet has grown, an increasingly large share of the traffic
   delivered to end users has become video.  Estimates put the total
   share of internet video traffic at 75% in 2019, expected to grow to
   82% by 2022.  What's more, this estimate projects the gross volume of
   video traffic will more than double during this time, based on a
   compound annual growth rate continuing at 34% (from Appendix D of

   In many contexts, video traffic can be handled transparently as
   generic application-level traffic.  However, as the volume of video
   traffic continues to grow, it's becoming increasingly important to
   consider the effects of network design decisions on application-level
   performance, with considerations for the impact on video delivery.

   This document aims to provide a taxonomy of networking issues as they
   relate to quality of experience in internet video delivery.  The
   focus is on capturing characteristics of video delivery that have
   surprised network designers or transport experts without specific

Holland, et al.          Expires 13 January 2021                [Page 2]

Internet-Draft             Media Streaming Ops                 July 2020

   video expertise, since these highlight key differences between common
   assumptions in existing networking documents and observations of
   video delivery issues in practice.

   Making specific recommendations for mitigating these issues is out of
   scope, though some existing mitigations are mentioned in passing.
   The intent is to provide a point of reference for future solution
   proposals to use in describing how new technologies address or avoid
   these existing observed problems.

1.1.  Notes for Contributors and Reviewers

   Note to RFC Editor: Please remove this section and its subsections
   before publication.

   This section is to provide references to make it easier to review the
   development and discussion on the draft so far.

1.1.1.  Venues for Contribution and Discussion

   This document is in the Github repository at:


   Readers are welcome to open issues and send pull requests for this

   Substantial discussion of this document should take place on the MOPS
   working group mailing list (mops@ietf.org).

   *  Join: https://www.ietf.org/mailman/listinfo/mops

   *  Search: https://mailarchive.ietf.org/arch/browse/mops/

1.1.2.  Template for Contributions

   Contributions are solicited regarding issues and considerations that
   have an impact on media streaming operations.

   Please note that contributions may be merged and substantially
   edited, and as a reminder, please carefully consider the Note Well
   before contributing: https://datatracker.ietf.org/submit/note-well/

   Contributions can be emailed to mops@ietf.org, submitted as issues to
   the issue tracker of the repository in Section 1.1.1, or emailed to
   the document authors at draft-ietf-mops-streaming-opcons@ietf.org.

Holland, et al.          Expires 13 January 2021                [Page 3]

Internet-Draft             Media Streaming Ops                 July 2020

   Contributors describing an issue not yet addressed in the draft are
   requested to provide the following information, where applicable:

   *  a suggested title or name for the issue

   *  a long-term pointer to the best reference describing the issue

   *  a short description of the nature of the issue and its impact on
      media quality of service, including:

      -  where in the network this issue has root causes

      -  who can detect this issue when it occurs

   *  an overview of the issue's known prevalence in practice.  pointers
      to write-ups of high-profile incidents are a plus.

   *  a list of known mitigation techniques, with (for each known

      -  a name for the mitigation technique

      -  a long-term pointer to the best reference describing it

      -  a short description of the technique:

         o  what it does

         o  where in the network it operates

         o  an overview of the tradeoffs involved-how and why it's
            helpful, what it costs.

      -  supplemental information about the technique's deployment
         prevalence and status

1.1.3.  History of Public Discussion


   *  IETF 105 BOF:


   *  IETF 106 meeting:


Holland, et al.          Expires 13 January 2021                [Page 4]

Internet-Draft             Media Streaming Ops                 July 2020

2.  Bandwidth Provisioning

2.1.  Scaling Requirements for Media Delivery

2.1.1.  Video Bitrates

   Video bitrate selection depends on many variables.  Different
   providers give different guidelines, but an equation that
   approximately matches the bandwidth requirement estimates from
   several video providers is given in [MSOD]:

   Kbps = (HEIGHT * WIDTH * FRAME_RATE) / (15 * 1024)

   Height and width are in pixels, and frame rate is in frames per
   second.  The actual bitrate required for a specific video will also
   depend on the codec used, fidelity desired and some other
   characteristics of the video itself, such as the amount and frequency
   of high-detail motion, which may influence the compressability of the
   content, but this equation provides a rough estimate.

   Here are a few common resolutions used for video content, with their
   typical per-user bandwidth requirements according to this formula:

      | Name       | Width x Height | Approximate Bitrate for 60fps |
      | DVD        | 720 x 480      | 1.3 Mbps                      |
      | 720p (1K)  | 1280 x 720     | 3.6 Mbps                      |
      | 1080p (2K) | 1920 x 1080    | 8.1 Mbps                      |
      | 2160p (4k) | 3840 x 2160    | 32 Mbps                       |

                                  Table 1

2.1.2.  Virtual Reality Bitrates

   Even the basic virtual reality (360-degree) videos (that allow users
   to look around freely, referred to as three degrees of freedom -
   3DoF) require substantially larger bitrates when they are captured
   and encoded as such videos require multiple fields of view of the
   scene.  The typical multiplication factor is 8 to 10.  Yet, due to
   smart delivery methods such as viewport-based or tiled-based
   streaming, we do not need to send the whole scene to the user.
   Instead, the user needs only the portion corresponding to its
   viewpoint at any given time.

Holland, et al.          Expires 13 January 2021                [Page 5]

Internet-Draft             Media Streaming Ops                 July 2020

   In more immersive applications, where basic user movement (3DoF+) or
   full user movement (6DoF) is allowed, the required bitrate grows even
   further.  In this case, the immersive content is typically referred
   to as volumetric media.  One way to represent the volumetric media is
   to use point clouds, where streaming a single object may easily
   require a bitrate of 30 Mbps or higher.  Refer to [PCC] for more

2.2.  Path Requirements

   The bitrate requirements in Section 2.1 are per end-user actively
   consuming a media feed, so in the worst case, the bitrate demands can
   be multiplied by the number of simultaneous users to find the
   bandwidth requirements for a router on the delivery path with that
   number of users downstream.  For example, at a node with 10,000
   downstream users simultaneously consuming video streams,
   approximately up to 80 Gbps would be necessary in order for all of
   them to get 1080p resolution at 60 fps.

   However, when there is some overlap in the feeds being consumed by
   end users, it is sometimes possible to reduce the bandwidth
   provisioning requirements for the network by performing some kind of
   replication within the network.  This can be achieved via object
   caching with delivery of replicated objects over individual
   connections, and/or by packet-level replication using multicast.

   To the extent that replication of popular content can be performed,
   bandwidth requirements at peering or ingest points can be reduced to
   as low as a per-feed requirement instead of a per-user requirement.

2.3.  Caching Systems

   TBD: pros, cons, tradeoffs of caching designs at different locations
   within the network?

   Peak vs. average provisioning, and effects on peering point
   congestion under peak load?

   Provisioning issues for caching systems?

2.4.  Predictable Usage Profiles

   Historical data shows that users consume more video and videos at
   higher bitrates than they did in the past on their connected devices.
   Improvements in the codecs that help with reducing the encoding
   bitrates with better compression algorithms could not have offset the
   increase in the demand for the higher quality video (higher
   resolution, higher frame rate, better color gamut, better dynamic

Holland, et al.          Expires 13 January 2021                [Page 6]

Internet-Draft             Media Streaming Ops                 July 2020

   range, etc.).  In particular, mobile data usage has shown a large
   jump over the years due to increased consumption of entertainement as
   well as conversational video.

   TBD: insert charts showing historical relative data usage patterns
   with error bars by time of day in consumer networks?

   Cross-ref vs. video quality by time of day in practice for some case
   study?  Not sure if there's a good way to capture a generalized
   insight here, but it seems worth making the point that demand
   projections can be used to help with e.g. power consumption with
   routing architectures that provide for modular scalability.

2.5.  Unpredictable Usage Profiles

   Although TCP/IP has been used with a number of widely used
   applications that have symmetric bandwidth requirements (similar
   bandwidth requirements in each direction between endpoints), many
   widely-used Internet applications operate in client-server roles,
   with asymmetric bandwidth requirements.  A common example might be an
   HTTP GET operation, where a client sends a relatively small HTTP GET
   request for a resource to an HTTP server, and often receives a
   significantly larger response carrying the requested resource.  When
   HTTP is commonly used to stream movie-length video, the ratio between
   response size and request size can become quite large.

   For this reason, operators may pay more attention to downstream
   bandwidth utilization when planning and managing capacity.  In
   addition, operators have been able to deploy access networks for end
   users using underlying technologies that are inherently asymetric,
   favoring downstream bandwidth (e.g.  ADSL, cellular technologies,
   most IEEE 802.11 variants), assuming that users will need less
   upstream bandwidth than downstream bandwidth.  This strategy usually
   works, except when it does not, because application bandwidth usage
   patterns have changed.

   One example of this type of change was when peer-to-peer file sharing
   applications gained popularity in the early 2000s.  To take one well-
   documented case ([RFC5594]), the Bittorrent application created
   "swarms" of hosts, uploading and downloading files to each other,
   rather than communicating with a server.  Bittorrent favored peers
   who uploaded as much as they downloaded, so that new Bittorrent users
   had an incentive to significantly increase their upstream bandwidth

   The combination of the large volume of "torrents" and the peer-to-
   peer characteristic of swarm transfers meant that end user hosts were
   suddenly uploading higher volumes of traffic to more destinations

Holland, et al.          Expires 13 January 2021                [Page 7]

Internet-Draft             Media Streaming Ops                 July 2020

   than was the case before Bittorrent.  This caused at least one large
   ISP to attempt to "throttle" these transfers, to mitigate the load
   that these hosts placed on their network.  These efforts were met by
   increased use of encryption in Bittorrent, similar to an arms race,
   and set off discussions about "Net Neutrality" and calls for
   regulatory action.

   Especially as end users increase use of video-based social networking
   applications, it will be helpful for access network providers to
   watch for increasing numbers of end users uploading significant
   amounts of content.

2.6.  Extremely Unpredictable Usage Profiles

   The causes of unpredictable usage described in Section 2.5 were more
   or less the result of human choices, but we were reminded during a
   post-IETF 107 meeting that humans are not always in control, and
   forces of nature can cause enormous fluctuations in traffic patterns.

   In his talk, Sanjay Mishra [Mishra] reported that after the CoViD-19
   pandemic broke out in early 2020,

   *  Comcast's streaming and web video consumption rose by 38%, with
      their reported peak traffic up 32% overall between March 1 to
      March 30 [Comcast],

   *  AT&T reported a 28% jump in core network traffic (single day in
      April, as compared to pre stay-at-home daily average traffic),
      with video accounting for nearly half of all mobile network
      traffic, while social networking and web browsing remained the
      highest percentage (almost a quarter each) of overall mobility
      traffic [ATT], and

   *  Verizon reported similar trends with video traffic up 36% over an
      average day (pre COVID-19) [Verizon].

   We note that other operators saw similar spikes during this time
   period.  Craig Labowitz [Labovitz] reported

   *  Weekday peak traffic increases over 45%-50% from pre-lockdown

   *  A 30% increase in upstream traffic over their pre-pandemic levels,

Holland, et al.          Expires 13 January 2021                [Page 8]

Internet-Draft             Media Streaming Ops                 July 2020

   *  A steady increase in the overall volume of DDoS traffic, with
      amounts exceeding the pre-pandemic levels by 40%. (He attributed
      this increase to the significant rise in gaming-related DDoS
      attacks ([LabovitzDDoS]), as gaming usage also increased.)

3.  Adaptive Bitrate

3.1.  Overview

   Adaptive BitRate (ABR) is a sort of application-level response
   strategy in which the receiving media player attempts to detect the
   available bandwidth of the network path by experiment or by observing
   the successful application-layer download speed, then chooses a video
   bitrate (among the limited number of available options) that fits
   within that bandwidth, typically adjusting as changes in available
   bandwidth occur in the network or changes in capabilities occur in
   the player (such as available memory, CPU, display size, etc.).

   The choice of bitrate occurs within the context of optimizing for
   some metric monitored by the video player, such as highest achievable
   video quality, or lowest rate of expected rebuffering events.

3.2.  Segmented Delivery

   ABR playback is commonly implemented by video players using HLS
   [RFC8216] or DASH [DASH] to perform a reliable segmented delivery of
   video data over HTTP.  Different player implementations and receiving
   devices use different strategies, often proprietary algorithms
   (called rate adaptation or bitrate selection algorithms), to perform
   available bandwidth estimation/prediction and the bitrate selection.
   Most players only use passive observations, i.e., they do not
   generate probe traffic to measure the available bandwidth.

   This kind of bandwidth-measurement systems can experience trouble in
   several ways that can be affected by networking design choices.

3.2.1.  Idle Time between Segments

   When the bitrate selection is successfully chosen below the available
   capacity of the network path, the response to a segment request will
   typically complete in less absolute time than the duration of the
   requested segment.  The resulting idle time within the connection
   carrying the segments has a few surprising consequences:

   *  Mobile flow-bandwidth spectrum and timing mapping.

Holland, et al.          Expires 13 January 2021                [Page 9]

Internet-Draft             Media Streaming Ops                 July 2020

   *  TCP slow-start when restarting after idle requires multiple RTTs
      to re-establish a throughput at the network's available capacity.
      On high-RTT paths or with small enough segments, this can produce
      a falsely low application-visible measurement of the available
      network capacity.

   A detailed investigation of this phenomenon is available in

3.2.2.  Head-of-Line Blocking

   In the event of a lost packet on a TCP connection with SACK support
   (a common case for segmented delivery in practice), loss of a packet
   can provide a confusing bandwidth signal to the receiving
   application.  Because of the sliding window in TCP, many packets may
   be accepted by the receiver without being available to the
   application until the missing packet arrives.  Upon arrival of the
   one missing packet after retransmit, the receiver will suddenly get
   access to a lot of data at the same time.

   To a receiver measuring bytes received per unit time at the
   application layer, and interpreting it as an estimate of the
   available network bandwidth, this appears as a high jitter in the
   goodput measurement.

   Active Queue Management (AQM) systems such as PIE [RFC8033] or
   variants of RED [RFC2309] that induce early random loss under
   congestion can mitigate this by using ECN [RFC3168] where available.
   ECN provides a congestion signal and induce a similar backoff in
   flows that use Explicit Congestion Notification-capable transport,
   but by avoiding loss avoids inducing head-of-line blocking effects in
   TCP connections.

3.3.  Unreliable Transport

   In contrast to segmented delivery, several applications use UDP or
   unreliable SCTP to deliver RTP or raw TS-formatted video.

   Under congestion and loss, this approach generally experiences more
   video artifacts with fewer delay or head-of-line blocking effects.
   Often one of the key goals is to reduce latency, to better support
   applications like videoconferencing, or for other live-action video
   with interactive components, such as some sporting events.

Holland, et al.          Expires 13 January 2021               [Page 10]

Internet-Draft             Media Streaming Ops                 July 2020

   Congestion avoidance strategies for this kind of deployment vary
   widely in practice, ranging from some streams that are entirely
   unresponsive to using feedback signaling to change encoder settings
   (as in [RFC5762]), or to use fewer enhancement layers (as in
   [RFC6190]), to proprietary methods for detecting quality of
   experience issues and cutting off video.

4.  IANA Considerations

   This document requires no actions from IANA.

5.  Security Considerations

   This document introduces no new security issues.

6.  Acknowledgements

   Thanks to Mark Nottingham, Glenn Deen, Dave Oran, Aaron Falk, Kyle
   Rose, and Leslie Daigle for their very helpful reviews and comments.

7.  Informative References

   [ATT]      AT&T, "Tuesday (March 24, 2020) Network Insights", March
              2020, <https://about.att.com/pages/COVID-19/updates.html>.

   [Comcast]  CNBC, "Comcast sees network traffic surge amid coronavirus
              outbreak", March 2020,

   [CVNI]     Cisco Systems, Inc., "Cisco Visual Networking Index:
              Forecast and Trends, 2017-2022 White Paper", 27 February
              2019, <https://www.cisco.com/c/en/us/solutions/collateral/

   [DASH]     "Information technology -- Dynamic adaptive streaming over
              HTTP (DASH) -- Part 1: Media presentation description and
              segment formats", ISO/IEC 23009-1:2019, 2019.

   [Labovitz] Labovitz, C. and Nokia Deepfield, "Network traffic
              insights in the time of COVID-19: April 9 update", April
              2020, <https://www.nokia.com/blog/network-traffic-

              Takahashi, D. and Venture Beat, "Why the game industry is
              still vulnerable to DDoS attacks", May 2018,

Holland, et al.          Expires 13 January 2021               [Page 11]

Internet-Draft             Media Streaming Ops                 July 2020


   [Mishra]   Mishra, S. and J. Thibeault, "An update on Streaming Video
              Alliance", 2020, <https://datatracker.ietf.org/meeting/

   [MSOD]     Akamai Technologies, Inc., "Media Services On Demand:
              Encoder Best Practices", 2019, <https://learn.akamai.com/

              al., S.A.e., "What Happens When HTTP Adaptive Streaming
              Players Compete for Bandwidth?", June 2012,

   [PCC]      al., S.S.e., "Emerging MPEG Standards for Point Cloud
              Compression", March 2019,

   [RFC2309]  Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
              S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
              Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
              S., Wroclawski, J., and L. Zhang, "Recommendations on
              Queue Management and Congestion Avoidance in the
              Internet", RFC 2309, DOI 10.17487/RFC2309, April 1998,

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,

   [RFC5594]  Peterson, J. and A. Cooper, "Report from the IETF Workshop
              on Peer-to-Peer (P2P) Infrastructure, May 28, 2008",
              RFC 5594, DOI 10.17487/RFC5594, July 2009,

   [RFC5762]  Perkins, C., "RTP and the Datagram Congestion Control
              Protocol (DCCP)", RFC 5762, DOI 10.17487/RFC5762, April
              2010, <https://www.rfc-editor.org/info/rfc5762>.

Holland, et al.          Expires 13 January 2021               [Page 12]

Internet-Draft             Media Streaming Ops                 July 2020

   [RFC6190]  Wenger, S., Wang, Y.-K., Schierl, T., and A.
              Eleftheriadis, "RTP Payload Format for Scalable Video
              Coding", RFC 6190, DOI 10.17487/RFC6190, May 2011,

   [RFC8033]  Pan, R., Natarajan, P., Baker, F., and G. White,
              "Proportional Integral Controller Enhanced (PIE): A
              Lightweight Control Scheme to Address the Bufferbloat
              Problem", RFC 8033, DOI 10.17487/RFC8033, February 2017,

   [RFC8216]  Pantos, R., Ed. and W. May, "HTTP Live Streaming",
              RFC 8216, DOI 10.17487/RFC8216, August 2017,

   [Verizon]  Rorbuck, M. and Fierce Telecom, "Verizon: U.S. network
              usage starts to normalize as subscribers settle into new
              routines", April 2020,

Authors' Addresses

   Jake Holland
   Akamai Technologies, Inc.
   150 Broadway
   Cambridge, MA 02144,
   United States of America

   Email: jakeholland.net@gmail.com

   Ali Begen
   Networked Media

   Email: ali.begen@networked.media

   Spencer Dawkins
   Tencent America LLC
   United States of America

   Email: spencerdawkins.ietf@gmail.com

Holland, et al.          Expires 13 January 2021               [Page 13]

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