rfc9317.original.xml   rfc9317.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.15 (Ruby 3.1. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
2) --> -ietf-mops-streaming-opcons-12" number="9317" submissionType="IETF" category="in
<?rfc docmapping="yes"?> fo" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" updates=""
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft obsoletes="" xml:lang="en" version="3">
-ietf-mops-streaming-opcons-12" category="info" submissionType="IETF" tocInclude
="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.13.1 --> <!-- xml2rfc v2v3 conversion 3.13.1 -->
<front> <front>
<title abbrev="Media Streaming Ops">Operational Considerations for Streaming <title abbrev="Media Streaming Operations">Operational Considerations for St
Media</title> reaming Media</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-mops-streaming-opcons-12 <seriesInfo name="RFC" value="9317"/>
"/>
<author initials="J." surname="Holland" fullname="Jake Holland"> <author initials="J." surname="Holland" fullname="Jake Holland">
<organization>Akamai Technologies, Inc.</organization> <organization>Akamai Technologies, Inc.</organization>
<address> <address>
<postal> <postal>
<street>150 Broadway</street> <street>150 Broadway</street>
<city>Cambridge, MA 02144</city> <city>Cambridge</city>
<region>MA</region>
<code>02144</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>jakeholland.net@gmail.com</email> <email>jakeholland.net@gmail.com</email>
</address> </address>
</author> </author>
<author initials="A." surname="Begen" fullname="Ali Begen"> <author initials="A." surname="Begen" fullname="Ali Begen">
<organization>Networked Media</organization> <organization>Networked Media</organization>
<address> <address>
<postal> <postal>
<country>Turkey</country> <country>Turkey</country>
skipping to change at line 45 skipping to change at line 46
</author> </author>
<author initials="S." surname="Dawkins" fullname="Spencer Dawkins"> <author initials="S." surname="Dawkins" fullname="Spencer Dawkins">
<organization>Tencent America LLC</organization> <organization>Tencent America LLC</organization>
<address> <address>
<postal> <postal>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>spencerdawkins.ietf@gmail.com</email> <email>spencerdawkins.ietf@gmail.com</email>
</address> </address>
</author> </author>
<date year="2022" month="August" day="08"/> <date year="2022" month="October"/>
<area>OPS</area> <area>ops</area>
<workgroup>MOPS</workgroup> <workgroup>mops</workgroup>
<keyword>Internet-Draft</keyword> <keyword>DASH</keyword>
<keyword>HLS</keyword>
<keyword>ABR</keyword>
<keyword>adaptive streaming</keyword>
<keyword>live streaming</keyword>
<keyword>live latency</keyword>
<keyword>media transport</keyword>
<abstract> <abstract>
<t>This document provides an overview of operational networking and transp <t>This document provides an overview of operational networking and transp
ort protocol issues that pertain to the quality of experience when streaming vid ort protocol issues that pertain to the quality of experience (QoE) when streami
eo and other high-bitrate media over the Internet.</t> ng video and other high-bitrate media over the Internet.</t>
<t>This document is intended to explain the characteristics of streaming m <t>This document explains the characteristics of streaming
edia delivery that have surprised network designers or transport experts who lac media delivery that have surprised network designers or transport experts who
k specific media expertise, since streaming media highlights key differences bet lack specific media expertise, since streaming media highlights key differences
ween common assumptions in existing networking practices and observations of med between common assumptions in existing networking practices and observations of
ia delivery issues encountered when streaming media over those existing networks media delivery issues encountered when streaming media over those existing netw
.</t> orks.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t>This document provides an overview of operational networking and transp ort protocol issues that pertain to the quality of experience (QoE) when streami ng video and other high-bitrate media over the Internet.</t> <t>This document provides an overview of operational networking and transp ort protocol issues that pertain to the quality of experience (QoE) when streami ng video and other high-bitrate media over the Internet.</t>
<t>This document is intended to explain the characteristics of streaming m edia delivery that have surprised network designers or transport experts who lac k specific media expertise, since streaming media highlights key differences bet ween common assumptions in existing networking practices and observations of med ia delivery issues encountered when streaming media over those existing networks .</t> <t>This document is intended to explain the characteristics of streaming m edia delivery that have surprised network designers or transport experts who lac k specific media expertise, since streaming media highlights key differences bet ween common assumptions in existing networking practices and observations of med ia delivery issues encountered when streaming media over those existing networks .</t>
<section anchor="key-def"> <section anchor="key-def">
<name>Key Definitions</name> <name>Key Definitions</name>
<t>This document defines "high-bitrate streaming media over the Internet " as follows:</t> <t>This document defines "high-bitrate streaming media over the Internet " as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>"High-bitrate" is a context-sensitive term broadly intended to cap ture rates that can be sustained over some but not all of the target audience's network connections. A snapshot of values commonly qualifying as high-bitrate on today's Internet is given by the higher-value entries in <xref target="bvr"/>.< /li> <li>"High-bitrate" is a context-sensitive term broadly intended to cap ture rates that can be sustained over some but not all of the target audience's network connections. A snapshot of values commonly qualifying as high-bitrate on today's Internet is given by the higher-value entries in <xref target="bvr"/>.< /li>
<li> <li>
<t>"Streaming" means the continuous transmission of media segments f rom a server to a client and its simultaneous consumption by the client. <t>"Streaming" means the continuous transmission of media segments f rom a server to a client and its simultaneous consumption by the client.
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li>The term "simultaneous" is critical, as media segment transmis sion is not considered "streaming" if one downloads a media file and plays it af ter the download is completed. Instead, this would be called "download and play" .</li> <li>The term "simultaneous" is critical, as media segment transmis sion is not considered "streaming" if one downloads a media file and plays it af ter the download is completed. Instead, this would be called "download and play" .</li>
<li>This has two implications. First, the sending rate for media s egments must match the client's consumption rate (whether loosely or tightly) to provide uninterrupted playback. That is, the client must not run out of media s egments (buffer underrun), and must not accept more media segments than it can b uffer before playback (buffer overrun).</li> <li>This has two implications. First, the sending rate for media s egments must match the client's consumption rate (whether loosely or tightly) to provide uninterrupted playback. That is, the client must not run out of media s egments (buffer underrun) and must not accept more media segments than it can bu ffer before playback (buffer overrun).</li>
<li>Second, the client's media segment consumption rate is limited not only by the path's available bandwidth but also by media segment availabili ty. The client cannot fetch media segments that a media server cannot provide (y et).</li> <li>Second, the client's media segment consumption rate is limited not only by the path's available bandwidth but also by media segment availabili ty. The client cannot fetch media segments that a media server cannot provide (y et).</li>
</ul> </ul>
</li> </li>
<li>"Media" refers to any type of media and associated streams such as <li>"Media" refers to any type of media and associated streams, such a
video, audio, metadata, etc.</li> s video, audio, metadata, etc.</li>
<li>"Over the Internet" means that a single operator does not have con <li>"Over the Internet" means that a single operator does not have con
trol of the entire path between media servers and media clients, so not a "walle trol of the entire path between media servers and media clients, so it is not a
d garden".</li> "walled garden".</li>
</ul> </ul>
<t>This document uses these terms, to describe the streaming media ecosy stem:</t> <t>This document uses these terms to describe the streaming media ecosys tem:</t>
<dl> <dl>
<dt>Streaming Media Operator:</dt> <dt>Streaming Media Operator:</dt>
<dd> <dd>
<t>An entity that provides streaming media servers</t> <t>an entity that provides streaming media servers</t>
</dd> </dd>
<dt>Media Server:</dt> <dt>Media Server:</dt>
<dd> <dd>
<t>A server that provides streaming media to a media player</t> <t>a server that provides streaming media to a media player, which i
</dd> s
<dt/> also referred to as a streaming media server, or simply a server</t>
<dd>
<t>Also refered to as a streaming media server, or simply a server</
t>
</dd> </dd>
<dt>Intermediary:</dt> <dt>Intermediary:</dt>
<dd> <dd>
<t>An entity that is on-path, between the streaming media operator a <t>an entity that is on-path, between the streaming media operator a
nd the ultimate media consumer, and that is media-aware</t> nd the ultimate media consumer, and that is media aware</t>
</dd> <t>When the streaming media is encrypted, an intermediary must have
<dt/> credentials that allow the intermediary to decrypt the media in order to be medi
<dd> a aware.</t>
<t>When the streaming media is encrypted, an intermediary must have <t>An intermediary can be one of many specialized subtypes that meet
credentials that allow the intermediary to decrypt the media in order to be medi this definition.</t>
a-aware</t>
</dd>
<dt/>
<dd>
<t>An intermediary can be one of many specialized subtypes that meet
this definition</t>
</dd> </dd>
<dt>Media Player:</dt> <dt>Media Player:</dt>
<dd> <dd>
<t>An endpoint that requests streaming media from a media player for <t>an endpoint that requests streaming media from a media server for
an ultimate media consumer</t> an ultimate media consumer, which is also referred to as a streaming media clie
</dd> nt, or simply a client</t>
<dt/>
<dd>
<t>Also referred to as a streaming media client, or simply a client<
/t>
</dd> </dd>
<dt>Ultimate Media Consumer:</dt> <dt>Ultimate Media Consumer:</dt>
<dd> <dd>
<t>A human using a media player</t> <t>a human or machine using a media player</t>
</dd> </dd>
</dl> </dl>
</section> </section>
<section anchor="document-scope"> <section anchor="document-scope">
<name>Document Scope</name> <name>Document Scope</name>
<t>A full review of all streaming media considerations for all types of media over all types of network paths is too broad a topic to cover comprehensiv ely in a single document.</t> <t>A full review of all streaming media considerations for all types of media over all types of network paths is too broad a topic to cover comprehensiv ely in a single document.</t>
<t>This document focuses chiefly on the large-scale delivery of streamin g high-bitrate media to end users. <t>This document focuses chiefly on the large-scale delivery of streamin g high-bitrate media to end users.
It is primarily intended for those controlling endpoints involved in delivering streaming media traffic. It is primarily intended for those controlling endpoints involved in delivering streaming media traffic.
This can include origin servers publishing content, intermediaries like content delivery networks (CDNs), and providers for client devices and media players.</t > This can include origin servers publishing content, intermediaries like content delivery networks (CDNs), and providers for client devices and media players.</t >
<t>Most of the considerations covered in this document apply both to "li <t>Most of the considerations covered in this document apply to both "li
ve media" (created and streamed as an event is in progress) and "media on demand ve media" (created and streamed as an event is in progress) and "media on demand
" (previously recorded media that is streamed from storage), except where noted. " (previously recorded media that is streamed from storage), except where noted.
</t> </t>
<t>Most of the considerations covered in this document apply both to med <t>Most of the considerations covered in this document apply to both med
ia that is consumed by a media player, for viewing by a human, and media that is ia that is consumed by a media player, for viewing by a human, and media that is
consumed by a machine, such as a media recorder that is executing an ABR algori consumed by a machine, such as a media recorder that is executing an adaptive b
thm, except where noted.</t> itrate (ABR) streaming algorithm, except where noted.</t>
<t>This document contains</t> <t>This document contains</t>
<ul spacing="normal"> <ul spacing="normal">
<li>A short description of streaming video characteristics in <xref ta <li>a short description of streaming video characteristics in <xref ta
rget="sd"/>, to set the stage for the rest of the document,</li> rget="sd"/> to set the stage for the rest of the document,</li>
<li>General guidance on bandwidth provisioning (<xref target="bwprov"/ <li>general guidance on bandwidth provisioning (<xref target="bwprov"/
>) and latency considerations (<xref target="latency-cons"/>) for streaming medi >) and latency considerations (<xref target="latency-cons"/>) for streaming medi
a delivery,</li> a delivery,</li>
<li>A description of adaptive encoding and adaptive delivery technique <li>a description of adaptive encoding and adaptive delivery technique
s in common use for streaming video, along with a description of the challenges s in common use for streaming video, along with a description of the challenges
media senders face in detecting the bitrate available between the media sender a media senders face in detecting the bitrate available between the media sender a
nd media receiver, and collection of measurements by a third party for use in an nd media receiver, and a collection of measurements by a third party for use in
alytics (<xref target="sec-abr"/>),</li> analytics (<xref target="sec-abr"/>),</li>
<li>A description of existing transport protocols used for media strea <li>a description of existing transport protocols used for media strea
ming and the issues encountered when using those protocols, along with a descrip ming and the issues encountered when using those protocols, along with a descrip
tion of the QUIC transport protocol <xref target="RFC9000"/> more recently used tion of the QUIC transport protocol <xref target="RFC9000"/> more recently used
for streaming media (<xref target="sec-trans"/>),</li> for streaming media (<xref target="sec-trans"/>),</li>
<li>A description of implications when streaming encrypted media (<xre <li>a description of implications when streaming encrypted media (<xre
f target="stream-encrypt-media"/>), and</li> f target="stream-encrypt-media"/>), and</li>
<li>Several pointers for further reading on this rapidly changing subj <li>a pointer to additional resources for further reading on this rapi
ect (<xref target="further"/>).</li> dly changing subject (<xref target="further"/>).</li>
</ul> </ul>
<t>Topics outside this scope include:</t> <t>Topics outside this scope include the following:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>in-depth examination of real-time two-way interactive media, such as videoconferencing; although this document touches lightly on topics related t o this space, the intent is to let readers know that for more in-depth coverage, they should look to other documents, since the techniques and issues for intera ctive real-time two-way media differ so dramatically from those in large-scale o ne-way delivery of streaming media.</li> <li>an in-depth examination of real-time, two-way interactive media, s uch as videoconferencing; although this document touches lightly on topics relat ed to this space, the intent is to let readers know that for more in-depth cover age they should look to other documents, since the techniques and issues for int eractive real-time, two-way media differ so dramatically from those in large-sca le, one-way delivery of streaming media.</li>
<li>specific recommendations on operational practices to mitigate issu es described in this document; although some known mitigations are mentioned in passing, the primary intent is to provide a point of reference for future soluti on proposals to describe how new technologies address or avoid existing problems .</li> <li>specific recommendations on operational practices to mitigate issu es described in this document; although some known mitigations are mentioned in passing, the primary intent is to provide a point of reference for future soluti on proposals to describe how new technologies address or avoid existing problems .</li>
<li>generalized network performance techniques; while considerations s uch as datacenter design, transit network design, and "walled garden" optimizati ons can be crucial components of a performant streaming media service, these are considered independent topics better addressed by other documents.</li> <li>generalized network performance techniques; while considerations, such as data center design, transit network design, and "walled garden" optimiza tions, can be crucial components of a performant streaming media service, these are considered independent topics that are better addressed by other documents.< /li>
<li>transparent tunnels; while tunnels can have an impact on streaming media via issues like the round-trip time and the maximum transmission unit (MT U) of packets carried over tunnels, for the purposes of this document, these iss ues are considered as part of the set of network path properties.</li> <li>transparent tunnels; while tunnels can have an impact on streaming media via issues like the round-trip time and the maximum transmission unit (MT U) of packets carried over tunnels, for the purposes of this document, these iss ues are considered as part of the set of network path properties.</li>
</ul> </ul>
<t>It is worth pointing out explicitly because questions about "Web Real <t>Questions about whether this document also covers "Web Real-Time Comm
-Time Communication (WebRTC)" has come up often, that RTP, WebRTC's principal me unication (WebRTC)" have come up often. It does not. WebRTC’s principal media t
dia transport protocol (<xref target="RFC8834"/>, <xref target="RFC8835"/>), is ransport protocol <xref target="RFC8834"/> <xref target="RFC8835"/>, the Real-ti
mentioned in this document. However, (as noted in <xref target="sd"/>) it is di me Transport Protocol (RTP), is mentioned in this document. However, as noted in
fficult to give general guidance for unreliable media transport protocols used t <xref target="sd"/>, it is difficult to give general guidance for unreliable me
o carry interactive real-time media.</t> dia transport protocols used to carry interactive real-time media.</t>
</section>
<section anchor="notes-for-contributors-and-reviewers">
<name>Notes for Contributors and Reviewers</name>
<t>Note to RFC Editor: Please remove this section and its subsections
before publication.</t>
<t>This section is to provide references to make it easier to review the
development and discussion on the draft so far.</t>
<section anchor="venue">
<name>Venues for Contribution and Discussion</name>
<t>This document is in the GitHub repository at:</t>
<t><eref target="https://github.com/ietf-wg-mops/draft-ietf-mops-strea
ming-opcons">https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons</e
ref></t>
<t>Readers are welcome to open issues and send pull requests for this
document.</t>
<t>Substantial discussion of this document should take place on the MO
PS working group mailing list (mops@ietf.org).</t>
<ul spacing="normal">
<li>Join: <eref target="https://www.ietf.org/mailman/listinfo/mops">
https://www.ietf.org/mailman/listinfo/mops</eref></li>
<li>Search: <eref target="https://mailarchive.ietf.org/arch/browse/m
ops/">https://mailarchive.ietf.org/arch/browse/mops/</eref></li>
</ul>
</section>
</section> </section>
</section> </section>
<section anchor="sd"> <section anchor="sd">
<name>Our Focus on Streaming Video</name> <name>Our Focus on Streaming Video</name>
<t>As the Internet has grown, an increasingly large share of the traffic d elivered to end users has become video. <t>As the Internet has grown, an increasingly large share of the traffic d elivered to end users has become video.
The most recent available estimates found that 75% of the total traffic to end u sers was video in 2019 (as described in <xref target="RFC8404"/>, such traffic s urveys have since become impossible to conduct due to ubiquitous encryption). The most recent available estimates found that 75% of the total traffic to end users was video in 2019 (as described in <xref target="RFC8404"/>, such tra ffic surveys have since become impossible to conduct due to ubiquitous encryptio n).
At that time, the share of video traffic had been growing for years and was proj ected to continue growing (Appendix D of <xref target="CVNI"/>).</t> At that time, the share of video traffic had been growing for years and was proj ected to continue growing (Appendix D of <xref target="CVNI"/>).</t>
<t>A substantial part of this growth is due to the increased use of stream ing video. However, video traffic in real-time communications (for example, onli ne videoconferencing) has also grown significantly. <t>A substantial part of this growth is due to the increased use of stream ing video. However, video traffic in real-time communications (for example, onli ne videoconferencing) has also grown significantly.
While both streaming video and videoconferencing have real-time delivery and lat ency requirements, these requirements vary from one application to another. While both streaming video and videoconferencing have real-time delivery and lat ency requirements, these requirements vary from one application to another.
For additional discussion of latency requirements, see <xref target="latency-con s"/>.</t> For additional discussion of latency requirements, see <xref target="latency-con s"/>.</t>
<t>In many contexts, media traffic can be handled transparently as <t>In many contexts, media traffic can be handled transparently as
generic application-level traffic. However, as the volume of generic application-level traffic. However, as the volume of
media traffic continues to grow, it is becoming increasingly media traffic continues to grow, it is becoming increasingly
important to consider the effects of network design decisions important to consider the effects of network design decisions
on application-level performance, with considerations for on application-level performance, with considerations for
the impact on media delivery.</t> the impact on media delivery.</t>
<t>Much of the focus of this document is on media streaming over HTTP. HTT P is widely used for media streaming because</t> <t>Much of the focus of this document is on media streaming over HTTP. HTT P is widely used for media streaming because</t>
<ul spacing="normal"> <ul spacing="normal">
<li>support for HTTP is widely available in a wide range of operating sy stems,</li> <li>support for HTTP is widely available in a wide range of operating sy stems,</li>
<li>HTTP is also used in a wide variety of other applications,</li> <li>HTTP is also used in a wide variety of other applications,</li>
<li>HTTP has been demonstrated to provide acceptable performance over th e open Internet,</li> <li>HTTP has been demonstrated to provide acceptable performance over th e open Internet,</li>
<li>HTTP includes state-of-the-art standardized security mechanisms, and </li> <li>HTTP includes state-of-the-art standardized security mechanisms, and </li>
<li>HTTP can use already-deployed caching infrastructure such as content delivery networks (CDN), local proxies, and browser caches.</li> <li>HTTP can use already-deployed caching infrastructure, such as CDNs, local proxies, and browser caches.</li>
</ul> </ul>
<t>Various HTTP versions have been used for media delivery. HTTP/1.0, HTTP <t>Various HTTP versions have been used for media delivery. HTTP/1.0, HTTP
/1.1 and HTTP/2 are carried over TCP <xref target="I-D.ietf-tcpm-rfc793bis"/>, a /1.1, and HTTP/2 are carried over TCP <xref target="RFC9293"/>, and TCP's transp
nd TCP's transport behavior is described in <xref target="reliable-behavior"/>. ort behavior is described in <xref target="reliable-behavior"/>. HTTP/3 is carri
HTTP/3 is carried over QUIC, and QUIC's transport behavior is described in <xref ed over QUIC, and QUIC's transport behavior is described in <xref target="quic-b
target="quic-behavior"/>.</t> ehavior"/>.</t>
<t>Unreliable media delivery using RTP and other UDP-based protocols is al <t>Unreliable media delivery using RTP and other UDP-based protocols is al
so discussed in <xref target="ultralow"/>, <xref target="unreliable-behavior"/>, so discussed in Sections <xref target="ultralow" format="counter"/>, <xref targe
and <xref target="hop-by-hop-encrypt"/>, but it is difficult to give general gu t="unreliable-behavior" format="counter"/>, and <xref target="hop-by-hop-encrypt
idance for these applications. For instance, when packet loss occurs, the most a " format="counter"/>, but it is difficult to give general guidance for these app
ppropriate response may depend on the type of codec being used.</t> lications. For instance, when packet loss occurs, the most appropriate response
may depend on the type of codec being used.</t>
</section> </section>
<section anchor="bwprov"> <section anchor="bwprov">
<name>Bandwidth Provisioning</name> <name>Bandwidth Provisioning</name>
<section anchor="scaling"> <section anchor="scaling">
<name>Scaling Requirements for Media Delivery</name> <name>Scaling Requirements for Media Delivery</name>
<section anchor="bvr"> <section anchor="bvr">
<name>Video Bitrates</name> <name>Video Bitrates</name>
<t>Video bitrate selection depends on many variables including the res olution (height and width), frame rate, color depth, codec, encoding parameters, scene complexity and amount of motion. Generally speaking, as the resolution, f rame rate, color depth, scene complexity and amount of motion increase, the enco ding bitrate increases. As newer codecs with better compression tools are used, the encoding bitrate decreases. Similarly, a multi-pass encoding generally produ ces better quality output compared to single-pass encoding at the same bitrate o r delivers the same quality at a lower bitrate.</t> <t>Video bitrate selection depends on many variables including the res olution (height and width), frame rate, color depth, codec, encoding parameters, scene complexity, and amount of motion. Generally speaking, as the resolution, frame rate, color depth, scene complexity, and amount of motion increase, the en coding bitrate increases. As newer codecs with better compression tools are used , the encoding bitrate decreases. Similarly, a multi-pass encoding generally pro duces better quality output compared to single-pass encoding at the same bitrate or delivers the same quality at a lower bitrate.</t>
<t>Here are a few common resolutions used for video content, with typi cal ranges of bitrates for the two most popular video codecs <xref target="Encod ings"/>.</t> <t>Here are a few common resolutions used for video content, with typi cal ranges of bitrates for the two most popular video codecs <xref target="Encod ings"/>.</t>
<table> <table>
<name>Typical Resolutions and Bitrate Ranges Used for Video Encoding< /name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Width x Height</th> <th align="left">Width x Height</th>
<th align="left">H.264</th> <th align="left">H.264</th>
<th align="left">H.265</th> <th align="left">H.265</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
skipping to change at line 231 skipping to change at line 209
</tr> </tr>
<tr> <tr>
<td align="left">2160p (4k)</td> <td align="left">2160p (4k)</td>
<td align="left">3840 x 2160</td> <td align="left">3840 x 2160</td>
<td align="left">N/A</td> <td align="left">N/A</td>
<td align="left">10-20 Mbps</td> <td align="left">10-20 Mbps</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<ul spacing="normal"> <ul spacing="normal">
<li>Note that these codecs do not take the actual "available bandwid <li>Note that these codecs do not take the actual "available bandwid
th" between streaming video servers and streaming video receivers into account w th" between media servers and media players into account when encoding because t
hen encoding because the codec does not have any idea what network paths and net he codec does not have any idea what network paths and network path conditions w
work path conditions will carry the encoded video at some point in the future. I ill carry the encoded video at some point in the future. It is common for codecs
t is common for codecs to offer a small number of resource variants, differing o to offer a small number of resource variants, differing only in the bandwidth e
nly in the bandwidth each variant targets.</li> ach variant targets.</li>
<li>Note that video receivers attempting to receive encoded video ac <li>Note that media players attempting to receive encoded video acro
ross a network path with insufficient available path bandwidth might request the ss a network path with insufficient available path bandwidth might request the m
video server to provide video encoded for lower bitrates, at the cost of lower edia server to provide video encoded for lower bitrates, at the cost of lower vi
video quality, as described in <xref target="adapt-deliver"/>.</li> deo quality, as described in <xref target="adapt-deliver"/>.</li>
<li>In order to provide multiple encodings for video resources, the <li>In order to provide multiple encodings for video resources, the
codec must produce multiple versions of the video resource encoded at various bi codec must produce multiple variants (also called renditions) of the video resou
trates, as described in <xref target="adapt-encode"/>.</li> rce encoded at various bitrates, as described in <xref target="adapt-encode"/>.<
/li>
</ul> </ul>
</section> </section>
<section anchor="virtual-reality-bitrates"> <section anchor="virtual-reality-bitrates">
<name>Virtual Reality Bitrates</name> <name>Virtual Reality Bitrates</name>
<t>The bitrates given in <xref target="bvr"/> describe video streams t <t>The bitrates given in <xref target="bvr"/> describe video streams t
hat provide the user with a single, fixed point of view - so, the user has no "d hat provide the user with a single, fixed point of view -- therefore, the user h
egrees of freedom," and the user sees all of the video image that is available.< as no "degrees of freedom", and the user sees all of the video image that is ava
/t> ilable.</t>
<t>Even basic virtual reality (360-degree) videos that allow users to <t>Even basic virtual reality (360-degree) videos that allow users to
look around freely (referred to as "three degrees of freedom" or 3DoF) require s look around freely (referred to as "three degrees of freedom" or 3DoF) require s
ubstantially larger bitrates when they are captured and encoded as such videos r ubstantially larger bitrates when they are captured and encoded, as such videos
equire multiple fields of view of the scene. Yet, due to smart delivery methods require multiple fields of view of the scene. Yet, due to smart delivery methods
such as viewport-based or tile-based streaming, there is no need to send the who , such as viewport-based or tile-based streaming, there is no need to send the w
le scene to the user. Instead, the user needs only the portion corresponding to hole scene to the user. Instead, the user needs only the portion corresponding t
its viewpoint at any given time (<xref target="Survey360o"/>).</t> o its viewpoint at any given time <xref target="Survey360"/>.</t>
<t>In more immersive applications, where limited user movement ("three degrees of freedom plus" or 3DoF+) or full user movement ("six degrees of freed om" or 6DoF) is allowed, the required bitrate grows even further. In this case, immersive content is typically referred to as volumetric media. One way to repre sent the volumetric media is to use point clouds, where streaming a single objec t may easily require a bitrate of 30 Mbps or higher. Refer to <xref target="MPEG I"/> and <xref target="PCC"/> for more details.</t> <t>In more immersive applications, where limited user movement ("three degrees of freedom plus" or 3DoF+) or full user movement ("six degrees of freed om" or 6DoF) is allowed, the required bitrate grows even further. In this case, immersive content is typically referred to as volumetric media. One way to repre sent the volumetric media is to use point clouds, where streaming a single objec t may easily require a bitrate of 30 Mbps or higher. Refer to <xref target="MPEG I"/> and <xref target="PCC"/> for more details.</t>
</section> </section>
</section> </section>
<section anchor="sec-band-constraints"> <section anchor="sec-band-constraints">
<name>Path Bottlenecks and Constraints</name> <name>Path Bottlenecks and Constraints</name>
<t>Even when the bandwidth requirements for media streams along a path a re well understood, additional analysis is required to understand the constraint s on bandwidth at various points along the path between media servers and media players. Media streams can encounter bottlenecks at many points along a path, wh ether the bottleneck happens at a node or at a path segment along the path, and these bottlenecks may involve a lack of processing power, buffering capacity, li nk speed, or any other exhaustible resource.</t> <t>Even when the bandwidth requirements for media streams along a path a re well understood, additional analysis is required to understand the constraint s on bandwidth at various points along the path between media servers and media players. Media streams can encounter bottlenecks at many points along a path, wh ether the bottleneck happens at a node or at a path segment along the path, and these bottlenecks may involve a lack of processing power, buffering capacity, li nk speed, or any other exhaustible resource.</t>
<t>Media servers may react to bandwidth constraints using two independen t feedback loops:</t> <t>Media servers may react to bandwidth constraints using two independen t feedback loops:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Media servers often respond to application-level feedback from the <li>Media servers often respond to application-level feedback from the
media player that indicates a bottleneck somewhere along the path by adjusting media player that indicates a bottleneck somewhere along the path by sending a
the number of media segments that the media server will send to the media player different media bitrate. This is described in greater detail in <xref target="se
in a given timeframe. This is described in greater detail in <xref target="sec- c-abr"/>.</li>
abr"/>.</li> <li>Media servers also typically rely on transport protocols with capa
<li>Media servers also typically rely on transport protocols with capa city-seeking congestion controllers that probe for available path bandwidth and
city-seeking congestion controllers that probe for available path bandwidth and adjust the media sending rate based on transport mechanisms. This is described i
adjust the media segment sending rate based on transport mechanisms. This is des n greater detail in <xref target="sec-trans"/>.</li>
cribed in greater detail in <xref target="sec-trans"/>.</li>
</ul> </ul>
<t>The result is that these two (potentially competing) "helpful" mechan isms each respond to the same bottleneck with no coordination between themselves , so that each is unaware of actions taken by the other, and this can result in QoE for users that is significantly lower than what could have been achieved.</t > <t>The result is that these two (potentially competing) "helpful" mechan isms each respond to the same bottleneck with no coordination between themselves , so that each is unaware of actions taken by the other, and this can result in QoE for users that is significantly lower than what could have been achieved.</t >
<t>One might wonder why media servers and transport protocols are each u naware of what the other is doing, and there are multiple reasons for that. One reason is that media servers are often implemented as applications executing in user space, relying on a general-purpose operating system that typically has its transport protocols implemented in the operating system kernel, making decision s that the media server never knows about.</t> <t>One might wonder why media servers and transport protocols are each u naware of what the other is doing, and there are multiple reasons for that. One reason is that media servers are often implemented as applications executing in user space, relying on a general-purpose operating system that typically has its transport protocols implemented in the operating system kernel, making decision s that the media server never knows about.</t>
<t>In one example, if a media server overestimates the available bandwid th to the media player,</t> <t>As one example, if a media server overestimates the available bandwid th to the media player,</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the transport protocol may detect loss due to congestion and reduc e its sending window size per round trip,</li> <li>the transport protocol may detect loss due to congestion and reduc e its sending window size per round trip,</li>
<li>the media server adapts to application-level feedback from the med <li>the media server adapts to application-level feedback from the med
ia player and reduces its own sending rate,</li> ia player and reduces its own sending rate, and/or</li>
<li>the transport protocol sends media segments at the new, lower rate <li>the transport protocol sends media at the new, lower rate and conf
and confirms that this new, lower rate is "safe" because no transport-level los irms that this new, lower rate is "safe" because no transport-level loss is occu
s is occurring, but</li> rring.</li>
<li>because the media server continues to send at the new, lower rate,
the transport protocol's maximum sending rate is now limited by the amount of i
nformation the media server queues for transmission, so</li>
<li>the transport protocol cannot probe for available path bandwidth b
y sending at a higher rate until the media receiver requests segments that buffe
r enough data for the transport to perform the probing.</li>
</ul> </ul>
<t>However, because the media server continues to send at the new, lower
rate,
the transport protocol's maximum sending rate is now limited by the amount
of information the media server queues for transmission. Therefore, the
transport protocol cannot probe for available path bandwidth by sending
at a higher rate until the media player requests segments that buffer
enough data for the transport to perform the probing.</t>
<t>To avoid these types of situations, which can potentially affect all the users whose streaming media segments traverse a bottleneck path segment, the re are several possible mitigations that streaming operators can use. However, t he first step toward mitigating a problem is knowing that a problem is occurring .</t> <t>To avoid these types of situations, which can potentially affect all the users whose streaming media segments traverse a bottleneck path segment, the re are several possible mitigations that streaming operators can use. However, t he first step toward mitigating a problem is knowing that a problem is occurring .</t>
<section anchor="sec-know-your-traffic"> <section anchor="sec-know-your-traffic">
<name>Recognizing Changes from a Baseline</name> <name>Recognizing Changes from a Baseline</name>
<t>There are many reasons why path characteristics might change in nor mal operation, for example:</t> <t>There are many reasons why path characteristics might change in nor mal operation. For example:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>If the path topology changes. For example, routing changes, whic <li>If the path topology changes. For example, routing changes, whic
h can happen in normal operation, may result in traffic being carried over a new h can happen in normal operation, may result in traffic being carried over a new
path topology that that is partially or entirely disjoint from the previous pat path topology that is partially or entirely disjointed from the previous path,
h, especially if the new path topology includes one or more path segments that a especially if the new path topology includes one or more path segments that are
re more heavily loaded, offer lower total bandwidth, change the overall Path MTU more heavily loaded, offer lower total bandwidth, change the overall Path MTU si
size, or simply cover more distance between the path endpoints.</li> ze, or simply cover more distance between the path endpoints.</li>
<li>If cross traffic that also traverses part or all of the same pat <li>If cross traffic that also traverses part or all of the same pat
h topology increases or decreases, especially if this new cross traffic is "inel h topology increases or decreases, especially if this new cross traffic is "inel
astic," and does not respond to indications of path congestion.</li> astic" and does not respond to indications of path congestion.</li>
<li>Wireless links (Wi-Fi, 5G, LTE, etc.) may see rapid changes to c apacity from changes in radio interference and signal strength as endpoints move .</li> <li>Wireless links (Wi-Fi, 5G, LTE, etc.) may see rapid changes to c apacity from changes in radio interference and signal strength as endpoints move .</li>
</ul> </ul>
<t>To recognize that a path carrying streaming media segments has expe rienced a change, maintaining a baseline that captures its prior properties is f undamental. <t>To recognize that a path carrying streaming media has experienced a change, maintaining a baseline that captures its prior properties is fundamenta l.
Analytics that aid in that recognition can be more or less sophisticated and can usefully operate on several different time scales, from milliseconds to hours o r days.</t> Analytics that aid in that recognition can be more or less sophisticated and can usefully operate on several different time scales, from milliseconds to hours o r days.</t>
<t>Useful properties to monitor for changes can include:</t> <t>Useful properties to monitor for changes can include the following: </t>
<ul spacing="normal"> <ul spacing="normal">
<li>round-trip times</li> <li>round-trip times</li>
<li>loss rate (and explicit congestion notification (ECN) (<xref tar get="RFC3168"/> when in use)</li> <li>loss rate (and explicit congestion notification (ECN) <xref targ et="RFC3168"/> when in use)</li>
<li>out-of-order packet rate</li> <li>out-of-order packet rate</li>
<li>packet and byte receive rate</li> <li>packet and byte receive rate</li>
<li>application level goodput</li> <li>application-level goodput</li>
<li>properties of other connections carrying competing traffic, in a <li>properties of other connections carrying competing traffic, in a
ddition to the connections carrying the streaming media segments</li> ddition to the connections carrying the streaming media</li>
<li>externally provided measurements, for example, from network card s or metrics collected by the operating system</li> <li>externally provided measurements, for example, from network card s or metrics collected by the operating system</li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="pathreq"> <section anchor="pathreq">
<name>Path Requirements</name> <name>Path Requirements</name>
<t>The bitrate requirements in <xref target="scaling"/> are per end user actively <t>The bitrate requirements in <xref target="scaling"/> are per end user actively
consuming a media feed, so in the worst case, the bitrate demands 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 can be multiplied by the number of simultaneous users to find the bandwidth
requirements for a delivery path with that requirements for a delivery path with that
skipping to change at line 306 skipping to change at line 288
provisioning requirements for the network by performing some kind provisioning requirements for the network by performing some kind
of replication within the network. This can be achieved via object of replication within the network. This can be achieved via object
caching with the delivery of replicated objects over individual caching with the delivery of replicated objects over individual
connections and/or by packet-level replication using multicast.</t> connections and/or by packet-level replication using multicast.</t>
<t>To the extent that replication of popular content can be performed, <t>To the extent that replication of popular content can be performed,
bandwidth requirements at peering or ingest points can be reduced to bandwidth requirements at peering or ingest points can be reduced to
as low as a per-feed requirement instead of a per-user requirement.</t> as low as a per-feed requirement instead of a per-user requirement.</t>
</section> </section>
<section anchor="caching"> <section anchor="caching">
<name>Caching Systems</name> <name>Caching Systems</name>
<t>When demand for content is relatively predictable, and especially whe <t>When demand for content is relatively predictable, and especially whe
n that content is relatively static, caching content close to requesters and pre n that content is relatively static, caching content close to requesters and pre
-loading caches to respond quickly to initial requests is often useful (for exam loading caches to respond quickly to initial requests are often useful (for exam
ple, HTTP/1.1 caching is described in <xref target="RFC9111"/>). This is subject ple, HTTP/1.1 caching is described in <xref target="RFC9111"/>). This is subject
to the usual considerations for caching - for example, how much data must be ca to the usual considerations for caching -- for example, how much data must be c
ched to make a significant difference to the requester and how the benefit of ca ached to make a significant difference to the requester and how the benefit of c
ching and pre-loading caches balances against the costs of tracking stale conten aching and preloading cache balances against the costs of tracking stale content
t in caches and refreshing that content.</t> in caches and refreshing that content.</t>
<t>It is worth noting that not all high-demand content is "live" content <t>It is worth noting that not all high-demand content is "live" content
. One relevant example is when popular streaming content can be staged close to . One relevant example is when popular streaming content can be staged close to
a significant number of requesters, as can happen when a new episode of a popula a significant number of requesters, as can happen when a new episode of a popula
r show is released. This content may be largely stable, so low-cost to maintain r show is released. This content may be largely stable and is therefore low-cost
in multiple places throughout the Internet. This can reduce demands for high end to maintain in multiple places throughout the Internet. This can reduce demands
-to-end bandwidth without having to use mechanisms like multicast.</t> for high end-to-end bandwidth without having to use mechanisms like multicast.<
<t>Caching and pre-loading can also reduce exposure to peering point con /t>
gestion, since less traffic crosses the peering point exchanges if the caches ar <t>Caching and preloading can also reduce exposure to peering point cong
e placed in peer networks. This is especially true when the content can be pre-l estion, since less traffic crosses the peering point exchanges if the caches are
oaded during off-peak hours, and if the transfer can make use of "Lower-Effort P placed in peer networks. This is especially true when the content can be preloa
er-Hop Behavior (LE PHB) for Differentiated Services" <xref target="RFC8622"/>, ded during off-peak hours and if the transfer can make use of "A Lower-Effort Pe
"Low Extra Delay Background Transport (LEDBAT)" <xref target="RFC6817"/>, or sim r-Hop Behavior (LE PHB) for Differentiated Services" <xref target="RFC8622"/>, "
ilar mechanisms.</t> Low Extra Delay Background Transport (LEDBAT)" <xref target="RFC6817"/>, or simi
lar mechanisms.</t>
<t>All of this depends, of course, on the ability of a streaming media o perator to predict usage and provision bandwidth, caching, and other mechanisms to meet the needs of users. In some cases (<xref target="sec-predict"/>), this is relatively routine, but in other cases, it is more difficult (<xref target="s ec-unpredict"/>).</t> <t>All of this depends, of course, on the ability of a streaming media o perator to predict usage and provision bandwidth, caching, and other mechanisms to meet the needs of users. In some cases (<xref target="sec-predict"/>), this is relatively routine, but in other cases, it is more difficult (<xref target="s ec-unpredict"/>).</t>
<t>With the emergence of ultra-low-latency streaming, responses have to start streaming to the end user while still being transmitted to the cache, and while the cache does not yet know the size of the object. Some of the popular c aching systems were designed around cache footprint and had deeply ingrained ass umptions about knowing the size of objects that are being stored, so the change in design requirements in long-established systems caused some errors in product ion. Incidents occurred where a transmission error in the connection from the u pstream source to the cache could result in the cache holding a truncated segmen t and transmitting it to the end user's device. In this case, players rendering the stream often had a playback freeze until the player was reset. In some case s, the truncated object was even cached that way and served later to other playe rs as well, causing continued stalls at the same spot in the media for all playe rs playing the segment delivered from that cache node.</t> <t>With the emergence of ultra-low-latency streaming, responses have to start streaming to the end user while still being transmitted to the cache and w hile the cache does not yet know the size of the object. Some of the popular ca ching systems were designed around a cache footprint and had deeply ingrained as sumptions about knowing the size of objects that are being stored, so the change in design requirements in long-established systems caused some errors in produc tion. Incidents occurred where a transmission error in the connection from the upstream source to the cache could result in the cache holding a truncated segme nt and transmitting it to the end user's device. In this case, players rendering the stream often had a playback freeze until the player was reset. In some cas es, the truncated object was even cached that way and served later to other play ers as well, causing continued stalls at the same spot in the media for all play ers playing the segment delivered from that cache node.</t>
</section> </section>
<section anchor="sec-predict"> <section anchor="sec-predict">
<name>Predictable Usage Profiles</name> <name>Predictable Usage Profiles</name>
<t>Historical data shows that users consume more videos and these videos are encoded at a bitrate higher than they were in the past. Improvements in the codecs that help reduce the encoding bitrates with better compression algorithm s have not offset the increase in the demand for the higher quality video (highe r resolution, higher frame rate, better color gamut, better dynamic range, etc.) . In particular, mobile data usage in cellular access networks has shown a large jump over the years due to increased consumption of entertainment and conversat ional video.</t> <t>Historical data shows that users consume more videos, and these video s are encoded at a bitrate higher than they were in the past. Improvements in th e codecs that help reduce the encoding bitrates with better compression algorith ms have not offset the increase in the demand for the higher quality video (high er resolution, higher frame rate, better color gamut, better dynamic range, etc. ). In particular, mobile data usage in cellular access networks has shown a larg e jump over the years due to increased consumption of entertainment and conversa tional video.</t>
</section> </section>
<section anchor="sec-unpredict"> <section anchor="sec-unpredict">
<name>Unpredictable Usage Profiles</name> <name>Unpredictable Usage Profiles</name>
<t>It is also possible for usage profiles to change significantly and su ddenly. These changes are more difficult to plan for, but at a minimum, recogniz ing that sudden changes are happening is critical.</t> <t>It is also possible for usage profiles to change significantly and su ddenly. These changes are more difficult to plan for, but at a minimum, recogniz ing that sudden changes are happening is critical.</t>
<t>Two examples are instructive.</t> <t>The two examples that follow are instructive.</t>
<section anchor="p2p"> <section anchor="p2p">
<name>Peer-to-peer Applications</name> <name>Peer-to-Peer Applications</name>
<t>In the first example, described in "Report from the IETF Workshop o <t>In the first example, described in "Report from the IETF Workshop o
n Peer-to-Peer (P2P) Infrastructure, May 28, 2008" (<xref target="RFC5594"/>), w n Peer-to-Peer (P2P) Infrastructure, May 28, 2008" <xref target="RFC5594"/>, whe
hen the BitTorrent filesharing application came into widespread use in 2005, sud n the BitTorrent file sharing application came into widespread use in 2005, sudd
den and unexpected growth in peer-to-peer traffic led to complaints from ISP cus en and unexpected growth in peer-to-peer traffic led to complaints from ISP cust
tomers about the performance of delay-sensitive traffic (VoIP and gaming). These omers about the performance of delay-sensitive traffic (Voice over IP (VoIP) and
performance issues resulted from at least two causes:</t> gaming). These performance issues resulted from at least two causes:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Many access networks for end users used underlying technologies <li>Many access networks for end users used underlying technologies
that are inherently asymmetric, favoring downstream bandwidth (e.g., ADSL, cellu that are inherently asymmetric, favoring downstream bandwidth (e.g., ADSL, cellu
lar technologies, most IEEE 802.11 variants), assuming that most users will need lar technologies, and most IEEE 802.11 variants), assuming that most users will
more downstream bandwidth than upstream bandwidth. This is a good assumption fo need more downstream bandwidth than upstream bandwidth. This is a good assumptio
r client-server applications such as streaming media or software downloads, but n for client-server applications, such as streaming media or software downloads,
BitTorrent rewarded peers that uploaded as much as they downloaded, so BitTorren but BitTorrent rewarded peers that uploaded as much as they downloaded, so BitT
t users had much more symmetric usage profiles, which interacted badly with thes orrent users had much more symmetric usage profiles, which interacted badly with
e asymetric access network technologies.</li> these asymmetric access network technologies.</li>
<li>BitTorrent also used distributed hash tables to organize peers i <li>Some P2P systems also used distributed hash tables to organize p
nto a ring topology, where each peer knew its "next peer" and "previous peer." T eers into a ring topology, where each peer knew its "next peer" and "previous pe
here was no connection between the application-level ring topology and the lower er". There was no connection between the application-level ring topology and the
-level network topology, so a peer's "next peer" might be anywhere on the reacha lower-level network topology, so a peer's "next peer" might be anywhere on the
ble Internet. Traffic models that expected most communication to take place with reachable Internet. Traffic models that expected most communication to take plac
a relatively small number of servers were unable to cope with peer-to-peer traf e with a relatively small number of servers were unable to cope with peer-to-pee
fic that was much less predictable.</li> r traffic that was much less predictable.</li>
</ul> </ul>
<t>Especially, as end users increase the use of video-based social net working applications, it will be helpful for access network providers to watch f or increasing numbers of end users uploading significant amounts of content.</t> <t>Especially as end users increase the use of video-based social netw orking applications, it will be helpful for access network providers to watch fo r increasing numbers of end users uploading significant amounts of content.</t>
</section> </section>
<section anchor="impact-of-global-pandemic"> <section anchor="impact-of-global-pandemic">
<name>Impact of Global Pandemic</name> <name>Impact of Global Pandemic</name>
<t>Early in 2020, the COVID-19 pandemic and resulting quarantines and shutdowns led to significant changes in traffic patterns due to a large number o f people who suddenly started working and attending school remotely and using mo re interactive applications (videoconferencing, in addition to streaming media). Subsequently, the Internet Architecture Board (IAB) held a COVID-19 Network Imp acts Workshop <xref target="RFC9075"/> in November 2020. The following observati ons from the workshop report are worth considering.</t> <t>Early in 2020, the COVID-19 pandemic and resulting quarantines and shutdowns led to significant changes in traffic patterns due to a large number o f people who suddenly started working and attending school remotely and using mo re interactive applications (e.g., videoconferencing and streaming media). Subse quently, the Internet Architecture Board (IAB) held a COVID-19 Network Impacts W orkshop <xref target="RFC9075"/> in November 2020. The following observations fr om the workshop report are worth considering.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Participants describing different types of networks reported dif ferent kinds of impacts, but all types of networks saw impacts.</li> <li>Participants describing different types of networks reported dif ferent kinds of impacts, but all types of networks saw impacts.</li>
<li>Mobile networks saw traffic reductions and residential networks <li>Mobile networks saw traffic reductions, and residential networks
saw significant increases.</li> saw significant increases.</li>
<li>Reported traffic increases from ISPs and Internet Exchange Point <li>Reported traffic increases from ISPs and Internet Exchange Point
s (IXP) over just a few weeks were as big as the traffic growth over the course s (IXPs) over just a few weeks were as big as the traffic growth over the course
of a typical year, representing a 15-20% surge in growth to land at a new normal of a typical year, representing a 15-20% surge in growth to land at a new norma
that was much higher than anticipated.</li> l that was much higher than anticipated.</li>
<li>At DE-CIX Frankfurt, the world's largest IXP in terms of data th <li>At Deutscher Commercial Internet Exchange (DE-CIX) Frankfurt, th
roughput, the year 2020 has seen the largest increase in peak traffic within a s e world's largest IXP in terms of data throughput, the year 2020 has seen the la
ingle year since the IXP was founded in 1995.</li> rgest increase in peak traffic within a single year since the IXP was founded in
1995.</li>
<li>The usage pattern changed significantly as work-from-home and vi deoconferencing usage peaked during normal work hours, which would have typicall y been off-peak hours with adults at work and children at school. One might expe ct that the peak would have had more impact on networks if it had happened durin g typical evening peak hours for streaming applications.</li> <li>The usage pattern changed significantly as work-from-home and vi deoconferencing usage peaked during normal work hours, which would have typicall y been off-peak hours with adults at work and children at school. One might expe ct that the peak would have had more impact on networks if it had happened durin g typical evening peak hours for streaming applications.</li>
<li>The increase in daytime bandwidth consumption reflected both sig <li>The increase in daytime bandwidth consumption reflected both sig
nificant increases in essential applications such as videoconferencing and virtu nificant increases in essential applications, such as videoconferencing and virt
al private networks (VPN), and entertainment applications as people watched vide ual private networks (VPNs), and entertainment applications as people watched vi
os or played games.</li> deos or played games.</li>
<li>At the IXP level, it was observed that physical link utilization <li>At the IXP level, it was observed that physical link utilization
increased. This phenomenon could probably be explained by a higher level of unc increased. This phenomenon could probably be explained by a higher level of unc
acheable traffic such as videoconferencing and VPNs from residential users as th acheable traffic, such as videoconferencing and VPNs, from residential users as
ey stopped commuting and switched to work-at-home.</li> they stopped commuting and switched to working at home.</li>
</ul> </ul>
<t>Again, it will be helpful for streaming operators to monitor traffi c as described in <xref target="measure-coll"/>, watching for sudden changes in performance.</t> <t>Again, it will be helpful for streaming operators to monitor traffi c as described in <xref target="measure-coll"/>, watching for sudden changes in performance.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="latency-cons"> <section anchor="latency-cons">
<name>Latency Considerations</name> <name>Latency Considerations</name>
<t>Streaming media latency refers to the "glass-to-glass" time duration, w hich is the delay between the real-life occurrence of an event and the streamed media being appropriately displayed on an end user's device. Note that this is different from the network latency (defined as the time for a packet to cross a network from one end to another end) because it includes media encoding/decoding and buffering time, and for most cases also the ingest to an intermediate servi ce such as a CDN or other media distribution service, rather than a direct conne ction to an end user.</t> <t>Streaming media latency refers to the "glass-to-glass" time duration, w hich is the delay between the real-life occurrence of an event and the streamed media being appropriately played on an end user's device. Note that this is dif ferent from the network latency (defined as the time for a packet to cross a net work from one end to another end) because it includes media encoding/decoding an d buffering time and, for most cases, also the ingest to an intermediate service , such as a CDN or other media distribution service, rather than a direct connec tion to an end user.</t>
<t>The team working on this document found these rough categories to be us eful when considering a streaming media application's latency requirements:</t> <t>The team working on this document found these rough categories to be us eful when considering a streaming media application's latency requirements:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>ultra-low-latency (less than 1 second)</li> <li>ultra-low-latency (less than 1 second)</li>
<li>low-latency live (less than 10 seconds)</li> <li>low-latency live (less than 10 seconds)</li>
<li>non-low-latency live (10 seconds to a few minutes)</li> <li>non-low-latency live (10 seconds to a few minutes)</li>
<li>on-demand (hours or more)</li> <li>on-demand (hours or more)</li>
</ul> </ul>
<section anchor="ultralow"> <section anchor="ultralow">
<name>Ultra-Low-Latency</name> <name>Ultra-Low-Latency</name>
<t>Ultra-low-latency delivery of media is defined here as having a glass <t>Ultra-low-latency delivery of media is defined here as having a glass
-to-glass delay target under one second.</t> -to-glass delay target under 1 second.</t>
<t>Some media content providers aim to achieve this level of latency for <t>Some media content providers aim to achieve this level of latency for
live media events. This introduces new challenges when compared to the other la live media events. This introduces new challenges when compared to the other la
tency categories described in <xref target="latency-cons"/>, because ultra-low-l tency categories described in <xref target="latency-cons"/>, because ultra-low-l
atency is on the same scale as commonly observed end-to-end network latency vari atency is on the same scale as commonly observed end-to-end network latency vari
ation, often due to bufferbloat (<xref target="CoDel"/>), Wi-Fi error correction ation, often due to bufferbloat <xref target="CoDel"/>, Wi-Fi error correction,
, or packet reordering. These effects can make it difficult to achieve ultra-low or packet reordering. These effects can make it difficult to achieve ultra-low-l
-latency for many users, and may require accepting relatively frequent user-visi atency for many users and may require accepting relatively frequent user-visible
ble media artifacts. However, for controlled environments that provide mitigatio media artifacts. However, for controlled environments that provide mitigations
ns against such effects, ultra-low-latency is potentially achievable with the ri against such effects, ultra-low-latency is potentially achievable with the right
ght provisioning and the right media transport technologies.</t> provisioning and the right media transport technologies.</t>
<t>Most applications operating over IP networks and requiring latency th <t>Most applications operating over IP networks and requiring latency th
is low use the Real-time Transport Protocol (RTP) <xref target="RFC3550"/> or We is low use the Real-time Transport Protocol (RTP) <xref target="RFC3550"/> or We
bRTC <xref target="RFC8825"/>, which uses RTP as its Media Transport Protocol, a bRTC <xref target="RFC8825"/>, which uses RTP as its media transport protocol, a
long with several other protocols necessary for safe operation in browsers.</t> long with several other protocols necessary for safe operation in browsers.</t>
<t>Worth noting is that many applications for ultra-low-latency delivery <t>It is worth noting that many applications for ultra-low-latency deliv
do not need to scale to as many users as applications for low-latency and non-l ery do not need to scale to as many users as applications for low-latency and no
ow-latency live delivery, which simplifies many delivery considerations.</t> n-low-latency live delivery, which simplifies many delivery considerations.</t>
<t>Recommended reading for applications adopting an RTP-based approach a lso includes <xref target="RFC7656"/>. For increasing the robustness of the play back by implementing adaptive playout methods, refer to <xref target="RFC4733"/> and <xref target="RFC6843"/>.</t> <t>Recommended reading for applications adopting an RTP-based approach a lso includes <xref target="RFC7656"/>. For increasing the robustness of the play back by implementing adaptive playout methods, refer to <xref target="RFC4733"/> and <xref target="RFC6843"/>.</t>
<section anchor="near-realtime-latency"> <section anchor="near-realtime-latency">
<name>Near-Realtime Latency</name> <name>Near-Real-Time Latency</name>
<t>Some Internet applications that incorporate media streaming have sp <t>Some Internet applications that incorporate media streaming have sp
ecific interactivity or control-feedback requirements that drive much lower glas ecific interactivity or control-feedback requirements that drive much lower glas
s-to-glass media latency targets than one second. s-to-glass media latency targets than 1 second.
These include videoconferencing or voice calls, remote video gameplay, remote co These include videoconferencing or voice calls; remote video gameplay; remote co
ntrol of hardware platforms like drones, vehicles, or surgical robots and many o ntrol of hardware platforms like drones, vehicles, or surgical robots; and many
ther envisioned or deployed interactive applications.</t> other envisioned or deployed interactive applications.</t>
<t>Applications with latency targets in these regimes are out of scope for this document.</t> <t>Applications with latency targets in these regimes are out of scope for this document.</t>
</section> </section>
</section> </section>
<section anchor="low-latency-live"> <section anchor="low-latency-live">
<name>Low-Latency Live</name> <name>Low-Latency Live</name>
<t>Low-latency live delivery of media is defined here as having a glass- to-glass delay target under 10 seconds.</t> <t>Low-latency live delivery of media is defined here as having a glass- to-glass delay target under 10 seconds.</t>
<t>This level of latency is targeted to have a user experience similar t <t>This level of latency is targeted to have a user experience similar t
o broadcast TV delivery. A frequently cited problem with failing to achieve thi o broadcast TV delivery. A frequently cited problem with failing to achieve thi
s level of latency for live sporting events is the user experience failure from s level of latency for live sporting events is the user experience failure from
having crowds within earshot of one another who react audibly to an important pl having crowds within earshot of one another who react audibly to an important pl
ay, or from users who learn of an event in the match via some other channel, for ay or from users who learn of an event in the match via some other channel, for
example, social media, before it has happened on the screen showing the sportin example, social media, before it has happened on the screen showing the sporting
g event.</t> event.</t>
<t>Applications requiring low-latency live media delivery are generally <t>Applications requiring low-latency live media delivery are generally
feasible at scale with some restrictions. This typically requires the use of a feasible at scale with some restrictions. This typically requires the use of a
premium service dedicated to the delivery of live media, and some tradeoffs may premium service dedicated to the delivery of live media, and some trade-offs may
be necessary relative to what is feasible in a higher latency service. The trade be necessary relative to what is feasible in a higher-latency service. The trad
offs may include higher costs, delivering a lower quality media, reduced flexibi e-offs may include higher costs, delivering a lower quality media, reduced flexi
lity for adaptive bitrates or reduced flexibility for available resolutions so t bility for adaptive bitrates, or reduced flexibility for available resolutions s
hat fewer devices can receive an encoding tuned for their display. Low-latency l o that fewer devices can receive an encoding tuned for their display. Low-latenc
ive delivery is also more susceptible to user-visible disruptions due to transie y live delivery is also more susceptible to user-visible disruptions due to tran
nt network conditions than higher latency services.</t> sient network conditions than higher-latency services.</t>
<t>Implementation of a low-latency live media service can be achieved wi <t>Implementation of a low-latency live media service can be achieved wi
th the use of "HTTP Live Streaming (HLS)" <xref target="RFC8216"/> by using its th the use of HTTP Live Streaming (HLS) <xref target="RFC8216"/> by using its lo
low-latency extension (called LL-HLS) <xref target="I-D.draft-pantos-hls-rfc8216 w-latency extension (called LL-HLS) <xref target="HLS-RFC8216BIS"/> or with Dyna
bis"/> or with "Dynamic Adaptive Streaming over HTTP (DASH)" <xref target="MPEG- mic Adaptive Streaming over HTTP (DASH) <xref target="MPEG-DASH"/> by using its
DASH"/> by using its low-latency extension (called LL-DASH) <xref target="LL-DAS low-latency extension (called LL-DASH) <xref target="LL-DASH"/>. These extension
H"/>. These extensions use the Common Media Application Format (CMAF) standard < s use the Common Media Application Format (CMAF) standard <xref target="MPEG-CMA
xref target="MPEG-CMAF"/> that allows the media to be packaged into and transmit F"/> that allows the media to be packaged into and transmitted in units smaller
ted in units smaller than segments, which are called chunks in CMAF language. Th than segments, which are called "chunks" in CMAF language. This way, the latency
is way, the latency can be decoupled from the duration of the media segments. Wi can be decoupled from the duration of the media segments. Without a CMAF-like p
thout a CMAF-like packaging, lower latencies can only be achieved by using very ackaging, lower latencies can only be achieved by using very short segment durat
short segment durations. However, using shorter segments means using more freque ions. However, using shorter segments means using more frequent intra-coded fram
nt intra-coded frames and that is detrimental to video encoding quality. CMAF al es, and that is detrimental to video encoding quality. The CMAF standard allows
lows us to still use longer segments (improving encoding quality) without penali us to still use longer segments (improving encoding quality) without penalizing
zing latency.</t> latency.</t>
<t>While an LL-HLS client retrieves each chunk with a separate HTTP GET request, an LL-DASH client uses the chunked transfer encoding feature of the HTT P <xref target="CMAF-CTE"/>, which allows the LL-DASH client to fetch all the ch unks belonging to a segment with a single GET request. An HTTP server can transm it the CMAF chunks to the LL-DASH client as they arrive from the encoder/package r. A detailed comparison of LL-HLS and LL-DASH is given in <xref target="MMSP20" />.</t> <t>While an LL-HLS client retrieves each chunk with a separate HTTP GET request, an LL-DASH client uses the chunked transfer encoding feature of the HTT P <xref target="CMAF-CTE"/>, which allows the LL-DASH client to fetch all the ch unks belonging to a segment with a single GET request. An HTTP server can transm it the CMAF chunks to the LL-DASH client as they arrive from the encoder/package r. A detailed comparison of LL-HLS and LL-DASH is given in <xref target="MMSP20" />.</t>
</section> </section>
<section anchor="non-low-latency-live"> <section anchor="non-low-latency-live">
<name>Non-Low-Latency Live</name> <name>Non-Low-Latency Live</name>
<t>Non-low-latency live delivery of media is defined here as a livestrea <t>Non-low-latency live delivery of media is defined here as a live stre
m that does not have a latency target shorter than 10 seconds.</t> am that does not have a latency target shorter than 10 seconds.</t>
<t>This level of latency is the historically common case for segmented m <t>This level of latency is the historically common case for segmented m
edia delivery using HLS and DASH. This level of latency is often considered adeq edia delivery using HLS and DASH. This level of latency is often considered adeq
uate for content like news. This level of latency is also sometimes achieved as uate for content like news. This level of latency is also sometimes achieved as
a fallback state when some part of the delivery system or the client-side playe a fallback state when some part of the delivery system or the client-side playe
rs do not have the necessary support for the features necessary to support low-l rs do not support low-latency live streaming.</t>
atency live streaming.</t> <t>This level of latency can typically be achieved at scale with commodi
<t>This level of latency can typically be achieved at scale with commodi ty CDN services for HTTP(s) delivery, and in some cases, the increased time wind
ty CDN services for HTTP(s) delivery, and in some cases, the increased time wind ow can allow for the production of a wider range of encoding options relative to
ow can allow for the production of a wider range of encoding options relative to the requirements for a lower-latency service without the need for increasing th
the requirements for a lower latency service without the need for increasing th e hardware footprint, which can allow for wider device interoperability.</t>
e hardware footprint, which can allow for wider device interoperability.</t>
</section> </section>
<section anchor="on-demand"> <section anchor="on-demand">
<name>On-Demand</name> <name>On-Demand</name>
<t>On-demand media streaming refers to the playback of pre-recorded medi a based on a user's action. In some cases, on-demand media is produced as a by- product of a live media production, using the same segments as the live event, b ut freezing the manifest that describes the media available from the media serve r after the live event has finished. In other cases, on-demand media is constru cted out of pre-recorded assets with no streaming necessarily involved during th e production of the on-demand content.</t> <t>On-demand media streaming refers to the playback of pre-recorded medi a based on a user's action. In some cases, on-demand media is produced as a by- product of a live media production, using the same segments as the live event bu t freezing the manifest that describes the media available from the media server after the live event has finished. In other cases, on-demand media is construc ted out of pre-recorded assets with no streaming necessarily involved during the production of the on-demand content.</t>
<t>On-demand media generally is not subject to latency concerns, but oth er timing-related considerations can still be as important or even more importan t to the user experience than the same considerations with live events. These c onsiderations include the startup time, the stability of the media stream's play back quality, and avoidance of stalls and other media artifacts during the playb ack under all but the most severe network conditions.</t> <t>On-demand media generally is not subject to latency concerns, but oth er timing-related considerations can still be as important or even more importan t to the user experience than the same considerations with live events. These c onsiderations include the startup time, the stability of the media stream's play back quality, and avoidance of stalls and other media artifacts during the playb ack under all but the most severe network conditions.</t>
<t>In some applications, optimizations are available to on-demand media that are not always available to live events, such as pre-loading the first segm ent for a startup time that does not have to wait for a network download to begi n.</t> <t>In some applications, optimizations are available to on-demand media but are not always available to live events, such as preloading the first segmen t for a startup time that does not have to wait for a network download to begin. </t>
</section> </section>
</section> </section>
<section anchor="sec-abr"> <section anchor="sec-abr">
<name>Adaptive Encoding, Adaptive Delivery, and Measurement Collection</na me> <name>Adaptive Encoding, Adaptive Delivery, and Measurement Collection</na me>
<t>This section describes one of the best-known ways to provide a good use r experience over a given network path, but one thing to keep in mind is that ap plication-level mechanisms cannot provide a better experience than the underlyin g network path can support.</t> <t>This section describes one of the best-known ways to provide a good use r experience over a given network path, but one thing to keep in mind is that ap plication-level mechanisms cannot provide a better experience than the underlyin g network path can support.</t>
<section anchor="abr-overview"> <section anchor="abr-overview">
<name>Overview</name> <name>Overview</name>
<t>A simple model of media playback can be described as a media stream c onsumer, a buffer, and a transport mechanism that fills the buffer. <t>A simple model of media playback can be described as a media stream c onsumer, a buffer, and a transport mechanism that fills the buffer.
The consumption rate is fairly static and is represented by the content bitrate. The consumption rate is fairly static and is represented by the content bitrate.
The size of the buffer is also commonly a fixed size. The size of the buffer is also commonly a fixed size.
The buffer fill process needs to be at least fast enough to ensure that the buff er is never empty, however, it also can have significant complexity when things like personalization or advertising insertion workflows are introduced.</t> The buffer fill process needs to be at least fast enough to ensure that the buff er is never empty; however, it also can have significant complexity when things like personalization or advertising insertion workflows are introduced.</t>
<t>The challenges in filling the buffer in a timely way fall into two br oad categories:</t> <t>The challenges in filling the buffer in a timely way fall into two br oad categories:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Content selection comprises all of the steps needed to determine w <li>Content variation (also sometimes called a “bitrate ladder”) is th
hich content variation to offer the client.</li> e set of content renditions that are available at any given selection point.</li
<li>Content variation is the number of content options that exist at a >
ny given selection point.</li> <li>Content selection comprises all of the steps a client uses to dete
rmine which content rendition to play.</li>
</ul> </ul>
<t>The mechanism used to select the bitrate is part of the content selec <t>The mechanism used to select the bitrate is part of the content selec
tion, and the content variation are all of the different bitrate renditions.</t> tion, and the content variation is all of the different bitrate renditions.</t>
<t>Adaptive bitrate streaming ("ABR streaming", or simply "ABR") is a co <t>Adaptive bitrate streaming ("ABR streaming" or simply "ABR") is a
mmonly used technique for dynamically adjusting the compression level and media commonly used technique for dynamically adjusting the media quality of a stre
quality of a stream to match bandwidth availability. When this goal is achieved, am to match bandwidth availability. When this goal is achieved, the media server
the media server will tend to send enough media that the media player does not will tend to send enough
"stall", without sending so much media that the media player cannot accept it wi media that the media player does not "stall", without sending so much media t
thout exhausting all available receive buffers.</t> hat the media player cannot accept it.</t>
<t>ABR uses an application-level response strategy in which the streamin <t>ABR uses an application-level response strategy in which the streamin
g client attempts to detect the available bandwidth of the network path by first g client attempts to detect the available bandwidth of the network path by first
observing the successful application-layer download speed, and then, given the observing the successful application-layer download speed; then, given the avai
available bandwidth, the client chooses a bitrate for each of the video, audio, lable bandwidth, the client chooses a bitrate for each of the video, audio, subt
subtitles and metadata (among a limited number of available options for each typ itles, and metadata (among a limited number of available options for each type o
e of media) that fits within that bandwidth, typically adjusting as changes in a f media) that fits within that bandwidth, typically adjusting as changes in avai
vailable bandwidth occur in the network or changes in capabilities occur during lable bandwidth occur in the network or changes in capabilities occur during the
the playback (such as available memory, CPU, display size, etc.).</t> playback (such as available memory, CPU, display size, etc.).</t>
</section> </section>
<section anchor="adapt-encode"> <section anchor="adapt-encode">
<name>Adaptive Encoding</name> <name>Adaptive Encoding</name>
<t>Media servers can provide media streams at various bitrates because t he media has been encoded at various bitrates. This is a so-called "ladder" of b itrates that can be offered to media players as part of the manifest, so that th e media player can select among the available bitrate choices.</t> <t>Media servers can provide media streams at various bitrates because t he media has been encoded at various bitrates. This is a so-called "ladder" of b itrates that can be offered to media players as part of the manifest so that the media player can select among the available bitrate choices.</t>
<t>The media server may also choose to alter which bitrates are made ava ilable to players by adding or removing bitrate options from the ladder delivere d to the player in subsequent manifests built and sent to the player. This way, both the player, through its selection of bitrate to request from the manifest, and the server, through its construction of the bitrates offered in the manifest , are able to affect network utilization.</t> <t>The media server may also choose to alter which bitrates are made ava ilable to players by adding or removing bitrate options from the ladder delivere d to the player in subsequent manifests built and sent to the player. This way, both the player, through its selection of bitrate to request from the manifest, and the server, through its construction of the bitrates offered in the manifest , are able to affect network utilization.</t>
</section> </section>
<section anchor="adapt-deliver"> <section anchor="adapt-deliver">
<name>Adaptive Segmented Delivery</name> <name>Adaptive Segmented Delivery</name>
<t>Adaptive Segmented Delivery attempts to optimize its own use of the p <t>Adaptive segmented delivery attempts to optimize its own use of the p
ath between a media server and a media client. ABR playback is commonly implemen ath between a media server and a media client. ABR playback is commonly implemen
ted by streaming clients using HLS <xref target="RFC8216"/> or DASH <xref target ted by streaming clients using HLS <xref target="RFC8216"/> or DASH <xref target
="MPEG-DASH"/> to perform a reliable segmented delivery of media over HTTP. Diff ="MPEG-DASH"/> to perform a reliable segmented delivery of media over HTTP. Diff
erent implementations use different strategies <xref target="ABRSurvey"/>, often erent implementations use different strategies <xref target="ABRSurvey"/>, often
relying on proprietary algorithms (called rate adaptation or bitrate selection relying on proprietary algorithms (called rate adaptation or bitrate selection
algorithms) to perform available bandwidth estimation/prediction and the bitrate algorithms) to perform available bandwidth estimation/prediction and the bitrate
selection.</t> selection.</t>
<t>Many systems will do an initial probe or a very simple throughput spe <t>Many systems will do an initial probe or a very simple throughput spe
ed test at the start of media playback. This is done to get a rough sense of the ed test at the start of media playback. This is done to get a rough sense of the
highest (total) media bitrate that the network between the server and player wi highest (total) media bitrate that the network between the server and player wi
ll likely be able to provide under initial network conditions. After the initial ll likely be able to provide under initial network conditions. After the initial
testing, clients tend to rely upon passive network observations and will make u testing, clients tend to rely upon passive network observations and will make u
se of player side statistics such as buffer fill rates to monitor and respond to se of player-side statistics, such as buffer fill rates, to monitor and respond
changing network conditions.</t> to changing network conditions.</t>
<t>The choice of bitrate occurs within the context of optimizing for one <t>The choice of bitrate occurs within the context of optimizing for one
or more metrics monitored by the client, such as the highest achievable audiovi or more metrics monitored by the client, such as the highest achievable audiovi
sual quality or lowest chances for a rebuffering event (playback stall).</t> sual quality or the lowest chances for a rebuffering event (playback stall).</t>
</section> </section>
<section anchor="advertising"> <section anchor="advertising">
<name>Advertising</name> <name>Advertising</name>
<t>The inclusion of advertising alongside or interspersed with streaming media content is common in today's media landscape.</t> <t>The inclusion of advertising alongside or interspersed with streaming media content is common in today's media landscape.</t>
<t>Some commonly used forms of advertising can introduce potential user experience issues for a media stream. <t>Some commonly used forms of advertising can introduce potential user experience issues for a media stream.
This section provides a very brief overview of a complex and rapidly evolving sp ace.</t> This section provides a very brief overview of a complex and rapidly evolving sp ace.</t>
<t>The same techniques used to allow a media player to switch between re <t>The same techniques used to allow a media player to switch between re
nditions of different bitrates at segment or chunk boundaries can also be used t nditions of different bitrates at segment boundaries can also be used to enable
o enable the dynamic insertion of advertisements (hereafter referred to as "ads" the dynamic insertion of advertisements (hereafter referred to as "ads"), but th
), but this does not mean that the insertion of ads has no effect on the user's is does not mean that the insertion of ads has no effect on the user's quality o
quality of experience.</t> f experience.</t>
<t>Ads may be inserted either with Client-side Ad Insertion (CSAI) or Se <t>Ads may be inserted with either Client-side Ad Insertion (CSAI) or Se
rver-side Ad Insertion (SSAI). rver-side Ad Insertion (SSAI). In CSAI, the ABR manifest will generally include
- In CSAI, the ABR manifest will generally include links to an external ad serve links to an external ad server for some segments of the media stream, while in S
r for some segments of the media stream, while in SSAI the server will remain th SAI, the server will remain the same during ads but will include media segments
e same during advertisements, but will include media segments that contain the a that contain the advertising. In SSAI, the media segments may or may not be sour
dvertising. ced from an external ad server like with CSAI.</t>
- In SSAI, the media segments may or may not be sourced from an external ad serv
er like with CSAI.</t>
<t>In general, the more targeted the ad request is, the more requests th e ad service needs to be able to handle concurrently. <t>In general, the more targeted the ad request is, the more requests th e ad service needs to be able to handle concurrently.
If connectivity is poor to the ad service, this can cause rebuffering even if th e underlying media assets (both content and ads) can be accessed quickly. If connectivity is poor to the ad service, this can cause rebuffering even if th e underlying media assets (both content and ads) can be accessed quickly.
The less targeted the ad request is, the more likely that ad requests can be con The less targeted the ad request is, the more likely that ad requests can be con
solidated, and that ads can be cached similarly to the media content.</t> solidated and that ads can be cached similarly to the media content.</t>
<t>In some cases, especially with SSAI, advertising space in a stream is <t>In some cases, especially with SSAI, advertising space in a stream is
reserved for a specific advertiser and can be integrated with the video so that reserved for a specific advertiser and can be integrated with the video so that
the segments share the same encoding properties such as bitrate, dynamic range the segments share the same encoding properties, such as bitrate, dynamic range
and resolution. , and resolution.
However, in many cases, ad servers integrate with a Supply Side Platform (SSP) t However, in many cases, ad servers integrate with a Supply Side Platform (SSP) t
hat offers advertising space in real-time auctions via an Ad Exchange, with bids hat offers advertising space in real-time auctions via an Ad Exchange, with bids
for the advertising space coming from Demand Side Platforms (DSPs) that collect for the advertising space coming from Demand Side Platforms (DSPs) that collect
money from advertisers for delivering the advertisements. money from advertisers for delivering the ads.
Most such Ad Exchanges use application-level protocol specifications published b y the Interactive Advertising Bureau <xref target="IAB-ADS"/>, an industry trade organization.</t> Most such Ad Exchanges use application-level protocol specifications published b y the Interactive Advertising Bureau <xref target="IAB-ADS"/>, an industry trade organization.</t>
<t>This ecosystem balances several competing objectives and integrating with it naively can produce surprising user experience results. <t>This ecosystem balances several competing objectives, and integrating with it naively can produce surprising user experience results.
For example, ad server provisioning and/or the bitrate of the ad segments might be different from that of the main content, and either of these differences can result in playback stalls. For example, ad server provisioning and/or the bitrate of the ad segments might be different from that of the main content, and either of these differences can result in playback stalls.
For another example, since the inserted ads are often produced independently, th ey might have a different base volume level than the main content, which can mak e for a jarring user experience.</t> For another example, since the inserted ads are often produced independently, th ey might have a different base volume level than the main content, which can mak e for a jarring user experience.</t>
<t>Another major source of competing objectives comes from user privacy considerations vs. the advertiser's incentives to target ads to user segments ba sed on behavioral data. <t>Another major source of competing objectives comes from user privacy considerations vs. the advertiser's incentives to target ads to user segments ba sed on behavioral data.
Multiple studies, for example, <xref target="BEHAVE"/> and <xref target="BEHAVE2 "/>, have reported large improvements in ad effectiveness when using behaviorall y targeted ads, relative to untargeted ads. Multiple studies, for example, <xref target="BEHAVE"/> and <xref target="BEHAVE2 "/>, have reported large improvements in ad effectiveness when using behaviorall y targeted ads, relative to untargeted ads.
This provides a strong incentive for advertisers to gain access to the data nece ssary to perform behavioral targeting, leading some to engage in what is indisti nguishable from a pervasive monitoring attack (<xref target="RFC7258"/>) based o n user tracking in order to collect the relevant data, This provides a strong incentive for advertisers to gain access to the data nece ssary to perform behavioral targeting, leading some to engage in what is indisti nguishable from a pervasive monitoring attack <xref target="RFC7258"/> based on user tracking in order to collect the relevant data.
A more complete review of issues in this space is available in <xref target="BAL ANCING"/>.</t> A more complete review of issues in this space is available in <xref target="BAL ANCING"/>.</t>
<t>On top of these competing objectives, this market historically has ha d incidents of misreporting of ad delivery to end users for financial gain <xref target="ADFRAUD"/>. <t>On top of these competing objectives, this market historically has ha d incidents of misreporting of ad delivery to end users for financial gain <xref target="ADFRAUD"/>.
As a mitigation for concerns driven by those incidents, some SSPs have required the use of specific media players that include features like reporting of ad del ivery, or providing additional user information that can be used for tracking.</ t> As a mitigation for concerns driven by those incidents, some SSPs have required the use of specific media players that include features like reporting of ad del ivery or providing additional user information that can be used for tracking.</t >
<t>In general, this is a rapidly developing space with many consideratio ns, and media streaming operators engaged in advertising may need to research th ese and other concerns to find solutions that meet their user experience, user p rivacy, and financial goals. <t>In general, this is a rapidly developing space with many consideratio ns, and media streaming operators engaged in advertising may need to research th ese and other concerns to find solutions that meet their user experience, user p rivacy, and financial goals.
For further reading on mitigations, <xref target="BAP"/> has published some stan dards and best practices based on user experience research.</t> For further reading on mitigations, <xref target="BAP"/> has published some stan dards and best practices based on user experience research.</t>
</section> </section>
<section anchor="bitrate-detection-challenges"> <section anchor="bitrate-detection-challenges">
<name>Bitrate Detection Challenges</name> <name>Bitrate Detection Challenges</name>
<t>This kind of bandwidth-measurement system can experience trouble in s <t>This kind of bandwidth-measurement system can experience various
everal ways that are affected by networking and transport protocol issues. troubles that are affected by networking and transport protocol
issues.
Because adaptive application-level response strategies are often using rates as observed by the application layer, there are sometimes inscrutable transport-lev el protocol behaviors that can produce surprising measurement values when the ap plication-level feedback loop is interacting with a transport-level feedback loo p.</t> Because adaptive application-level response strategies are often using rates as observed by the application layer, there are sometimes inscrutable transport-lev el protocol behaviors that can produce surprising measurement values when the ap plication-level feedback loop is interacting with a transport-level feedback loo p.</t>
<t>A few specific examples of surprising phenomena that affect bitrate d etection measurements are described in the following subsections. <t>A few specific examples of surprising phenomena that affect bitrate d etection measurements are described in the following subsections.
As these examples will demonstrate, it is common to encounter cases that can del As these examples will demonstrate, it is common to encounter cases that can del
iver application-level measurements that are too low, too high, and (possibly) c iver application-level measurements that are too low, too high, and (possibly) c
orrect but varying more quickly than a lab-tested selection algorithm might expe orrect but that vary more quickly than a lab-tested selection algorithm might ex
ct.</t> pect.</t>
<t>These effects and others that cause transport behavior to diverge fro <t>These effects and others that cause transport behavior to diverge fro
m lab modeling can sometimes have a significant impact on bitrate selection and m lab modeling can sometimes have a significant impact on bitrate selection and
on user QoE, especially where players use naive measurement strategies and selec on user QoE, especially where players use naive measurement strategies and selec
tion algorithms that don't account for the likelihood of bandwidth measurements tion algorithms that do not account for the likelihood of bandwidth measurements
that diverge from the true path capacity.</t> that diverge from the true path capacity.</t>
<section anchor="idle-time"> <section anchor="idle-time">
<name>Idle Time between Segments</name> <name>Idle Time between Segments</name>
<t>When the bitrate selection is chosen substantially below the availa ble capacity of the network path, the response to a segment request will typical ly complete in much less absolute time than the duration of the requested segmen t, leaving significant idle time between segment downloads. This can have a few surprising consequences:</t> <t>When the bitrate selection is chosen substantially below the availa ble capacity of the network path, the response to a segment request will typical ly complete in much less absolute time than the duration of the requested segmen t, leaving significant idle time between segment downloads. This can have a few surprising consequences:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>TCP slow-start when restarting after idle requires multiple RTTs to re-establish a throughput at the network's available capacity. When the act ive transmission time for segments is substantially shorter than the time betwee n segments, leaving an idle gap between segments that triggers a restart of TCP slow-start, the estimate of the successful download speed coming from the applic ation-visible receive rate on the socket can thus end up much lower than the act ual available network capacity. This, in turn, can prevent a shift to the most appropriate bitrate. <xref target="RFC7661"/> provides some mitigations for this effect at the TCP transport layer for senders who anticipate a high incidence o f this problem.</li> <li>TCP slow-start, when restarting after idle, requires multiple RT Ts to re-establish a throughput at the network's available capacity. When the a ctive transmission time for segments is substantially shorter than the time betw een segments, leaving an idle gap between segments that triggers a restart of TC P slow-start, the estimate of the successful download speed coming from the appl ication-visible receive rate on the socket can thus end up much lower than the a ctual available network capacity. This, in turn, can prevent a shift to the mos t appropriate bitrate. <xref target="RFC7661"/> provides some mitigations for th is effect at the TCP transport layer for senders who anticipate a high incidence of this problem.</li>
<li>Mobile flow-bandwidth spectrum and timing mapping can be impacte d by idle time in some networks. The carrier capacity assigned to a physical or virtual link can vary with activity. Depending on the idle time characteristics, this can result in a lower available bitrate than would be achievable with a st eadier transmission in the same network.</li> <li>Mobile flow-bandwidth spectrum and timing mapping can be impacte d by idle time in some networks. The carrier capacity assigned to a physical or virtual link can vary with activity. Depending on the idle time characteristics, this can result in a lower available bitrate than would be achievable with a st eadier transmission in the same network.</li>
</ul> </ul>
<t>Some receiver-side ABR algorithms such as <xref target="ELASTIC"/>
are designed to try to avoid this effect.</t> <t>Some receiver-side ABR algorithms, such as <xref target="ELASTIC"/>
, are designed to try to avoid this effect.</t>
<t>Another way to mitigate this effect is by the help of two simultane ous TCP connections, as explained in <xref target="MMSys11"/> for Microsoft Smoo th Streaming. In some cases, the system-level TCP slow-start restart can also be disabled, for example, as described in <xref target="OReilly-HPBN"/>.</t> <t>Another way to mitigate this effect is by the help of two simultane ous TCP connections, as explained in <xref target="MMSys11"/> for Microsoft Smoo th Streaming. In some cases, the system-level TCP slow-start restart can also be disabled, for example, as described in <xref target="OReilly-HPBN"/>.</t>
</section> </section>
<section anchor="noisy-measurements"> <section anchor="noisy-measurements">
<name>Noisy Measurements</name> <name>Noisy Measurements</name>
<t>In addition to smoothing over an appropriate time scale to handle n etwork jitter (see <xref target="RFC5481"/>), ABR systems relying on measurement s at the application layer also have to account for noise from the in-order data transmission at the transport layer.</t> <t>In addition to smoothing over an appropriate time scale to handle n etwork jitter (see <xref target="RFC5481"/>), ABR systems relying on measurement s at the application layer also have to account for noise from the in-order data transmission at the transport layer.</t>
<t>For instance, in the event of a lost packet on a TCP connection wit h SACK <t>For instance, in the event of a lost packet on a TCP connection wit h SACK
support (a common case for segmented delivery in practice), loss support (a common case for segmented delivery in practice), loss
of a packet can provide a confusing bandwidth signal to the of a packet can provide a confusing bandwidth signal to the
receiving application. Because of the sliding window in TCP, receiving application. Because of the sliding window in TCP,
many packets may be accepted by the receiver without being available many packets may be accepted by the receiver without being available
skipping to change at line 486 skipping to change at line 471
available network bandwidth, this appears as a high jitter in available network bandwidth, this appears as a high jitter in
the goodput measurement, presenting as a stall followed by a sudden leap that ca n far exceed the actual the goodput measurement, presenting as a stall followed by a sudden leap that ca n far exceed the actual
capacity of the transport path from the server when the hole in capacity of the transport path from the server when the hole in
the received data is filled by a later retransmission.</t> the received data is filled by a later retransmission.</t>
</section> </section>
<section anchor="wide-and-rapid-variation-in-path-capacity"> <section anchor="wide-and-rapid-variation-in-path-capacity">
<name>Wide and Rapid Variation in Path Capacity</name> <name>Wide and Rapid Variation in Path Capacity</name>
<t>As many end devices have moved to wireless connections for the fina l hop (such as Wi-Fi, 5G, LTE, etc.), new problems in bandwidth detection have e merged.</t> <t>As many end devices have moved to wireless connections for the fina l hop (such as Wi-Fi, 5G, LTE, etc.), new problems in bandwidth detection have e merged.</t>
<t>In most real-world operating environments, wireless links can often experience sudden changes in capacity as the end user device moves from place t o place or encounters new sources of interference. <t>In most real-world operating environments, wireless links can often experience sudden changes in capacity as the end user device moves from place t o place or encounters new sources of interference.
Microwave ovens, for example, can cause a throughput degradation in Wi-Fi of mor e than a factor of 2 while active <xref target="Micro"/>.</t> Microwave ovens, for example, can cause a throughput degradation in Wi-Fi of mor e than a factor of 2 while active <xref target="Micro"/>.</t>
<t>These swings in actual transport capacity can result in user experi ence issues when interacting with ABR algorithms that aren't tuned to handle the capacity variation gracefully.</t> <t>These swings in actual transport capacity can result in user experi ence issues when interacting with ABR algorithms that are not tuned to handle th e capacity variation gracefully.</t>
</section> </section>
</section> </section>
<section anchor="measure-coll"> <section anchor="measure-coll">
<name>Measurement Collection</name> <name>Measurement Collection</name>
<t>Media players use measurements to guide their segment-by-segment adap <t>Media players use measurements to guide their segment-by-segment adap
tive streaming requests, but may also provide measurements to streaming media pr tive streaming requests but may also provide measurements to streaming media pro
oviders.</t> viders.</t>
<t>In turn, media providers may base analytics on these measurements to <t>In turn, media providers may base analytics on these measurements to
guide decisions such as whether adaptive encoding bitrates in use are the best o guide decisions, such as whether adaptive encoding bitrates in use are the best
nes to provide to media players, or whether current media content caching is pro ones to provide to media players or whether current media content caching is pro
viding the best experience for viewers.</t> viding the best experience for viewers.</t>
<t>To that effect, the Consumer Technology Association (CTA), who owns t he Web Application Video Ecosystem (WAVE) project, has published two important s pecifications.</t> <t>To that effect, the Consumer Technology Association (CTA), who owns t he Web Application Video Ecosystem (WAVE) project, has published two important s pecifications.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>CTA-2066: Streaming Quality of Experience Events, Properties and M etrics</li> <li>CTA-2066: Streaming Quality of Experience Events, Properties and M etrics</li>
</ul> </ul>
<t><xref target="CTA-2066"/> specifies a set of media player events, pro perties, QoE metrics and associated terminology for representing streaming media QoE across systems, media players and analytics vendors. While all these events , properties, metrics and associated terminology are used across a number of pro prietary analytics and measurement solutions, they were used in slightly (or vas tly) different ways that led to interoperability issues. CTA-2066 attempts to ad dress this issue by defining a common terminology as well as how each metric sho uld be computed for consistent reporting.</t> <t><xref target="CTA-2066"/> specifies a set of media player events, pro perties, QoE metrics, and associated terminology for representing streaming medi a QoE across systems, media players, and analytics vendors. While all these even ts, properties, metrics, and associated terminology are used across a number of proprietary analytics and measurement solutions, they were used in slightly (or vastly) different ways that led to interoperability issues. CTA-2066 attempts to address this issue by defining common terminology and how each metric should be computed for consistent reporting.</t>
<ul spacing="normal"> <ul spacing="normal">
<li>CTA-5004: Common Media Client Data (CMCD)</li> <li>CTA-5004: Web Application Video Ecosystem - Common Media Client Da ta (CMCD)</li>
</ul> </ul>
<t>Many assume that the CDNs have a holistic view of the health and perf ormance of the streaming clients. However, this is not the case. The CDNs produc e millions of log lines per second across hundreds of thousands of clients and t hey have no concept of a "session" as a client would have, so CDNs are decoupled from the metrics the clients generate and report. A CDN cannot tell which reque st belongs to which playback session, the duration of any media object, the bitr ate, or whether any of the clients have stalled and are rebuffering or are about to stall and will rebuffer. The consequence of this decoupling is that a CDN ca nnot prioritize delivery for when the client needs it most, prefetch content, or trigger alerts when the network itself may be underperforming. One approach to couple the CDN to the playback sessions is for the clients to communicate standa rdized media-relevant information to the CDNs while they are fetching data. <xre f target="CTA-5004"/> was developed exactly for this purpose.</t> <t>Many assume that the CDNs have a holistic view of the health and perf ormance of the streaming clients. However, this is not the case. The CDNs produc e millions of log lines per second across hundreds of thousands of clients, and they have no concept of a "session" as a client would have, so CDNs are decouple d from the metrics the clients generate and report. A CDN cannot tell which requ est belongs to which playback session, the duration of any media object, the bit rate, or whether any of the clients have stalled and are rebuffering or are abou t to stall and will rebuffer. The consequence of this decoupling is that a CDN c annot prioritize delivery for when the client needs it most, prefetch content, o r trigger alerts when the network itself may be underperforming. One approach to couple the CDN to the playback sessions is for the clients to communicate stand ardized media-relevant information to the CDNs while they are fetching data. <xr ef target="CTA-5004"/> was developed exactly for this purpose.</t>
</section> </section>
</section> </section>
<section anchor="sec-trans"> <section anchor="sec-trans">
<name>Transport Protocol Behaviors and Their Implications for Media Transp ort Protocols</name> <name>Transport Protocol Behaviors and Their Implications for Media Transp ort Protocols</name>
<t>Within this document, the term "Media Transport Protocol" is used to de scribe any protocol that carries media metadata and media segments in its payloa d, and the term "Transport Protocol" describes any protocol that carries a Media Transport Protocol, or another Transport Protocol, in its payload. This is easi er to understand if the reader assumes a protocol stack that looks something lik e this:</t> <t>Within this document, the term "media transport protocol" is used to de scribe any protocol that carries media metadata and media segments in its payloa d, and the term "transport protocol" describes any protocol that carries a media transport protocol, or another transport protocol, in its payload. This is easi er to understand if the reader assumes a protocol stack that looks something lik e this:</t>
<artwork><![CDATA[ <artwork><![CDATA[
Media Segments Media Segments
--------------------------- ---------------------------
Media Format Media Format
--------------------------- ---------------------------
Media Transport Protocol Media Transport Protocol
--------------------------- ---------------------------
Transport Protocol(s) Transport Protocol(s)
]]></artwork> ]]></artwork>
<t>where</t> <t>where</t>
<ul spacing="normal"> <ul spacing="normal">
<li>"Media Segments" would be something like the output of a codec, or s <li>"Media segments" would be something like the output of a codec or so
ome other source of media segments, such as closed-captioning,</li> me other source of media segments, such as closed-captioning,</li>
<li>"Media Format" would be something like an RTP payload format <xref t <li>"Media format" would be something like an RTP payload format <xref t
arget="RFC2736"/> or an ISOBMFF <xref target="ISOBMFF"/> profile,</li> arget="RFC2736"/> or an ISO base media file format (ISOBMFF) profile <xref targe
<li>"Media Transport Protocol" would be something like RTP <xref target= t="ISOBMFF"/>,</li>
"RFC3550"/> or DASH <xref target="MPEG-DASH"/>, and</li> <li>"Media transport protocol" would be something like RTP <xref target=
<li>"Transport Protocol" would be a protocol that provides appropriate t "RFC3550"/> or DASH <xref target="MPEG-DASH"/>, and</li>
ransport services, as described in Section 5 of <xref target="RFC8095"/>.</li> <li>"Transport protocol" would be a protocol that provides appropriate t
ransport services, as described in <xref target="RFC8095" sectionFormat="of" sec
tion="5"/>.</li>
</ul> </ul>
<t>Not all possible streaming media applications follow this model, but fo <t>Not all possible streaming media applications follow this model, but fo
r the ones that do, it seems useful to distinguish between the protocol layer th r the ones that do, it seems useful to distinguish between the protocol layer th
at is aware it is transporting media segments, and underlying protocol layers th at is aware it is transporting media segments and underlying protocol layers tha
at are not aware.</t> t are not aware.</t>
<t>As described in the <xref target="RFC8095"/> Abstract, the IETF has sta <t>As described in the abstract of <xref target="RFC8095"/>, the IETF has
ndardized a number of protocols that provide transport services. Although these standardized a number of protocols that provide transport services. Although the
protocols, taken in total, provide a wide variety of transport services, <xref t se protocols, taken in total, provide a wide variety of transport services, <xre
arget="sec-trans"/> will distinguish between two extremes:</t> f target="sec-trans"/> will distinguish between two extremes:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Transport protocols used to provide reliable, in-order media deliver <li>transport protocols used to provide reliable, in-order media deliver
y to an endpoint, typically providing flow control and congestion control (<xref y to an endpoint, typically providing flow control and congestion control (<xref
target="reliable-behavior"/>) and</li> target="reliable-behavior"/>), and</li>
<li>Transport protocols used to provide unreliable, unordered media deli <li>transport protocols used to provide unreliable, unordered media deli
very to an endpoint, without flow control or congestion control (<xref target="u very to an endpoint, without flow control or congestion control (<xref target="u
nreliable-behavior"/>).</li> nreliable-behavior"/>).</li>
</ul> </ul>
<t>Because newly standardized transport protocols such as QUIC <xref targe <t>Because newly standardized transport protocols, such as QUIC <xref targ
t="RFC9000"/> that are typically implemented in userspace can evolve their trans et="RFC9000"/>, that are typically implemented in user space can evolve their tr
port behavior more rapidly than currently-used transport protocols that are typi ansport behavior more rapidly than currently used transport protocols that are t
cally implemented in operating system kernel space, this document includes a des ypically implemented in operating system kernel space, this document includes a
cription of how the path characteristics that streaming media providers may see description of how the path characteristics that streaming media providers may s
are likely to evolve in <xref target="quic-behavior"/>.</t> ee are likely to evolve; see <xref target="quic-behavior"/>.</t>
<t>It is worth noting explicitly that the Transport Protocol layer might i <t>It is worth noting explicitly that the transport protocol layer might i
nclude more than one protocol. For example, a specific Media Transport Protocol nclude more than one protocol. For example, a specific media transport protocol
might run over HTTP, or over WebTransport, which in turn runs over HTTP.</t> might run over HTTP, or over WebTransport, which in turn runs over HTTP.</t>
<t>It is worth noting explicitly that more complex network protocol stacks <t>It is worth noting explicitly that more complex network protocol stacks
are certainly possible - for instance, when packets with this protocol stack ar are certainly possible -- for instance, when packets with this protocol stack a
e carried in a tunnel or in a VPN, the entire packet would likely appear in the re carried in a tunnel or in a VPN, the entire packet would likely appear in th
payload of other protocols. If these environments are present, streaming media e payload of other protocols. If these environments are present, streaming media
operators may need to analyze their effects on applications as well.</t> operators may need to analyze their effects on applications as well.</t>
<section anchor="reliable-behavior"> <section anchor="reliable-behavior">
<name>Media Transport Over Reliable Transport Protocols</name> <name>Media Transport over Reliable Transport Protocols</name>
<t>The HLS <xref target="RFC8216"/> and DASH <xref target="MPEG-DASH"/> media transport protocols are typically carried over HTTP, and HTTP has used TCP as its only standardized transport protocol until HTTP/3 <xref target="RFC9114" />. These media transport protocols use ABR response strategies as described in <xref target="sec-abr"/> to respond to changing path characteristics, and underl ying transport protocols are also attempting to respond to changing path charact eristics.</t> <t>The HLS <xref target="RFC8216"/> and DASH <xref target="MPEG-DASH"/> media transport protocols are typically carried over HTTP, and HTTP has used TCP as its only standardized transport protocol until HTTP/3 <xref target="RFC9114" />. These media transport protocols use ABR response strategies as described in <xref target="sec-abr"/> to respond to changing path characteristics, and underl ying transport protocols are also attempting to respond to changing path charact eristics.</t>
<t>The past success of the largely TCP-based Internet is evidence that t <t>The past success of the largely TCP-based Internet is evidence that t
he various flow control and congestion control mechanisms TCP has used to achiev he various flow control and congestion control mechanisms that TCP has used to a
e equilibrium quickly, at a point where TCP senders do not interfere with other chieve equilibrium quickly, at a point where TCP senders do not interfere with o
TCP senders for sustained periods of time (<xref target="RFC5681"/>), have been ther TCP senders for sustained periods of time <xref target="RFC5681"/>, have be
largely successful. The Internet has continued to work even when the specific TC en largely successful. The Internet has continued to work even when the specific
P mechanisms used to reach equilibrium changed over time (<xref target="RFC7414" TCP mechanisms used to reach equilibrium changed over time <xref target="RFC741
/>). Because TCP provided a common tool to avoid contention, even when significa 4"/>. Because TCP provided a common tool to avoid contention, even when signific
nt TCP-based applications like FTP were largely replaced by other significant TC ant TCP-based applications like FTP were largely replaced by other significant T
P-based applications like HTTP, the transport behavior remained safe for the Int CP-based applications like HTTP, the transport behavior remained safe for the In
ernet.</t> ternet.</t>
<t>Modern TCP implementations (<xref target="I-D.ietf-tcpm-rfc793bis"/>) <t>Modern TCP implementations <xref target="RFC9293"/> continue to probe
continue to probe for available bandwidth, and "back off" when a network path i for available bandwidth and "back off" when a network path is saturated but may
s saturated, but may also work to avoid growing queues along network paths, whic also work to avoid growing queues along network paths, which can prevent older
h can prevent older TCP senders from detecting quickly when a network path is be TCP senders from quickly detecting when a network path is becoming saturated. Co
coming saturated. Congestion control mechanisms such as COPA <xref target="COPA1 ngestion control mechanisms, such as Copa <xref target="COPA18"/> and Bottleneck
8"/> and BBR <xref target="I-D.cardwell-iccrg-bbr-congestion-control"/> make the Bandwidth and Round-trip propagation time (BBR) <xref target="I-D.cardwell-iccr
se decisions based on measured path delays, assuming that if the measured path d g-bbr-congestion-control"/>, make these decisions based on measured path delays,
elay is increasing, the sender is injecting packets onto the network path faster assuming that if the measured path delay is increasing, the sender is injecting
than the network can forward them (or the receiver can accept them) so the send packets onto the network path faster than the network can forward them (or the
er should adjust its sending rate accordingly.</t> receiver can accept them), so the sender should adjust its sending rate accordin
<t>Although common TCP behavior has changed significantly since the days gly.</t>
of <xref target="Jacobson-Karels"/> and <xref target="RFC2001"/>, even adding n <t>Although common TCP behavior has changed significantly since the days
ew congestion controllers such as CUBIC <xref target="RFC8312"/>, the common pra of <xref target="Jacobson-Karels"/> and <xref target="RFC2001"/>, even with add
ctice of implementing TCP as part of an operating system kernel has acted to lim ing new congestion controllers such as CUBIC <xref target="RFC8312"/>, the commo
it how quickly TCP behavior can change. Even with the widespread use of automate n practice of implementing TCP as part of an operating system kernel has acted t
d operating system update installation on many end-user systems, streaming media o limit how quickly TCP behavior can change. Even with the widespread use of aut
providers could have a reasonable expectation that they could understand TCP tr omated operating system update installation on many end-user systems, streaming
ansport protocol behaviors, and that those behaviors would remain relatively sta media providers could have a reasonable expectation that they could understand T
ble in the short term.</t> CP transport protocol behaviors and that those behaviors would remain relativel
y stable in the short term.</t>
</section> </section>
<section anchor="unreliable-behavior"> <section anchor="unreliable-behavior">
<name>Media Transport Over Unreliable Transport Protocols</name> <name>Media Transport over Unreliable Transport Protocols</name>
<t>Because UDP does not provide any feedback mechanism to senders to hel <t>Because UDP does not provide any feedback mechanism to senders to hel
p limit impacts on other users, UDP-based application-level protocols have been p limit impacts on other users, UDP-based application-level protocols have been
responsible for the decisions that TCP-based applications have delegated to TCP responsible for the decisions that TCP-based applications have delegated to TCP,
- what to send, how much to send, and when to send it. Because UDP itself has no i.e., what to send, how much to send, and when to send it. Because UDP itself h
transport-layer feedback mechanisms, UDP-based applications that send and recei as no transport-layer feedback mechanisms, UDP-based applications that send and
ve substantial amounts of information are expected to provide their own feedback receive substantial amounts of information are expected to provide their own fee
mechanisms, and to respond to the feedback the application receives. This expec dback mechanisms and to respond to the feedback the application receives. This e
tation is most recently codified as a Best Current Practice <xref target="RFC808 xpectation is most recently codified as a Best Current Practice <xref target="RF
5"/>.</t> C8085"/>.</t>
<t>In contrast to adaptive segmented delivery over a reliable transport <t>In contrast to adaptive segmented delivery over a reliable transport
as described in <xref target="adapt-deliver"/>, some applications deliver stream as described in <xref target="adapt-deliver"/>, some applications deliver stream
ing media segments using an unreliable transport, and rely on a variety of appro ing media segments using an unreliable transport and rely on a variety of approa
aches, including:</t> ches, including:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>raw MPEG Transport Stream ("MPEG-TS")-formatted media <xref target ="MPEG-TS"/> over UDP, which makes no attempt to account for reordering or loss in the transport,</li> <li>media encapsulated in a raw MPEG Transport Stream (MPEG-TS) <xref target="MPEG-TS"/> over UDP, which makes no attempt to account for reordering or loss in the transport,</li>
<li>RTP <xref target="RFC3550"/>, which can notice packet loss and rep air some limited reordering,</li> <li>RTP <xref target="RFC3550"/>, which can notice packet loss and rep air some limited reordering,</li>
<li>SCTP <xref target="RFC9260"/>, which can use partial reliability < <li>the Stream Control Transmission Protocol (SCTP) <xref target="RFC9
xref target="RFC3758"/> to recover from some loss, but can abandon recovery to l 260"/>, which can use partial reliability <xref target="RFC3758"/> to recover fr
imit head-of-line blocking, and</li> om some loss but can abandon recovery to limit head-of-line blocking, and</li>
<li>SRT <xref target="SRT"/>, which can use forward error correction a <li>the Secure Reliable Transport (SRT) <xref target="SRT"/>, which ca
nd time-bound retransmission to recover from loss within certain limits, but can n use forward error correction and time-bound retransmission to recover from los
abandon recovery to limit head-of-line blocking.</li> s within certain limits but can abandon recovery to limit head-of-line blocking.
</li>
</ul> </ul>
<t>Under congestion and loss, approaches like the above generally experi <t>Under congestion and loss, approaches like the above generally experi
ence transient media artifacts more often and delay of playback effects less oft ence transient media artifacts more often and delay of playback effects less oft
en, as compared with reliable segment transport. Often one of the key goals of u en, as compared with reliable segment transport. Often, one of the key goals of
sing a UDP-based transport that allows some unreliability is to reduce latency a using a UDP-based transport that allows some unreliability is to reduce latency
nd better support applications like videoconferencing, or for other live-action and better support applications like videoconferencing or other live-action vide
video with interactive components, such as some sporting events.</t> o with interactive components, such as some sporting events.</t>
<t>Congestion avoidance strategies for deployments using unreliable tran <t>Congestion avoidance strategies for deployments using unreliable
sport protocols vary widely in practice, ranging from being entirely unresponsiv transport protocols vary widely in practice, ranging from being
e to congestion, to using feedback signaling to change encoder settings (as in < entirely unresponsive to responding by using strategies, including:</t>
xref target="RFC5762"/>), to using fewer enhancement layers (as in <xref target= <ul>
"RFC6190"/>), to using proprietary methods to detect QoE issues and turn off vid <li>feedback signaling to change encoder settings (as in <xref target="
eo to allow less bandwidth-intensive media such as audio to be delivered.</t> RFC5762"/>),</li>
<t>RTP relies on RTCP Sender and Receiver Reports <xref target="RFC3550" <li>fewer enhancement layers (as in <xref target="RFC6190"/>), and </li
/> as its own feedback mechanism, and even includes Circuit Breakers for Unicast >
RTP Sessions <xref target="RFC8083"/> for situations when normal RTP congestion <li>proprietary methods to detect QoE issues and turn off video to
control has not been able to react sufficiently to RTP flows sending at rates t allow less bandwidth-intensive media, such as audio, to be
hat result in sustained packet loss.</t> delivered.</li>
<t>The notion of "Circuit Breakers" has also been applied to other UDP a </ul>
pplications in <xref target="RFC8084"/>, such as tunneling packets over UDP that <t>RTP relies on RTCP sender and receiver reports <xref target="RFC3550"
are potentially not congestion-controlled (for example, "Encapsulating MPLS in /> as its own feedback mechanism and even includes circuit breakers for unicast
UDP," as described in <xref target="RFC7510"/>). If streaming media segments are RTP sessions <xref target="RFC8083"/> for situations when normal RTP congestion
carried in tunnels encapsulated in UDP, these media streams may encounter "trip control has not been able to react sufficiently to RTP flows sending at rates th
ped circuit breakers," with resulting user-visible impacts.</t> at result in sustained packet loss.</t>
<t>The notion of "circuit breakers" has also been applied to other UDP a
pplications in <xref target="RFC8084"/>, such as tunneling packets over UDP that
are potentially not congestion controlled (for example, "encapsulating MPLS in
UDP", as described in <xref target="RFC7510"/>). If streaming media segments are
carried in tunnels encapsulated in UDP, these media streams may encounter "trip
ped circuit breakers", with resulting user-visible impacts.</t>
</section> </section>
<section anchor="quic-behavior"> <section anchor="quic-behavior">
<name>QUIC and Changing Transport Protocol Behavior</name> <name>QUIC and Changing Transport Protocol Behavior</name>
<t>The QUIC protocol, developed from a proprietary protocol into an IETF <t>The QUIC protocol, developed from a proprietary protocol into an IETF
standards-track protocol <xref target="RFC9000"/>, turns many of the statements Standards Track protocol <xref target="RFC9000"/>, behaves differently than the
made in <xref target="reliable-behavior"/> and <xref target="unreliable-behavio transport protocols characterized in Sections <xref target="reliable-behavior" f
r"/> on their heads.</t> ormat="counter"/> and <xref target="unreliable-behavior" format="counter"/>.</t>
<t>Although QUIC provides an alternative to the TCP and UDP transport pr <t>Although QUIC provides an alternative to the TCP and UDP transport pr
otocols, QUIC is itself encapsulated in UDP. As noted elsewhere in <xref target= otocols, QUIC is itself encapsulated in UDP. As noted elsewhere in <xref target=
"gen-encrypt"/>, the QUIC protocol encrypts almost all of its transport paramete "gen-encrypt"/>, the QUIC protocol encrypts almost all of its transport paramete
rs, and all of its payload, so any intermediaries that network operators may be rs and all of its payload, so any intermediaries that network operators may be u
using to troubleshoot HTTP streaming media performance issues, perform analytics sing to troubleshoot HTTP streaming media performance issues, perform analytics,
, or even intercept exchanges in current applications will not work for QUIC-bas or even intercept exchanges in current applications will not work for QUIC-base
ed applications without making changes to their networks. <xref target="stream-e d applications without making changes to their networks. <xref target="stream-en
ncrypt-media"/> describes the implications of media encryption in more detail.</ crypt-media"/> describes the implications of media encryption in more detail.</t
t> >
<t>While QUIC is designed as a general-purpose transport protocol, and c <t>While QUIC is designed as a general-purpose transport protocol and ca
an carry different application-layer protocols, the current standardized mapping n carry different application-layer protocols, the current standardized mapping
is for HTTP/3 <xref target="RFC9114"/>, which describes how QUIC transport serv is for HTTP/3 <xref target="RFC9114"/>, which describes how QUIC transport servi
ices are used for HTTP. The convention is for HTTP/3 to run over UDP port 443 <x ces are used for HTTP. The convention is for HTTP/3 to run over UDP port 443 <xr
ref target="Port443"/> but this is not a strict requirement.</t> ef target="Port443"/>, but this is not a strict requirement.</t>
<t>When HTTP/3 is encapsulated in QUIC, which is then encapsulated in UD <t>When HTTP/3 is encapsulated in QUIC, which is then encapsulated in UD
P, streaming operators (and network operators) might see UDP traffic patterns th P, streaming operators (and network operators) might see UDP traffic patterns th
at are similar to HTTP(S) over TCP. UDP ports may be blocked for any port number at are similar to HTTP(S) over TCP. UDP ports may be blocked for any port number
s that are not commonly used, such as UDP 53 for DNS. Even when UDP ports are no s that are not commonly used, such as UDP 53 for DNS. Even when UDP ports are no
t blocked and QUIC packets can flow, streaming operators (and network operators) t blocked and QUIC packets can flow, streaming operators (and network operators)
may severely rate-limit this traffic because they do not expect to see legitima may severely rate-limit this traffic because they do not expect to see legitima
te high-bandwidth traffic such as streaming media over the UDP ports that HTTP/3 te high-bandwidth traffic, such as streaming media over the UDP ports that HTTP/
is using.</t> 3 is using.</t>
<t>As noted in <xref target="noisy-measurements"/>, because TCP provides <t>As noted in <xref target="noisy-measurements"/>, because TCP provides
a reliable, in-order delivery service for applications, any packet loss for a T a reliable, in-order delivery service for applications, any packet loss for a T
CP connection causes head-of-line blocking, so that no TCP segments arriving aft CP connection causes head-of-line blocking so that no TCP segments arriving afte
er a packet is lost will be delivered to the receiving application until retrans r a packet is lost will be delivered to the receiving application until retransm
mission of the lost packet has been received, allowing in-order delivery to the ission of the lost packet has been received, allowing in-order delivery to the a
application to continue. As described in <xref target="RFC9000"/>, QUIC connecti pplication to continue. As described in <xref target="RFC9000"/>, QUIC connectio
ons can carry multiple streams, and when packet losses do occur, only the stream ns can carry multiple streams, and when packet losses do occur, only the streams
s carried in the lost packet are delayed.</t> carried in the lost packet are delayed.</t>
<t>A QUIC extension currently being specified (<xref target="RFC9221"/>) <t>A QUIC extension currently being specified <xref target="RFC9221"/> a
adds the capability for "unreliable" delivery, similar to the service provided dds the capability for "unreliable" delivery, similar to the service provided by
by UDP, but these datagrams are still subject to the QUIC connection's congestio UDP, but these datagrams are still subject to the QUIC connection's congestion
n controller, providing some transport-level congestion avoidance measures, whic controller, providing some transport-level congestion avoidance measures, which
h UDP does not.</t> UDP does not.</t>
<t>As noted in <xref target="reliable-behavior"/>, there is an increasin <t>As noted in <xref target="reliable-behavior"/>, there is an increasin
g interest in congestion control algorithms that respond to delay measurements, g interest in congestion control algorithms that respond to delay measurements i
instead of responding to packet loss. These algorithms may deliver an improved u nstead of responding to packet loss. These algorithms may deliver an improved us
ser experience, but in some cases, have not responded to sustained packet loss, er experience, but in some cases, they have not responded to sustained packet lo
which exhausts available buffers along the end-to-end path that may affect other ss, which exhausts available buffers along the end-to-end path that may affect o
users sharing that path. The QUIC protocol provides a set of congestion control ther users sharing that path. The QUIC protocol provides a set of congestion con
hooks that can be used for algorithm agility, and <xref target="RFC9002"/> defi trol hooks that can be used for algorithm agility, and <xref target="RFC9002"/>
nes a basic congestion control algorithm that is roughly similar to TCP NewReno defines a basic congestion control algorithm that is roughly similar to TCP NewR
<xref target="RFC6582"/>. However, QUIC senders can and do unilaterally choose t eno <xref target="RFC6582"/>. However, QUIC senders can and do unilaterally choo
o use different algorithms such as loss-based CUBIC <xref target="RFC8312"/>, de se to use different algorithms, such as loss-based CUBIC <xref target="RFC8312"/
lay-based COPA or BBR, or even something completely different.</t> >, delay-based Copa or BBR, or even something completely different.</t>
<t>The Internet community does have experience with deploying new conges <t>The Internet community does have experience with deploying new conges
tion controllers without causing congestion collapse on the Internet. As noted i tion controllers without causing congestion collapse on the Internet. As noted i
n <xref target="RFC8312"/>, both the CUBIC congestion controller and its predece n <xref target="RFC8312"/>, both the CUBIC congestion controller and its predece
ssor BIC have significantly different behavior from Reno-style congestion contro ssor BIC have significantly different behavior from Reno-style congestion contro
llers such as TCP NewReno <xref target="RFC6582"/>, both were added to the Linux llers, such as TCP NewReno <xref target="RFC6582"/>; both were added to the Linu
kernel to allow experimentation and analysis, and both were then selected as th x kernel to allow experimentation and analysis, both were then selected as the d
e default TCP congestion controllers in Linux, and both were deployed globally.< efault TCP congestion controllers in Linux, and both were deployed globally.</t>
/t> <t>The point mentioned in <xref target="reliable-behavior"/> about TCP c
<t>The point mentioned in <xref target="reliable-behavior"/> about TCP c ongestion controllers being implemented in operating system kernels is different
ongestion controllers being implemented in operating system kernels is different with QUIC. Although QUIC can be implemented in operating system kernels, one of
with QUIC. Although QUIC can be implemented in operating system kernels, one of the design goals when this work was chartered was "QUIC is expected to support
the design goals when this work was chartered was "QUIC is expected to support rapid, distributed development and testing of features"; to meet this expectatio
rapid, distributed development and testing of features," and to meet this expect n, many implementers have chosen to implement QUIC in user space, outside the op
ation, many implementers have chosen to implement QUIC in user space, outside th erating system kernel, and to even distribute QUIC libraries with their own appl
e operating system kernel, and to even distribute QUIC libraries with their own ications. It is worth noting that streaming operators using HTTP/3, carried over
applications. It is worth noting that streaming operators using HTTP/3, carried QUIC, can expect more frequent deployment of new congestion controller behavior
over QUIC, can expect more frequent deployment of new congestion controller beha than has been the case with HTTP/1 and HTTP/2, carried over TCP.</t>
vior than has been the case with HTTP/1 and HTTP/2, carried over TCP.</t>
<t>It is worth considering that if TCP-based HTTP traffic and UDP-based HTTP/3 traffic are allowed to enter operator networks on roughly equal terms, qu estions of fairness and contention will be heavily dependent on interactions bet ween the congestion controllers in use for TCP-based HTTP traffic and UDP-based HTTP/3 traffic.</t> <t>It is worth considering that if TCP-based HTTP traffic and UDP-based HTTP/3 traffic are allowed to enter operator networks on roughly equal terms, qu estions of fairness and contention will be heavily dependent on interactions bet ween the congestion controllers in use for TCP-based HTTP traffic and UDP-based HTTP/3 traffic.</t>
</section> </section>
</section> </section>
<section anchor="stream-encrypt-media"> <section anchor="stream-encrypt-media">
<name>Streaming Encrypted Media</name> <name>Streaming Encrypted Media</name>
<t>"Encrypted Media" has at least three meanings:</t> <t>"Encrypted Media" has at least three meanings:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>Media encrypted at the application layer, typically using some sort <li>Media encrypted at the application layer, typically using some sort
of Digital Rights Management (DRM) system or other object encryption/security me of Digital Rights Management (DRM) system or other object encryption/security me
chanism, and typically remaining encrypted at rest, when senders and receivers s chanism and typically remaining encrypted at rest when senders and receivers sto
tore it.</li> re it.</li>
<li>Media encrypted by the sender at the transport layer, and remaining <li>Media encrypted by the sender at the transport layer and remaining e
encrypted until it reaches the ultimate media consumer (in this document, referr ncrypted until it reaches the ultimate media consumer (in this document, it is r
ed to as end-to-end media encryption).</li> eferred to as end-to-end media encryption).</li>
<li>Media encrypted by the sender at the transport layer, and remaining <li>Media encrypted by the sender at the transport layer and remaining e
encrypted until it reaches some intermediary that is <em>not</em> the ultimate m ncrypted until it reaches some intermediary that is <em>not</em> the ultimate me
edia consumer, but has credentials allowing decryption of the media content. Thi dia consumer but has credentials allowing decryption of the media content. This
s intermediary may examine and even transform the media content in some way, bef intermediary may examine and even transform the media content in some way, befor
ore forwarding re-encrypted media content (in this document referred to as hop-b e forwarding re-encrypted media content (in this document, it is referred to as
y-hop media encryption).</li> hop-by-hop media encryption).</li>
</ul> </ul>
<t>This document focuses on media encrypted at the transport layer, whethe r encryption is performed hop-by-hop or end-to-end. Because media encrypted at t he application layer will only be processed by application-level entities, this encryption does not have transport-layer implications. Of course, both hop-by-ho p and end-to-end encrypted transport may carry media that is, in addition, encry pted at the application layer.</t> <t>This document focuses on media encrypted at the transport layer, whethe r encryption is performed hop by hop or end to end. Because media encrypted at t he application layer will only be processed by application-level entities, this encryption does not have transport-layer implications. Of course, both hop-by-ho p and end-to-end encrypted transport may carry media that is, in addition, encry pted at the application layer.</t>
<t>Each of these encryption strategies is intended to achieve a different goal. For instance, application-level encryption may be used for business purpos es, such as avoiding piracy or enforcing geographic restrictions on playback, wh ile transport-layer encryption may be used to prevent media stream manipulation or to protect manifests.</t> <t>Each of these encryption strategies is intended to achieve a different goal. For instance, application-level encryption may be used for business purpos es, such as avoiding piracy or enforcing geographic restrictions on playback, wh ile transport-layer encryption may be used to prevent media stream manipulation or to protect manifests.</t>
<t>This document does not take a position on whether those goals are "vali <t>This document does not take a position on whether those goals are valid
d" (whatever that might mean).</t> .</t>
<t>Both end-to-end and hop-by-hop media encryption have specific implicati <t>Both end-to-end and hop-by-hop media encryption have specific implicati
ons for streaming operators. These are described in <xref target="hop-by-hop-enc ons for streaming operators. These are described in Sections <xref target="hop-b
rypt"/> and <xref target="e2em-encrypt"/>.</t> y-hop-encrypt" format="counter"/> and <xref target="e2em-encrypt" format="counte
r"/>.</t>
<section anchor="gen-encrypt"> <section anchor="gen-encrypt">
<name>General Considerations for Streaming Media Encryption</name> <name>General Considerations for Streaming Media Encryption</name>
<t>The use of strong encryption does provide confidentiality for encrypt <t>The use of strong encryption does provide confidentiality for encrypt
ed streaming media, from the sender to either the ultimate media consumer, or to ed streaming media, from the sender to either the ultimate media consumer or to
an intermediary that possesses credentials allowing decryption. This does prev an intermediary that possesses credentials allowing decryption. This does preve
ent Deep Packet Inspection by any on-path intermediary that does not possess cre nt deep packet inspection (DPI) by any on-path intermediary that does not posses
dentials allowing decryption. However, even encrypted content streams may be vul s credentials allowing decryption. However, even encrypted content streams may b
nerable to traffic analysis. An on-path observer that can identify that encrypte e vulnerable to traffic analysis. An on-path observer that can identify that enc
d traffic contains a media stream, could "fingerprint" this encrypted media stea rypted traffic contains a media stream could "fingerprint" this encrypted media
m, and then compare it against "fingerprints" of known content. The protection p stream and then compare it against "fingerprints" of known content. The protecti
rovided by strong encryption can be further lessened if a streaming media operat on provided by strong encryption can be further lessened if a streaming media op
or is repeatedly encrypting the same content. "Identifying HTTPS-Protected Netfl erator is repeatedly encrypting the same content. "Identifying HTTPS-Protected N
ix Videos in Real-Time" (<xref target="CODASPY17"/>) is an example of what is po etflix Videos in Real-Time" <xref target="CODASPY17"/> is an example of what is
ssible when identifying HTTPS-protected videos over TCP transport, based either possible when identifying HTTPS-protected videos over TCP transport, based eithe
on the length of entire resources being transferred, or on characteristic packet r on the length of entire resources being transferred or on characteristic packe
patterns at the beginning of a resource being transferred. If traffic analysis t patterns at the beginning of a resource being transferred. If traffic analysis
is successful at identifying encrypted content and associating it with specific is successful at identifying encrypted content and associating it with specific
users, this tells an on-path observer what resource is being streamed, and by wh users, this tells an on-path observer what resource is being streamed, and by w
o, almost as certainly as examining decrypted traffic.</t> ho, almost as certainly as examining decrypted traffic.</t>
<t>Because HTTPS has historically layered HTTP on top of TLS, which is i <t>Because HTTPS has historically layered HTTP on top of TLS, which is i
n turn layered on top of TCP, intermediaries have historically had access to une n turn layered on top of TCP, intermediaries have historically had access to une
ncrypted TCP-level transport information, such as retransmissions, and some carr ncrypted TCP-level transport information, such as retransmissions, and some carr
iers exploited this information in attempts to improve transport-layer performan iers exploited this information in attempts to improve transport-layer performan
ce <xref target="RFC3135"/>. The most recent standardized version of HTTPS, HTTP ce <xref target="RFC3135"/>. The most recent standardized version of HTTPS, HTTP
/3 <xref target="RFC9114"/>, uses the QUIC protocol <xref target="RFC9000"/> as /3 <xref target="RFC9114"/>, uses the QUIC protocol <xref target="RFC9000"/> as
its transport layer. QUIC relies on the TLS 1.3 initial handshake <xref target=" its transport layer. QUIC relies on the TLS 1.3 initial handshake <xref target="
RFC8446"/> only for key exchange <xref target="RFC9001"/>, and encrypts almost a RFC8446"/> only for key exchange <xref target="RFC9001"/> and encrypts almost al
ll transport parameters itself except for a few invariant header fields. In the l transport parameters itself, except for a few invariant header fields. In the
QUIC short header, the only transport-level parameter which is sent "in the clea QUIC short header, the only transport-level parameter that is sent "in the clear
r" is the Destination Connection ID <xref target="RFC8999"/>, and even in the QU " is the Destination Connection ID <xref target="RFC8999"/>, and even in the QUI
IC long header, the only transport-level parameters sent "in the clear" are the C long header, the only transport-level parameters sent "in the clear" are the v
Version, Destination Connection ID, and Source Connection ID. For these reasons, ersion, Destination Connection ID, and Source Connection ID. For these reasons,
HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2.</t> HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2.</t>
<t><xref target="I-D.ietf-quic-manageability"/> discusses the manageabil <t><xref target="RFC9312"/> discusses the manageability of the QUIC tran
ity of the QUIC transport protocol that is used to encapsulate HTTP/3, focusing sport protocol that is used to encapsulate HTTP/3, focusing on the implications
on the implications of QUIC's design and wire image on network operations involv of QUIC's design and wire image on network operations involving QUIC traffic. It
ing QUIC traffic. It discusses what network operators can consider in some detai discusses what network operators can consider in some detail.</t>
l.</t> <t>More broadly, "Considerations around Transport Header Confidentiality
<t>More broadly, RFC 9065 <xref target="RFC9065"/>, "Considerations arou , Network Operations, and the Evolution of Internet Transport Protocols" <xref t
nd Transport Header Confidentiality, Network Operations, and the Evolution of In arget="RFC9065"/> describes the impact of increased encryption of transport head
ternet Transport Protocols" describes the impact of increased encryption of tran ers in general terms.</t>
sport headers in general terms.</t> <t>It is also worth noting that considerations for heavily encrypted tra
<t>It is also worth noting that considerations for heavily-encrypted tra nsport protocols also come into play when streaming media is carried over IP-lev
nsport protocols also come into play when streaming media is carried over IP-lev el VPNs and tunnels, with the additional consideration that an intermediary that
el VPNs and tunnels, with the additional consideration that an intermediary that does not possess credentials allowing decryption will not have visibility to th
does not possess credentials allowing decryption will not have visibility to th e source and destination IP addresses of the packets being carried inside the tu
e source and destination IP addresses of the packets being carried inside the tu nnel.</t>
nnel.</t>
</section> </section>
<section anchor="hop-by-hop-encrypt"> <section anchor="hop-by-hop-encrypt">
<name>Considerations for Hop-by-Hop Media Encryption</name> <name>Considerations for Hop-by-Hop Media Encryption</name>
<t>Hop-by-hop media encryption offers the benefits described in <xref ta rget="gen-encrypt"/> between the streaming media operator and authorized interme diaries, among authorized intermediaries, and between authorized intermediaries and the ultimate media consumer, but does not provide these benefits end-to-end. The streaming media operator and ultimate media consumer must trust the authori zed intermediaries, and if these intermediaries cannot be trusted, the benefits of encryption are lost.</t> <t>Hop-by-hop media encryption offers the benefits described in <xref ta rget="gen-encrypt"/> between the streaming media operator and authorized interme diaries, among authorized intermediaries, and between authorized intermediaries and the ultimate media consumer; however, it does not provide these benefits end to end. The streaming media operator and ultimate media consumer must trust the authorized intermediaries, and if these intermediaries cannot be trusted, the b enefits of encryption are lost.</t>
<t>Although the IETF has put considerable emphasis on end-to-end streami ng media encryption, there are still important use cases that require the insert ion of intermediaries.</t> <t>Although the IETF has put considerable emphasis on end-to-end streami ng media encryption, there are still important use cases that require the insert ion of intermediaries.</t>
<t>There are a variety of ways to involve intermediaries, and some are m uch more intrusive than others.</t> <t>There are a variety of ways to involve intermediaries, and some are m uch more intrusive than others.</t>
<t>From a streaming media operator's perspective, a number of considerat <t>From a streaming media operator's perspective, a number of considerat
ions are in play. The first question is likely whether the streaming media opera ions are in play. The first question is likely whether the streaming media opera
tor intends that intermediaries are explicitly addressed from endpoints, or whet tor intends that intermediaries are explicitly addressed from endpoints or wheth
her the streaming media operator is willing to allow intermediaries to "interce er the streaming media operator is willing to allow intermediaries to "intercep
pt" streaming content transparently, with no awareness or permission from either t" streaming content transparently, with no awareness or permission from either
endpoint.</t> endpoint.</t>
<t>If a streaming media operator does not actively work to avoid interc <t>If a streaming media operator does not actively work to avoid interce
eption by on-path intermediaries, the effect will be indistinguishable from "imp ption by on-path intermediaries, the effect will be indistinguishable from "impe
ersonation attacks," and endpoints cannot be assured of any level of confidentia rsonation attacks", and endpoints cannot be assured of any level of confidential
lity, and cannot trust that the content received came from the expected sender.< ity and cannot trust that the content received came from the expected sender.</t
/t> >
<t>Assuming that a streaming media operator does intend to allow interme <t>Assuming that a streaming media operator does intend to allow interme
diaries to participate in content streaming and does intend to provide some leve diaries to participate in content streaming and does intend to provide some leve
l of privacy for endpoints, there are a number of possible tools, either already l of privacy for endpoints, there are a number of possible tools, either already
available or still being specified. These include</t> available or still being specified. These include the following:</t>
<ul spacing="normal"> <dl newline="true" spacing="normal">
<li>Server And Network assisted DASH <xref target="MPEG-DASH-SAND"/> - <dt>Server and Network Assisted DASH <xref target="MPEG-DASH-SAND"/>:<
this specification introduces explicit messaging between DASH clients and DASH- /dt>
aware network elements or among various DASH-aware network elements, for the pur <dd>This specification introduces explicit messaging between DASH clien
pose of improving the efficiency of streaming sessions by providing information ts and DASH-aware network elements or among various DASH-aware network elements
about real-time operational characteristics of networks, servers, proxies, cache for the purpose of improving the efficiency of streaming sessions by providing i
s, CDNs, as well as DASH client's performance and status.</li> nformation about real-time operational characteristics of networks, servers, pro
<li>"Double Encryption Procedures for the Secure Real-Time Transport P xies, caches, CDNs, as well as a DASH client's performance and status.</dd>
rotocol (SRTP)" <xref target="RFC8723"/> - this specification provides a cryptog <dt>"Double Encryption Procedures for the Secure Real-Time Transport P
raphic transform for the Secure Real-time Transport Protocol that provides both rotocol (SRTP)" <xref target="RFC8723"/>:</dt>
hop-by-hop and end-to-end security guarantees.</li> <dd>This specification provides a cryptographic transform for the SRTP
<li>Secure Media Frames <xref target="SFRAME"/> - <xref target="RFC872 that provides both hop-by-hop and end-to-end security guarantees.</dd>
3"/> is closely tied to SRTP, and this close association impeded widespread depl <dt>Secure Frames <xref target="SFRAME"/>:</dt>
oyment, because it could not be used for the most common media content delivery <dd><xref target="RFC8723"/> is closely tied to SRTP, and this close as
mechanisms. A more recent proposal, Secure Media Frames <xref target="SFRAME"/>, sociation impeded widespread deployment, because it could not be used for the mo
also provides both hop-by-hop and end-to-end security guarantees, but can be us st common media content delivery mechanisms. A more recent proposal, Secure Fram
ed with other media transport protocols beyond SRTP.</li> es <xref target="SFRAME"/>, also provides both hop-by-hop and end-to-end securit
</ul> y guarantees but can be used with other media transport protocols beyond SRTP.</
<t>A streaming media operator's choice of whether to involve intermediar dd>
ies requires careful consideration. As an example, when ABR manifests were commo </dl>
nly sent unencrypted, some access network operators would modify manifests durin <t>A streaming media operator's choice of whether to involve intermediar
g peak hours by removing high-bitrate renditions to prevent players from choosin ies requires careful consideration. As an example, when ABR manifests were commo
g those renditions, thus reducing the overall bandwidth consumed for delivering nly sent unencrypted, some access network operators would modify manifests durin
these media streams and thereby improving the network load and the user experien g peak hours by removing high-bitrate renditions to prevent players from choosin
ce for their customers. g those renditions, thus reducing the overall bandwidth consumed for delivering
these media streams and thereby reducing the network load and improving the aver
age user experience for their customers.
Now that ubiquitous encryption typically prevents this kind of modification, a s treaming media operator who used intermediaries in the past, and who now wishes to maintain the same level of network health and user experience, must choose be tween adding intermediaries who are authorized to change the manifests or adding some other form of complexity to their service.</t> Now that ubiquitous encryption typically prevents this kind of modification, a s treaming media operator who used intermediaries in the past, and who now wishes to maintain the same level of network health and user experience, must choose be tween adding intermediaries who are authorized to change the manifests or adding some other form of complexity to their service.</t>
<t>Some resources that might inform other similar considerations are fur ther discussed in <xref target="RFC8824"/> (for WebRTC) and <xref target="I-D.ie tf-quic-manageability"/> (for HTTP/3 and QUIC).</t> <t>Some resources that might inform other similar considerations are fur ther discussed in <xref target="RFC8824"/> (for WebRTC) and <xref target="RFC931 2"/> (for HTTP/3 and QUIC).</t>
</section> </section>
<section anchor="e2em-encrypt"> <section anchor="e2em-encrypt">
<name>Considerations for End-to-End Media Encryption</name> <name>Considerations for End-to-End Media Encryption</name>
<t>End-to-end media encryption offers the benefits described in <xref ta rget="gen-encrypt"/> from the streaming media operator to the ultimate media con sumer.</t> <t>End-to-end media encryption offers the benefits described in <xref ta rget="gen-encrypt"/> from the streaming media operator to the ultimate media con sumer.</t>
<t>End-to-end media encryption has become much more widespread in the ye <t>End-to-end media encryption has become much more widespread in the ye
ars since the IETF issued "Pervasive Monitoring Is an Attack" <xref target="RFC7 ars since the IETF issued "Pervasive Monitoring Is an Attack" <xref target="RFC7
258"/> as a Best Current Practice, describing pervasive monitoring as a much gre 258"/> as a Best Current Practice, describing pervasive monitoring as a much gre
ater threat than previously appreciated. After the Snowden disclosures, many con ater threat than previously appreciated. After the Snowden disclosures, many con
tent providers made the decision to use HTTPS protection - HTTP over TLS - for m tent providers made the decision to use HTTPS protection -- HTTP over TLS -- for
ost or all content being delivered as a routine practice, rather than in excepti most or all content being delivered as a routine practice, rather than in excep
onal cases for content that was considered sensitive.</t> tional cases for content that was considered sensitive.</t>
<t>However, as noted in <xref target="RFC7258"/>, there is no way to pre <t>However, as noted in <xref target="RFC7258"/>, there is no way to pre
vent pervasive monitoring by an attacker, while allowing monitoring by a more be vent pervasive monitoring by an attacker while allowing monitoring by a more ben
nign entity who only wants to use DPI to examine HTTP requests and responses to ign entity who only wants to use DPI to examine HTTP requests and responses to p
provide a better user experience. If a modern encrypted transport protocol is us rovide a better user experience. If a modern encrypted transport protocol is use
ed for end-to-end media encryption, unauthorized on-path intermediaries are unab d for end-to-end media encryption, unauthorized on-path intermediaries are unabl
le to examine transport and application protocol behavior. As described in <xref e to examine transport and application protocol behavior. As described in <xref
target="hop-by-hop-encrypt"/>, only an intermediary explicitly authorized by th target="hop-by-hop-encrypt"/>, only an intermediary explicitly authorized by the
e streaming media operator who is to examine packet payloads, rather than inter streaming media operator who is to examine packet payloads, rather than interc
cepting packets and examining them without authorization, can continue these pra epting packets and examining them without authorization, can continue these prac
ctices.</t> tices.</t>
<t><xref target="RFC7258"/> said that "The IETF will strive to produce s <t><xref target="RFC7258"/> states that "[t]he IETF will strive to produ
pecifications that mitigate pervasive monitoring attacks," so streaming operator ce specifications that mitigate pervasive monitoring attacks", so streaming oper
s should expect the IETF's direction toward preventing unauthorized monitoring o ators should expect the IETF's direction toward preventing unauthorized monitori
f IETF protocols to continue for the foreseeable future.</t> ng of IETF protocols to continue for the foreseeable future.</t>
</section> </section>
</section> </section>
<section anchor="further"> <section anchor="further">
<name>Further Reading and References</name> <name>Additional Resources for Streaming Media</name>
<t>The MOPS community maintains a list of references and resources for fur <t>The Media Operations (MOPS) community maintains a list of references an
ther reading at this location:</t> d resources;
<ul spacing="normal"> for further reading, see <xref target="MOPS-RESOURCES"/>.</t>
<li>
<eref target="https://github.com/ietf-wg-mops/draft-ietf-mops-streamin
g-opcons/blob/main/living-doc-mops-streaming-opcons.md">https://github.com/ietf-
wg-mops/draft-ietf-mops-streaming-opcons/blob/main/living-doc-mops-streaming-opc
ons.md</eref></li>
</ul>
<t>Editor's note: The URL above might or might not be changed during IESG
Evaluation. See <eref target="https://github.com/ietf-wg-mops/draft-ietf-mops-s
treaming-opcons/issues/114">https://github.com/ietf-wg-mops/draft-ietf-mops-stre
aming-opcons/issues/114</eref> for updates.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document requires no actions from IANA.</t> <t>This document has no IANA actions.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>Security is an important matter for streaming media applications and th <t>Security is an important matter for streaming media applications, and t
e topic of media encryption was explained in <xref target="stream-encrypt-media" he topic of media encryption was explained in <xref target="stream-encrypt-media
/>. This document itself introduces no new security issues.</t> "/>. This document itself introduces no new security issues.</t>
</section>
<section anchor="acknowledgments">
<name>Acknowledgments</name>
<t>Thanks to Alexandre Gouaillard, Aaron Falk, Chris Lemmons, Dave Oran, E
ric Vyncke, Glenn Deen, Kyle Rose, Leslie Daigle, Linda Dunbar, Lucas Pardue, Ma
rk Nottingham, Matt Stock, Mike English, Renan Krishna, Roni Even, Sanjay Mishra
, Kiran Makhjani, Chris Lemmons, Tommy Pauly, Will Law, Michael Scharf, Eric Vyn
cke, Erik Kline, Roman Danyliw, Valery Smyslov, Robert Wilton, Lars Eggert, Zahe
d Sarker, Warren Kumari, John Scudder, Martin Duke, and Nancy Cam-Winget for ver
y helpful suggestions, reviews and comments.</t>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.cardwell-iccrg-bbr-congestion-control" to="BBR-CON
GESTION-CONTROL"/>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="CVNI" target="https://www.ieee802.org/3/ad_hoc/bwa2/pub
lic/calls/19_0624/nowell_bwa_01_190624.pdf"> <reference anchor="CVNI" target="">
<front> <front>
<title>Cisco VNI Forecast update</title> <title>Cisco Visual Networking Index: Forecast and Trends, 2017–2022</
title>
<author>
<organization>Cisco</organization>
</author>
<date year="2018"/>
</front>
</reference>
<reference anchor="MOPS-RESOURCES" target="https://wiki.ietf.org/group/mops/
rfc9317-additional-resources">
<front>
<title>rfc9317-additional-resources</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date year="2019" month="June"/> <date year="2022" month="September"/>
</front> </front>
</reference> </reference>
<reference anchor="PCC" target="https://ieeexplore.ieee.org/document/85712 88"> <reference anchor="PCC" target="https://ieeexplore.ieee.org/document/85712 88">
<front> <front>
<title>Emerging MPEG Standards for Point Cloud Compression</title> <title>Emerging MPEG Standards for Point Cloud Compression</title>
<author initials="S." surname="Schwarz"> <author initials="" surname="Schwarz, S. et al." fullname="S. Schwarz
<organization/> et al.">
</author> <organization></organization>
<author initials="" surname="et al">
<organization/>
</author> </author>
<date year="2019" month="March"/> <date year="2019" month="March"/>
</front> </front>
<seriesInfo name="IEEE Journal on Emerging and Selected Topics in Circui <seriesInfo name="DOI" value="10.1109/JETCAS.2018.2885981"/>
ts and Systems" value=""/> <refcontent>IEEE Journal on Emerging and Selected Topics in Circuits and
Systems</refcontent>
</reference> </reference>
<reference anchor="MPEGI" target="https://ieeexplore.ieee.org/document/937 4648"> <reference anchor="MPEGI" target="https://ieeexplore.ieee.org/document/937 4648">
<front> <front>
<title>MPEG Immersive Video Coding Standard</title> <title>MPEG Immersive Video Coding Standard</title>
<author initials="J. M." surname="Boyce"> <author initials="" surname="Boyce, J. M. et al.">
<organization/>
</author>
<author initials="" surname="et al">
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
<seriesInfo name="Proceedings of the IEEE" value=""/> <seriesInfo name="DOI" value="10.1109/JPROC.2021.3062590"/>
<refcontent>Proceedings of the IEEE, Vol. 109, Issue 9, pp. 1521-1536</re
fcontent>
</reference> </reference>
<reference anchor="MMSys11" target="https://dl.acm.org/doi/10.1145/1943552 .1943574"> <reference anchor="MMSys11" target="https://dl.acm.org/doi/10.1145/1943552 .1943574">
<front> <front>
<title>An experimental evaluation of rate-adaptation algorithms in ada ptive streaming over HTTP</title> <title>An experimental evaluation of rate-adaptation algorithms in ada ptive streaming over HTTP</title>
<author initials="S." surname="Akhshabi"> <author initials="S." surname="Akhshabi">
<organization/> <organization/>
</author> </author>
<author initials="A. C." surname="Begen"> <author initials="A. C." surname="Begen">
<organization/> <organization/>
</author> </author>
<author initials="C." surname="Dovrolis"> <author initials="C." surname="Dovrolis">
<organization/> <organization/>
</author> </author>
<date year="2011" month="February"/> <date year="2011" month="February"/>
</front> </front>
<seriesInfo name="ACM MMSys" value=""/> <seriesInfo name="DOI" value="10.1145/1943552.1943574"/>
<refcontent>ACM MMSys</refcontent>
</reference> </reference>
<reference anchor="MMSP20" target="https://ieeexplore.ieee.org/document/92 87117"> <reference anchor="MMSP20" target="https://ieeexplore.ieee.org/document/92 87117">
<front> <front>
<title>Evaluating the performance of Apple's low-latency HLS</title> <title>Evaluating the Performance of Apple's Low-Latency HLS</title>
<author initials="K." surname="Durak"> <author initials="" surname="Durak, K. et al.">
<organization/>
</author>
<author initials="" surname="et al">
<organization/> <organization/>
</author> </author>
<date year="2020" month="September"/> <date year="2020" month="September"/>
</front> </front>
<seriesInfo name="IEEE MMSP" value=""/> <seriesInfo name="DOI" value="10.1109/MMSP48831.2020.9287117"/>
<refcontent>IEEE MMSP</refcontent>
</reference> </reference>
<reference anchor="LL-DASH" target="https://dashif.org/docs/CR-Low-Latency -Live-r8.pdf"> <reference anchor="LL-DASH" target="https://dashif.org/docs/CR-Low-Latency -Live-r8.pdf">
<front> <front>
<title>Low-latency Modes for DASH</title> <title>Low-latency Modes for DASH</title>
<author initials="" surname="DASH-IF"> <author>
<organization/> <organization>DASH-IF</organization>
</author> </author>
<date year="2020" month="March"/> <date year="2020" month="March"/>
</front> </front>
</reference> </reference>
<reference anchor="CMAF-CTE" target="https://www.akamai.com/us/en/multimed
ia/documents/white-paper/low-latency-streaming-cmaf-whitepaper.pdf"> <reference anchor="CMAF-CTE" target="">
<front> <front>
<title>Ultra-Low-Latency Streaming Using Chunked-Encoded and Chunked T <title>Catching the Moment With LoL+ in Twitch-Like Low-Latency Live S
ransferred CMAF</title> treaming Platforms</title>
<author initials="W." surname="Law" fullname="Will Law"> <author initials="A." surname="Bentaleb" fullname="Abdelhak Bentaleb">
<organization>Akamai Technologies, Inc.</organization> </author>
<author initials="M." surname="Akcay" fullname="Mehmet N. Akcay">
</author>
<author initials="M." surname="Lim" fullname="May Lim">
</author>
<author initials="A." surname="Begen" fullname="Ali C. Begen">
</author>
<author initials="R." surname="Zimmermann" fullname="Roger Zimmermann">
</author> </author>
<date year="2018" month="October"/> <date year="2021" month="May"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/TMM.2021.3079288"/>
<refcontent>IEEE Trans. Multimedia, Vol. 24, pp. 2300-2314</refcontent>
</reference> </reference>
<reference anchor="ABRSurvey" target="https://ieeexplore.ieee.org/abstract
/document/8424813"> <reference anchor="ABRSurvey">
<front> <front>
<title>A Survey on Bitrate Adaptation Schemes for Streaming Media Over <title>A survey on bitrate adaptation schemes for streaming media over
HTTP</title> HTTP</title>
<author initials="A." surname="Bentaleb" fullname="Abdelhak Bentaleb">
<organization/>
</author>
<author initials="B." surname="Taani"> <author initials="B." surname="Taani">
<organization/> <organization/>
</author> </author>
<author initials="A. C." surname="Begen"> <author initials="A. C." surname="Begen">
<organization/> <organization/>
</author> </author>
<author initials="C." surname="Timmerer"> <author initials="C." surname="Timmerer">
<organization/> <organization/>
</author> </author>
<author initials="R." surname="Zimmermann"> <author initials="R." surname="Zimmermann">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Bentaleb et al" fullname="Abdelhak Bent
aleb et al.">
<organization/>
</author>
<date year="2019"/>
</front> </front>
<seriesInfo name="IEEE Communications Surveys &amp; Tutorials" value=""/ <seriesInfo name="DOI" value="10.1109/COMST.2018.2862938"/>
> <refcontent>IEEE Communications Surveys &amp; Tutorials, vol. 21/1, pp. 5
62-585, Firstquarter 2019</refcontent>
</reference> </reference>
<reference anchor="Encodings" target="https://developer.apple.com/document ation/http_live_streaming/hls_authoring_specification_for_apple_devices"> <reference anchor="Encodings" target="https://developer.apple.com/document ation/http_live_streaming/hls_authoring_specification_for_apple_devices">
<front> <front>
<title>HLS Authoring Specification for Apple Devices</title> <title>HTTP Live Streaming (HLS) Authoring Specification for Apple Dev
<author initials="" surname="Apple, Inc"> ices</title>
<organization/> <author>
<organization>Apple Developer</organization>
</author> </author>
<date year="2020" month="June"/> <date year="2020" month="June"/>
</front> </front>
</reference> </reference>
<reference anchor="CTA-2066" target="https://shop.cta.tech/products/stream ing-quality-of-experience-events-properties-and-metrics"> <reference anchor="CTA-2066" target="https://shop.cta.tech/products/stream ing-quality-of-experience-events-properties-and-metrics">
<front> <front>
<title>Streaming Quality of Experience Events, Properties and Metrics< /title> <title>Streaming Quality of Experience Events, Properties and Metrics< /title>
<author> <author>
<organization>Consumer Technology Association</organization> <organization>Consumer Technology Association</organization>
</author> </author>
<date year="2020" month="March"/> <date year="2020" month="March"/>
</front> </front>
<refcontent>CTA-2066</refcontent>
</reference> </reference>
<reference anchor="CTA-5004" target="https://shop.cta.tech/products/web-ap plication-video-ecosystem-common-media-client-data-cta-5004"> <reference anchor="CTA-5004" target="https://shop.cta.tech/products/web-ap plication-video-ecosystem-common-media-client-data-cta-5004">
<front> <front>
<title>Common Media Client Data (CMCD)</title> <title>Web Application Video Ecosystem - Common Media Client Data</tit
<author initials="" surname="CTA"> le>
<organization/> <author>
<organization>Consumer Technology Association</organization>
</author> </author>
<date year="2020" month="September"/> <date year="2020" month="September"/>
</front> </front>
<refcontent>CTA-5004</refcontent>
</reference> </reference>
<reference anchor="ELASTIC" target="https://ieeexplore.ieee.org/document/6 691442"> <reference anchor="ELASTIC" target="https://ieeexplore.ieee.org/document/6 691442">
<front> <front>
<title>ELASTIC: A client-side controller for dynamic adaptive streamin g over HTTP (DASH)</title> <title>ELASTIC: A Client-Side Controller for Dynamic Adaptive Streamin g over HTTP (DASH)</title>
<author initials="L." surname="De Cicco"> <author initials="L." surname="De Cicco">
<organization/> <organization/>
</author> </author>
<author initials="V." surname="Caldaralo"> <author initials="V." surname="Caldaralo">
<organization/> <organization/>
</author> </author>
<author initials="V." surname="Palmisano"> <author initials="V." surname="Palmisano">
<organization/> <organization/>
</author> </author>
<author initials="S." surname="Mascolo"> <author initials="S." surname="Mascolo">
<organization/> <organization/>
</author> </author>
<date year="2013" month="December"/> <date year="2013" month="December"/>
</front> </front>
<seriesInfo name="Packet Video Workshop" value=""/> <seriesInfo name="DOI" value="10.1109/PV.2013.6691442"/>
<refcontent>Packet Video Workshop</refcontent>
</reference> </reference>
<reference anchor="OReilly-HPBN" target="https://hpbn.co/building-blocks-o f-tcp/"> <reference anchor="OReilly-HPBN" target="https://hpbn.co/building-blocks-o f-tcp/">
<front> <front>
<title>High Performance Browser Networking (Chapter 2: Building Blocks <title>High Performance Browser Networking - Chapter 2: Building Block
of TCP)</title> s of TCP</title>
<author> <author initials="I" surname="Grigorik" fullname="Ilya Grigorik">
<organization/> <organization/>
</author> </author>
<date year="2021" month="May"/> <date year="2021" month="May"/>
</front> </front>
</reference> </reference>
<reference anchor="Jacobson-Karels" target="https://ee.lbl.gov/papers/cong avoid.pdf"> <reference anchor="Jacobson-Karels" target="https://ee.lbl.gov/papers/cong avoid.pdf">
<front> <front>
<title>Congestion Avoidance and Control</title> <title>Congestion Avoidance and Control</title>
<author initials="V." surname="Jacobson"> <author initials="V." surname="Jacobson">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Karels"> <author initials="M." surname="Karels">
<organization/> <organization/>
</author> </author>
<date year="1988" month="November"/> <date year="1988" month="November"/>
skipping to change at line 809 skipping to change at line 832
<title>Congestion Avoidance and Control</title> <title>Congestion Avoidance and Control</title>
<author initials="V." surname="Jacobson"> <author initials="V." surname="Jacobson">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Karels"> <author initials="M." surname="Karels">
<organization/> <organization/>
</author> </author>
<date year="1988" month="November"/> <date year="1988" month="November"/>
</front> </front>
</reference> </reference>
<reference anchor="COPA18" target="https://web.mit.edu/copa/"> <reference anchor="COPA18" target="https://web.mit.edu/copa/">
<front> <front>
<title>Copa: Practical Delay-Based Congestion Control for the Internet </title> <title>Copa: Practical Delay-Based Congestion Control for the Internet </title>
<author initials="V." surname="Arun"> <author initials="V." surname="Arun">
<organization/> <organization/>
</author> </author>
<author initials="H." surname="Balakrishnan"> <author initials="H." surname="Balakrishnan">
<organization/> <organization/>
</author> </author>
<date year="2018" month="April"/> <date year="2018" month="April"/>
</front> </front>
<seriesInfo name="USENIX NSDI" value=""/> <refcontent>USENIX NSDI</refcontent>
</reference> </reference>
<reference anchor="Port443" target="https://www.iana.org/assignments/servi
ce-names-port-numbers/service-names-port-numbers.txt"> <reference anchor="Port443" target="https://www.iana.org/assignments/servi
ce-names-port-numbers">
<front> <front>
<title>Service Name and Transport Protocol Port Number Registry</title > <title>Service Name and Transport Protocol Port Number Registry</title >
<author> <author>
<organization/> <organization>IANA</organization>
</author> </author>
<date year="2021" month="April"/>
</front> </front>
</reference> </reference>
<reference anchor="CODASPY17" target="https://dl.acm.org/doi/10.1145/30298 06.3029821"> <reference anchor="CODASPY17" target="https://dl.acm.org/doi/10.1145/30298 06.3029821">
<front> <front>
<title>Identifying HTTPS-Protected Netflix Videos in Real-Time</title> <title>Identifying HTTPS-Protected Netflix Videos in Real-Time</title>
<author initials="A." surname="Reed"> <author initials="A." surname="Reed">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Kranch"> <author initials="M." surname="Kranch">
<organization/> <organization/>
</author> </author>
<date year="2017" month="March"/> <date year="2017" month="March"/>
</front> </front>
<seriesInfo name="ACM CODASPY" value=""/> <seriesInfo name="DOI" value="10.1145/3029806.3029821"/>
<refcontent>ACM CODASPY</refcontent>
</reference> </reference>
<reference anchor="MPEG-DASH" target="https://www.iso.org/standard/79329.h
tml"> <reference anchor="MPEG-DASH" target="https://www.iso.org/standard/83314.h
tml">
<front> <front>
<title>ISO/IEC 23009-1:2019 Dynamic adaptive streaming over HTTP (DASH ) - Part 1: Media presentation description and segment formats</title> <title>Information technology - Dynamic adaptive streaming over HTTP ( DASH) - Part 1: Media presentation description and segment formats</title>
<author> <author>
<organization/> <organization>ISO</organization>
</author> </author>
<date year="2019" month="December"/> <date year="2022" month="August"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="23009-1:2022"/>
</reference> </reference>
<reference anchor="MPEG-DASH-SAND" target="https://www.iso.org/standard/69 079.html"> <reference anchor="MPEG-DASH-SAND" target="https://www.iso.org/standard/69 079.html">
<front> <front>
<title>ISO/IEC 23009-5:2017 Dynamic adaptive streaming over HTTP (DASH ) - Part 5: Server and network assisted DASH (SAND)</title> <title>Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 5: Server and network assisted DASH (SAND)</title>
<author> <author>
<organization/> <organization>ISO</organization>
</author> </author>
<date year="2017" month="February"/> <date year="2017" month="February"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="23009-5:2017"/>
</reference> </reference>
<reference anchor="MPEG-CMAF" target="https://www.iso.org/standard/79106.h tml"> <reference anchor="MPEG-CMAF" target="https://www.iso.org/standard/79106.h tml">
<front> <front>
<title>ISO/IEC 23000-19:2020 Multimedia application format (MPEG-A) - Part 19: Common media application format (CMAF) for segmented media</title> <title>Information technology - Multimedia application format (MPEG-A) - Part 19: Common media application format (CMAF) for segmented media</title>
<author> <author>
<organization/> <organization>ISO</organization>
</author> </author>
<date year="2020" month="March"/> <date year="2020" month="March"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="23000-19:2020"/>
</reference> </reference>
<reference anchor="MPEG-TS" target="https://www.itu.int/rec/T-REC-H.222.0" > <reference anchor="MPEG-TS" target="https://www.itu.int/rec/T-REC-H.222.0" >
<front> <front>
<title>H.222.0 : Information technology - Generic coding of moving pic tures and associated audio information: Systems</title> <title>Information technology - Generic coding of moving pictures and associated audio information: Systems</title>
<author> <author>
<organization/> <organization>ITU-T</organization>
</author> </author>
<date year="2018" month="August" day="29"/> <date year="2021" month="June"/>
</front> </front>
<seriesInfo name="ITU-T Recommendation" value="H.222.0"/>
</reference> </reference>
<reference anchor="SFRAME" target="https://datatracker.ietf.org/doc/charte
r-ietf-sframe/"> <reference anchor="SFRAME" target="https://datatracker.ietf.org/doc/draft-
ietf-sframe-enc/">
<front> <front>
<title>Secure Media Frames Working Group (Home Page)</title> <title>Secure Frame (sframe)</title>
<author> <author>
<organization/> <organization>IETF</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="SRT" target="https://datatracker.ietf.org/meeting/inter
im-2020-mops-01/materials/slides-interim-2020-mops-01-sessa-april-15-2020-mops-i <reference anchor="SRT" target="https://datatracker.ietf.org/meeting/inter
nterim-an-update-on-streaming-video-alliance"> im-2020-mops-01/materials/slides-interim-2020-mops-01-sessa-srt-protocol-overvie
w-00">
<front> <front>
<title>Secure Reliable Transport (SRT) Protocol Overview</title> <title>SRT Protocol Overview</title>
<author initials="M." surname="Sharabayko" fullname="Maxim Sharabayko" > <author initials="M." surname="Sharabayko" fullname="Maxim Sharabayko" >
<organization/> <organization/>
</author> </author>
<date year="2020" month="April" day="15"/> <date year="2020" month="April"/>
</front> </front>
</reference> </reference>
<reference anchor="Micro"> <reference anchor="Micro">
<front> <front>
<title>Microwave Oven Signal Interference Mitigation For Wi-Fi Communi cation Systems</title> <title>Microwave Oven Signal Interference Mitigation For Wi-Fi Communi cation Systems</title>
<author initials="T. M." surname="Taher" fullname="Tanim M. Taher"> <author initials="T. M." surname="Taher" fullname="Tanim M. Taher">
<organization/> <organization/>
</author> </author>
<author initials="M. J." surname="Misurac" fullname="Matthew J. Misura c"> <author initials="M. J." surname="Misurac" fullname="Matthew J. Misura c">
<organization/> <organization/>
</author> </author>
<author initials="J. L." surname="LoCicero" fullname="Joseph L. LoCice ro"> <author initials="J. L." surname="LoCicero" fullname="Joseph L. LoCice ro">
<organization/> <organization/>
</author> </author>
<author initials="D. R." surname="Ucci" fullname="Donald R. Ucci"> <author initials="D. R." surname="Ucci" fullname="Donald R. Ucci">
<organization/> <organization/>
</author> </author>
<date year="2008"/> <date month="January" year="2008"/>
</front> </front>
<seriesInfo name="2008 5th IEEE Consumer Communications and Networking C <seriesInfo name="DOI" value="10.1109/ccnc08.2007.21"/>
onference 5th IEEE, pp. 67-68" value=""/> <refcontent>2008 5th IEEE Consumer Communications and Networking Conferen
ce, pp. 67-68</refcontent>
</reference> </reference>
<reference anchor="BEHAVE" target="https://dl.acm.org/doi/abs/10.1145/1526 709.1526745"> <reference anchor="BEHAVE" target="https://dl.acm.org/doi/abs/10.1145/1526 709.1526745">
<front> <front>
<title>How much can behavioral targeting help online advertising?</tit le> <title>How much can behavioral targeting help online advertising?</tit le>
<author initials="J." surname="Yan" fullname="Jun Yan"> <author initials="J." surname="Yan" fullname="Jun Yan">
<organization/> <organization/>
</author> </author>
<author initials="N." surname="Liu" fullname="Ning Liu"> <author initials="N." surname="Liu" fullname="Ning Liu">
<organization/> <organization/>
</author> </author>
<author initials="G." surname="Wang" fullname="Gang Wang"> <author initials="G." surname="Wang" fullname="Gang Wang">
skipping to change at line 938 skipping to change at line 976
</author> </author>
<author initials="W." surname="Zhang" fullname="Wen Zhang"> <author initials="W." surname="Zhang" fullname="Wen Zhang">
<organization/> <organization/>
</author> </author>
<author initials="Y." surname="Jiang" fullname="Yun Jiang"> <author initials="Y." surname="Jiang" fullname="Yun Jiang">
<organization/> <organization/>
</author> </author>
<author initials="Z." surname="Chen" fullname="Zheng Chen"> <author initials="Z." surname="Chen" fullname="Zheng Chen">
<organization/> <organization/>
</author> </author>
<date year="2009" month="April" day="20"/> <date year="2009" month="April"/>
</front> </front>
<seriesInfo name="WWW '09: Proceedings of the 18th international confere <seriesInfo name="DOI" value="10.1145/1526709.1526745"/>
nce on World wide webApril 2009 Pages 261-270" value=""/> <refcontent>WWW '09: Proceedings of the 18th international conference on
World wide web, pp. 261-270</refcontent>
</reference> </reference>
<reference anchor="BEHAVE2" target="https://dl.acm.org/doi/abs/10.1145/194 1487.1941498"> <reference anchor="BEHAVE2" target="https://dl.acm.org/doi/abs/10.1145/194 1487.1941498">
<front> <front>
<title>Online advertising, behavioral targeting, and privacy</title> <title>Online advertising, behavioral targeting, and privacy</title>
<author initials="A." surname="Goldfarb" fullname="Avi Goldfarb"> <author initials="A." surname="Goldfarb" fullname="Avi Goldfarb">
<organization/> <organization/>
</author> </author>
<author initials="C. E." surname="Tucker" fullname="Catherine E. Tucke r"> <author initials="C. E." surname="Tucker" fullname="Catherine E. Tucke r">
<organization/> <organization/>
</author> </author>
<date year="2011" month="May" day="01"/> <date year="2011" month="May"/>
</front> </front>
<seriesInfo name="Communications of the ACMVolume 54Issue 5May 2011 pp 2 <seriesInfo name="DOI" value="10.1145/1941487.1941498"/>
5-27" value=""/> <refcontent>Communications of the ACM, Volume 54, Issue 5, pp. 25-27</ref
content>
</reference> </reference>
<reference anchor="ADFRAUD" target="https://doi.org/10.3390/jcp1040039"> <reference anchor="ADFRAUD" target="https://doi.org/10.3390/jcp1040039">
<front> <front>
<title>Ads and Fraud: A Comprehensive Survey of Fraud in Online Advert ising</title> <title>Ads and Fraud: A Comprehensive Survey of Fraud in Online Advert ising</title>
<author initials="S." surname="Sadeghpour" fullname="Shadi Sadeghpour" > <author initials="S." surname="Sadeghpour" fullname="Shadi Sadeghpour" >
<organization/> <organization/>
</author> </author>
<author initials="N." surname="Vlajic" fullname="Natalija Vlajic"> <author initials="N." surname="Vlajic" fullname="Natalija Vlajic">
<organization/> <organization/>
</author> </author>
<date year="2021" month="December" day="16"/> <date year="2021" month="December"/>
</front> </front>
<seriesInfo name="Journal of Cybersecurity and Privacy 1, no. 4: 804-832 <seriesInfo name="DOI" value="10.3390/jcp1040039"/>
." value=""/> <refcontent>Journal of Cybersecurity and Privacy 1, no. 4, pp. 804-832</r
efcontent>
</reference> </reference>
<reference anchor="BALANCING" target="https://digitalcommons.law.scu.edu/c htlj/vol27/iss1/2/"> <reference anchor="BALANCING" target="https://digitalcommons.law.scu.edu/c htlj/vol27/iss1/2/">
<front> <front>
<title>Balancing Consumer Privacy with Behavioral Targeting</title> <title>Balancing Consumer Privacy with Behavioral Targeting</title>
<author initials="D. D." surname="Berger" fullname="Dustin D. Berger"> <author initials="D." surname="Berger" fullname="Dustin D. Berger">
<organization/> <organization/>
</author> </author>
<date year="2010"/> <date year="2010"/>
</front> </front>
<seriesInfo name="27 Santa Clara High Technology Law Journal, Vol. 27 Is sue 1 Article 2" value=""/> <refcontent>Santa Clara High Technology Law Journal, Vol. 27, Issue 1, Ar ticle 2</refcontent>
</reference> </reference>
<reference anchor="IAB-ADS" target="https://www.iab.com/"> <reference anchor="IAB-ADS" target="https://www.iab.com/">
<front> <front>
<title>IAB</title> <title>IAB</title>
<author> <author>
<organization/> <organization/>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="BAP" target="https://www.betterads.org/"> <reference anchor="BAP" target="https://www.betterads.org/">
<front> <front>
<title>The Coalition for Better Ads</title> <title>Making Online Ads Better for Everyone</title>
<author> <author>
<organization/> <organization>Coalition for Better Ads</organization>
</author> </author>
<date>n.d.</date>
</front> </front>
</reference> </reference>
<reference anchor="CoDel"> <reference anchor="CoDel">
<front> <front>
<title>Controlling Queue Delay</title> <title>Controlling queue delay</title>
<author initials="K." surname="Nichols"> <author initials="K." surname="Nichols">
<organization/> <organization/>
</author> </author>
<author initials="V." surname="Jacobson"> <author initials="V." surname="Jacobson">
<organization/> <organization/>
</author> </author>
<date year="2012" month="July"/> <date year="2012" month="July"/>
</front> </front>
<seriesInfo name="Communications of the ACM, Volume 55, Issue 7, pp. 42- <seriesInfo name="DOI" value="10.1145/2209249.2209264"/>
50" value=""/> <refcontent>Communications of the ACM, Volume 55, Issue 7, pp. 42-50"</re
fcontent>
</reference> </reference>
<reference anchor="Survey360o" target="https://ieeexplore.ieee.org/documen
t/9133103"> <reference anchor="Survey360" target="https://ieeexplore.ieee.org/document
/9133103">
<front> <front>
<title>A Survey on Adaptive 360 Video Streaming: Solutions, Challenges and Opportunities</title> <title>A Survey on Adaptive 360° Video Streaming: Solutions, Challenge s and Opportunities</title>
<author initials="A." surname="Yaqoob"> <author initials="A." surname="Yaqoob">
<organization/> <organization/>
</author> </author>
<author initials="T." surname="Bi"> <author initials="T." surname="Bi">
<organization/> <organization/>
</author> </author>
<author initials="G." surname="Muntean"> <author initials="G." surname="Muntean">
<organization/> <organization/>
</author> </author>
<date year="2020" month="July"/> <date year="2020" month="July"/>
</front> </front>
<seriesInfo name="IEEE Communications Surveys &amp; Tutorials" value=""/ <seriesInfo name="DOI" value="10.1109/COMST.2020.3006999"/>
> <refcontent>IEEE Communications Surveys &amp; Tutorials, Volume 22, Issue
4</refcontent>
</reference> </reference>
<reference anchor="ISOBMFF" target="https://www.iso.org/standard/83102.htm l"> <reference anchor="ISOBMFF" target="https://www.iso.org/standard/83102.htm l">
<front> <front>
<title>ISO/IEC 14496-12:2022 Information technology - Coding of audio- visual objects - Part 12: ISO base media file format</title> <title>Information technology - Coding of audio-visual objects - Part 12: ISO base media file format</title>
<author> <author>
<organization/> <organization>ISO</organization>
</author> </author>
<date year="2022" month="January"/> <date year="2022" month="January"/>
</front> </front>
<seriesInfo name="ISO/IEC" value="14496-12:2022"/>
</reference> </reference>
<reference anchor="I-D.ietf-quic-manageability">
<front>
<title>Manageability of the QUIC Transport Protocol</title>
<author fullname="Mirja Kuehlewind">
<organization>Ericsson</organization>
</author>
<author fullname="Brian Trammell">
<organization>Google Switzerland GmbH</organization>
</author>
<date day="15" month="July" year="2022"/>
<abstract>
<t> This document discusses manageability of the QUIC transport pr
otocol,
focusing on the implications of QUIC's design and wire image on
network operations involving QUIC traffic. It is intended as a
"user's manual" for the wire image, providing guidance for network
operators and equipment vendors who rely on the use of transport-
aware network functions.
</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9312.
</abstract> xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-quic-manageability-1
8"/>
</reference>
<reference anchor="I-D.cardwell-iccrg-bbr-congestion-control">
<front>
<title>BBR Congestion Control</title>
<author fullname="Neal Cardwell">
<organization>Google</organization>
</author>
<author fullname="Yuchung Cheng">
<organization>Google</organization>
</author>
<author fullname="Soheil Hassas Yeganeh">
<organization>Google</organization>
</author>
<author fullname="Ian Swett">
<organization>Google</organization>
</author>
<author fullname="Van Jacobson">
<organization>Google</organization>
</author>
<date day="7" month="March" year="2022"/>
<abstract>
<t> This document specifies the BBR congestion control algorithm.
BBR
("Bottleneck Bandwidth and Round-trip propagation time") uses recent
measurements of a transport connection's delivery rate, round-trip
time, and packet loss rate to build an explicit model of the network
path. BBR then uses this model to control both how fast it sends
data and the maximum volume of data it allows in flight in the
network at any time. Relative to loss-based congestion control
algorithms such as Reno [RFC5681] or CUBIC [RFC8312], BBR offers
substantially higher throughput for bottlenecks with shallow buffers
or random losses, and substantially lower queueing delays for
bottlenecks with deep buffers (avoiding "bufferbloat"). BBR can be
implemented in any transport protocol that supports packet-delivery
acknowledgment. Thus far, open source implementations are available
for TCP [RFC793] and QUIC [RFC9000]. This document specifies version
2 of the BBR algorithm, also sometimes referred to as BBRv2 or bbr2.
</t> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.cardwel
</abstract> l-iccrg-bbr-congestion-control.xml"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-cardwell-iccrg-bbr-conges
tion-control-02"/>
</reference>
<reference anchor="I-D.draft-pantos-hls-rfc8216bis">
<front>
<title>HTTP Live Streaming 2nd Edition</title>
<author fullname="Roger Pantos">
<organization>Apple Inc.</organization>
</author>
<date day="11" month="May" year="2022"/>
<abstract>
<t> This document obsoletes RFC 8216. It describes a protocol for
transferring unbounded streams of multimedia data. It specifies the
data format of the files and the actions to be taken by the server
(sender) and the clients (receivers) of the streams. It describes
version 10 of this protocol.
</t> <reference anchor="HLS-RFC8216BIS" target="https://www.ietf.org/archive/id/draft
</abstract> -pantos-hls-rfc8216bis-11.txt">
</front> <front>
<seriesInfo name="Internet-Draft" value="draft-pantos-hls-rfc8216bis-11" <title>HTTP Live Streaming 2nd Edition</title>
/> <author initials="R" surname="Pantos" fullname="Roger Pantos" role="editor">
</reference> <organization>Apple Inc.</organization>
<reference anchor="I-D.ietf-tcpm-rfc793bis"> </author>
<front> <date day="11" month="May" year="2022"/>
<title>Transmission Control Protocol (TCP) Specification</title> </front>
<author fullname="Wesley M. Eddy"> <seriesInfo name="Internet-Draft" value="draft-pantos-hls-rfc8216bis-11"/>
<organization>MTI Systems</organization> </reference>
</author>
<date day="7" month="March" year="2022"/>
<abstract>
<t> This document specifies the Transmission Control Protocol (TCP
). TCP
is an important transport layer protocol in the Internet protocol
stack, and has continuously evolved over decades of use and growth of
the Internet. Over this time, a number of changes have been made to
TCP as it was specified in RFC 793, though these have only been
documented in a piecemeal fashion. This document collects and brings
those changes together with the protocol specification from RFC 793.
This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,
6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs
1011 and 1122, and should be considered as a replacement for the
portions of those document dealing with TCP requirements. It also
updates RFC 5961 by adding a small clarification in reset handling
while in the SYN-RECEIVED state. The TCP header control bits from
RFC 793 have also been updated based on RFC 3168.
RFC EDITOR NOTE: If approved for publication as an RFC, this should <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9293.
be marked additionally as "STD: 7" and replace RFC 793 in that role. xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2001.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2736.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3135.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3168.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3758.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4733.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5481.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5594.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5681.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5762.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6190.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6582.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6817.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6843.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7258.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7414.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7510.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7656.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7661.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8083.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8084.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8085.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8095.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8216.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8312.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8404.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8622.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8723.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8824.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8825.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8834.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8835.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8999.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9000.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9001.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9002.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9065.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9114.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9260.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9111.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9075.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.9221.
xml"/>
</t> </references>
</abstract> <section anchor="acknowledgments" numbered="false">
</front> <name>Acknowledgments</name>
<seriesInfo name="Internet-Draft" value="draft-ietf-tcpm-rfc793bis-28"/> <t>Thanks to <contact fullname="Nancy Cam-Winget"/>, <contact fullname="Le
</reference> slie Daigle"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Glenn De
<reference anchor="RFC2001"> en"/>, <contact fullname="Martin Duke"/>, <contact fullname="Linda Dunbar"/>, <c
<front> ontact fullname="Lars Eggert"/>, <contact fullname="Mike English"/>, <contact fu
<title>TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast llname="Roni Even"/>, <contact fullname="Aaron Falk"/>, <contact fullname="Alexa
Recovery Algorithms</title> ndre Gouaillard"/>, <contact fullname="Erik Kline"/>, <contact fullname="Renan K
<author fullname="W. Stevens" initials="W." surname="Stevens"> rishna"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Will Law"/>,
<organization/> <contact fullname="Chris Lemmons"/>, <contact fullname="Kiran Makhjani"/>, <cont
</author> act fullname="Sanjay Mishra"/>, <contact fullname="Mark Nottingham"/>, <contact
<date month="January" year="1997"/> fullname="Dave Oran"/>, <contact fullname="Lucas Pardue"/>, <contact fullname="T
<abstract> ommy Pauly"/>, <contact fullname="Kyle Rose"/>, <contact fullname="Zahed Sarker"
<t>Modern implementations of TCP contain four intertwined algorithms />, <contact fullname="Michael Scharf"/>, <contact fullname="John Scudder"/>, <c
that have never been fully documented as Internet standards: slow start, conges ontact fullname="Valery Smyslov"/>, <contact fullname="Matt Stock"/>, <contact f
tion avoidance, fast retransmit, and fast recovery. [STANDARDS-TRACK]</t> ullname="Éric Vyncke"/>, and <contact fullname="Robert Wilton"/> for very helpfu
</abstract> l suggestions, reviews, and comments.</t>
</front> </section>
<seriesInfo name="RFC" value="2001"/>
<seriesInfo name="DOI" value="10.17487/RFC2001"/>
</reference>
<reference anchor="RFC2736">
<front>
<title>Guidelines for Writers of RTP Payload Format Specifications</ti
tle>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization/>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization/>
</author>
<date month="December" year="1999"/>
<abstract>
<t>This document provides general guidelines aimed at assisting the
authors of RTP Payload Format specifications in deciding on good formats. This
document specifies an Internet Best Current Practices for the Internet Community
, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="36"/>
<seriesInfo name="RFC" value="2736"/>
<seriesInfo name="DOI" value="10.17487/RFC2736"/>
</reference>
<reference anchor="RFC3135">
<front>
<title>Performance Enhancing Proxies Intended to Mitigate Link-Related
Degradations</title>
<author fullname="J. Border" initials="J." surname="Border">
<organization/>
</author>
<author fullname="M. Kojo" initials="M." surname="Kojo">
<organization/>
</author>
<author fullname="J. Griner" initials="J." surname="Griner">
<organization/>
</author>
<author fullname="G. Montenegro" initials="G." surname="Montenegro">
<organization/>
</author>
<author fullname="Z. Shelby" initials="Z." surname="Shelby">
<organization/>
</author>
<date month="June" year="2001"/>
<abstract>
<t>This document is a survey of Performance Enhancing Proxies (PEPs)
often employed to improve degraded TCP performance caused by characteristics of
specific link environments, for example, in satellite, wireless WAN, and wirele
ss LAN environments. This memo provides information for the Internet community.
</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3135"/>
<seriesInfo name="DOI" value="10.17487/RFC3135"/>
</reference>
<reference anchor="RFC3168">
<front>
<title>The Addition of Explicit Congestion Notification (ECN) to IP</t
itle>
<author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan
">
<organization/>
</author>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author fullname="D. Black" initials="D." surname="Black">
<organization/>
</author>
<date month="September" year="2001"/>
<abstract>
<t>This memo specifies the incorporation of ECN (Explicit Congestion
Notification) to TCP and IP, including ECN's use of two bits in the IP header.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3168"/>
<seriesInfo name="DOI" value="10.17487/RFC3168"/>
</reference>
<reference anchor="RFC3550">
<front>
<title>RTP: A Transport Protocol for Real-Time Applications</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization/>
</author>
<author fullname="S. Casner" initials="S." surname="Casner">
<organization/>
</author>
<author fullname="R. Frederick" initials="R." surname="Frederick">
<organization/>
</author>
<author fullname="V. Jacobson" initials="V." surname="Jacobson">
<organization/>
</author>
<date month="July" year="2003"/>
<abstract>
<t>This memorandum describes RTP, the real-time transport protocol.
RTP provides end-to-end network transport functions suitable for applications t
ransmitting real-time data, such as audio, video or simulation data, over multic
ast or unicast network services. RTP does not address resource reservation and
does not guarantee quality-of- service for real-time services. The data transpo
rt is augmented by a control protocol (RTCP) to allow monitoring of the data del
ivery in a manner scalable to large multicast networks, and to provide minimal c
ontrol and identification functionality. RTP and RTCP are designed to be indepe
ndent of the underlying transport and network layers. The protocol supports the
use of RTP-level translators and mixers. Most of the text in this memorandum is
identical to RFC 1889 which it obsoletes. There are no changes in the packet f
ormats on the wire, only changes to the rules and algorithms governing how the p
rotocol is used. The biggest change is an enhancement to the scalable timer algo
rithm for calculating when to send RTCP packets in order to minimize transmissio
n in excess of the intended rate when many participants join a session simultane
ously. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="64"/>
<seriesInfo name="RFC" value="3550"/>
<seriesInfo name="DOI" value="10.17487/RFC3550"/>
</reference>
<reference anchor="RFC3758">
<front>
<title>Stream Control Transmission Protocol (SCTP) Partial Reliability
Extension</title>
<author fullname="R. Stewart" initials="R." surname="Stewart">
<organization/>
</author>
<author fullname="M. Ramalho" initials="M." surname="Ramalho">
<organization/>
</author>
<author fullname="Q. Xie" initials="Q." surname="Xie">
<organization/>
</author>
<author fullname="M. Tuexen" initials="M." surname="Tuexen">
<organization/>
</author>
<author fullname="P. Conrad" initials="P." surname="Conrad">
<organization/>
</author>
<date month="May" year="2004"/>
<abstract>
<t>This memo describes an extension to the Stream Control Transmissi
on Protocol (SCTP) that allows an SCTP endpoint to signal to its peer that it sh
ould move the cumulative ack point forward. When both sides of an SCTP associat
ion support this extension, it can be used by an SCTP implementation to provide
partially reliable data transmission service to an upper layer protocol. This m
emo describes the protocol extensions, which consist of a new parameter for INIT
and INIT ACK, and a new FORWARD TSN chunk type, and provides one example of a p
artially reliable service that can be provided to the upper layer via this mecha
nism. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3758"/>
<seriesInfo name="DOI" value="10.17487/RFC3758"/>
</reference>
<reference anchor="RFC4733">
<front>
<title>RTP Payload for DTMF Digits, Telephony Tones, and Telephony Sig
nals</title>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization/>
</author>
<author fullname="T. Taylor" initials="T." surname="Taylor">
<organization/>
</author>
<date month="December" year="2006"/>
<abstract>
<t>This memo describes how to carry dual-tone multifrequency (DTMF)
signalling, other tone signals, and telephony events in RTP packets. It obsolete
s RFC 2833.</t>
<t>This memo captures and expands upon the basic framework defined i
n RFC 2833, but retains only the most basic event codes. It sets up an IANA reg
istry to which other event code assignments may be added. Companion documents ad
d event codes to this registry relating to modem, fax, text telephony, and chann
el-associated signalling events. The remainder of the event codes defined in RFC
2833 are conditionally reserved in case other documents revive their use.</t>
<t>This document provides a number of clarifications to the original
document. However, it specifically differs from RFC 2833 by removing the requi
rement that all compliant implementations support the DTMF events. Instead, com
pliant implementations taking part in out-of-band negotiations of media stream c
ontent indicate what events they support. This memo adds three new procedures t
o the RFC 2833 framework: subdivision of long events into segments, reporting of
multiple events in a single packet, and the concept and reporting of state even
ts. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4733"/>
<seriesInfo name="DOI" value="10.17487/RFC4733"/>
</reference>
<reference anchor="RFC5481">
<front>
<title>Packet Delay Variation Applicability Statement</title>
<author fullname="A. Morton" initials="A." surname="Morton">
<organization/>
</author>
<author fullname="B. Claise" initials="B." surname="Claise">
<organization/>
</author>
<date month="March" year="2009"/>
<abstract>
<t>Packet delay variation metrics appear in many different standards
documents. The metric definition in RFC 3393 has considerable flexibility, and
it allows multiple formulations of delay variation through the specification of
different packet selection functions.</t>
<t>Although flexibility provides wide coverage and room for new idea
s, it can make comparisons of independent implementations more difficult. Two d
ifferent formulations of delay variation have come into wide use in the context
of active measurements. This memo examines a range of circumstances for active
measurements of delay variation and their uses, and recommends which of the two
forms is best matched to particular conditions and tasks. This memo provides i
nformation for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5481"/>
<seriesInfo name="DOI" value="10.17487/RFC5481"/>
</reference>
<reference anchor="RFC5594">
<front>
<title>Report from the IETF Workshop on Peer-to-Peer (P2P) Infrastruct
ure, May 28, 2008</title>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization/>
</author>
<author fullname="A. Cooper" initials="A." surname="Cooper">
<organization/>
</author>
<date month="July" year="2009"/>
<abstract>
<t>This document reports the outcome of a workshop organized by the
Real-time Applications and Infrastructure Area Directors of the IETF to discuss
network delay and congestion issues resulting from increased Peer-to-Peer (P2P)
traffic volumes. The workshop was held on May 28, 2008 at MIT in Cambridge, MA,
USA. The goals of the workshop were twofold: to understand the technical probl
ems that ISPs and end users are experiencing as a result of high volumes of P2P
traffic, and to begin to understand how the IETF may be helpful in addressing th
ese problems. Gaining an understanding of where in the IETF this work might be
pursued and how to extract feasible work items were highlighted as important tas
ks in pursuit of the latter goal. The workshop was very well attended and produ
ced several work items that have since been taken up by members of the IETF comm
unity. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5594"/>
<seriesInfo name="DOI" value="10.17487/RFC5594"/>
</reference>
<reference anchor="RFC5681">
<front>
<title>TCP Congestion Control</title>
<author fullname="M. Allman" initials="M." surname="Allman">
<organization/>
</author>
<author fullname="V. Paxson" initials="V." surname="Paxson">
<organization/>
</author>
<author fullname="E. Blanton" initials="E." surname="Blanton">
<organization/>
</author>
<date month="September" year="2009"/>
<abstract>
<t>This document defines TCP's four intertwined congestion control a
lgorithms: slow start, congestion avoidance, fast retransmit, and fast recovery.
In addition, the document specifies how TCP should begin transmission after a
relatively long idle period, as well as discussing various acknowledgment genera
tion methods. This document obsoletes RFC 2581. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5681"/>
<seriesInfo name="DOI" value="10.17487/RFC5681"/>
</reference>
<reference anchor="RFC5762">
<front>
<title>RTP and the Datagram Congestion Control Protocol (DCCP)</title>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization/>
</author>
<date month="April" year="2010"/>
<abstract>
<t>The Real-time Transport Protocol (RTP) is a widely used transport
for real-time multimedia on IP networks. The Datagram Congestion Control Proto
col (DCCP) is a transport protocol that provides desirable services for real-tim
e applications. This memo specifies a mapping of RTP onto DCCP, along with asso
ciated signalling, such that real- time applications can make use of the service
s provided by DCCP. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5762"/>
<seriesInfo name="DOI" value="10.17487/RFC5762"/>
</reference>
<reference anchor="RFC6190">
<front>
<title>RTP Payload Format for Scalable Video Coding</title>
<author fullname="S. Wenger" initials="S." surname="Wenger">
<organization/>
</author>
<author fullname="Y.-K. Wang" initials="Y.-K." surname="Wang">
<organization/>
</author>
<author fullname="T. Schierl" initials="T." surname="Schierl">
<organization/>
</author>
<author fullname="A. Eleftheriadis" initials="A." surname="Eleftheriad
is">
<organization/>
</author>
<date month="May" year="2011"/>
<abstract>
<t>This memo describes an RTP payload format for Scalable Video Codi
ng (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is technical
ly identical to Amendment 3 of ISO/IEC International Standard 14496-10. The RTP
payload format allows for packetization of one or more Network Abstraction Laye
r (NAL) units in each RTP packet payload, as well as fragmentation of a NAL unit
in multiple RTP packets. Furthermore, it supports transmission of an SVC stream
over a single as well as multiple RTP sessions. The payload format defines a n
ew media subtype name "H264-SVC", but is still backward compatible to RFC 6184 s
ince the base layer, when encapsulated in its own RTP stream, must use the H.264
media subtype name ("H264") and the packetization method specified in RFC 6184.
The payload format has wide applicability in videoconferencing, Internet video
streaming, and high-bitrate entertainment-quality video, among others. [STANDA
RDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6190"/>
<seriesInfo name="DOI" value="10.17487/RFC6190"/>
</reference>
<reference anchor="RFC6582">
<front>
<title>The NewReno Modification to TCP's Fast Recovery Algorithm</titl
e>
<author fullname="T. Henderson" initials="T." surname="Henderson">
<organization/>
</author>
<author fullname="S. Floyd" initials="S." surname="Floyd">
<organization/>
</author>
<author fullname="A. Gurtov" initials="A." surname="Gurtov">
<organization/>
</author>
<author fullname="Y. Nishida" initials="Y." surname="Nishida">
<organization/>
</author>
<date month="April" year="2012"/>
<abstract>
<t>RFC 5681 documents the following four intertwined TCP congestion
control algorithms: slow start, congestion avoidance, fast retransmit, and fast
recovery. RFC 5681 explicitly allows certain modifications of these algorithms,
including modifications that use the TCP Selective Acknowledgment (SACK) option
(RFC 2883), and modifications that respond to "partial acknowledgments" (ACKs t
hat cover new data, but not all the data outstanding when loss was detected) in
the absence of SACK. This document describes a specific algorithm for respondin
g to partial acknowledgments, referred to as "NewReno". This response to partia
l acknowledgments was first proposed by Janey Hoe. This document obsoletes RFC
3782. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6582"/>
<seriesInfo name="DOI" value="10.17487/RFC6582"/>
</reference>
<reference anchor="RFC6817">
<front>
<title>Low Extra Delay Background Transport (LEDBAT)</title>
<author fullname="S. Shalunov" initials="S." surname="Shalunov">
<organization/>
</author>
<author fullname="G. Hazel" initials="G." surname="Hazel">
<organization/>
</author>
<author fullname="J. Iyengar" initials="J." surname="Iyengar">
<organization/>
</author>
<author fullname="M. Kuehlewind" initials="M." surname="Kuehlewind">
<organization/>
</author>
<date month="December" year="2012"/>
<abstract>
<t>Low Extra Delay Background Transport (LEDBAT) is an experimental
delay-based congestion control algorithm that seeks to utilize the available ban
dwidth on an end-to-end path while limiting the consequent increase in queueing
delay on that path. LEDBAT uses changes in one-way delay measurements to limit
congestion that the flow itself induces in the network. LEDBAT is designed for
use by background bulk-transfer applications to be no more aggressive than stand
ard TCP congestion control (as specified in RFC 5681) and to yield in the presen
ce of competing flows, thus limiting interference with the network performance o
f competing flows. This document defines an Experimental Protocol for the Inte
rnet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6817"/>
<seriesInfo name="DOI" value="10.17487/RFC6817"/>
</reference>
<reference anchor="RFC6843">
<front>
<title>RTP Control Protocol (RTCP) Extended Report (XR) Block for Dela
y Metric Reporting</title>
<author fullname="A. Clark" initials="A." surname="Clark">
<organization/>
</author>
<author fullname="K. Gross" initials="K." surname="Gross">
<organization/>
</author>
<author fullname="Q. Wu" initials="Q." surname="Wu">
<organization/>
</author>
<date month="January" year="2013"/>
<abstract>
<t>This document defines an RTP Control Protocol (RTCP) Extended Rep
ort (XR) block that allows the reporting of delay metrics for use in a range of
Real-time Transport Protocol (RTP) applications. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6843"/>
<seriesInfo name="DOI" value="10.17487/RFC6843"/>
</reference>
<reference anchor="RFC7258">
<front>
<title>Pervasive Monitoring Is an Attack</title>
<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization/>
</author>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig">
<organization/>
</author>
<date month="May" year="2014"/>
<abstract>
<t>Pervasive monitoring is a technical attack that should be mitigat
ed in the design of IETF protocols, where possible.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="188"/>
<seriesInfo name="RFC" value="7258"/>
<seriesInfo name="DOI" value="10.17487/RFC7258"/>
</reference>
<reference anchor="RFC7414">
<front>
<title>A Roadmap for Transmission Control Protocol (TCP) Specification
Documents</title>
<author fullname="M. Duke" initials="M." surname="Duke">
<organization/>
</author>
<author fullname="R. Braden" initials="R." surname="Braden">
<organization/>
</author>
<author fullname="W. Eddy" initials="W." surname="Eddy">
<organization/>
</author>
<author fullname="E. Blanton" initials="E." surname="Blanton">
<organization/>
</author>
<author fullname="A. Zimmermann" initials="A." surname="Zimmermann">
<organization/>
</author>
<date month="February" year="2015"/>
<abstract>
<t>This document contains a roadmap to the Request for Comments (RFC
) documents relating to the Internet's Transmission Control Protocol (TCP). Thi
s roadmap provides a brief summary of the documents defining TCP and various TCP
extensions that have accumulated in the RFC series. This serves as a guide and
quick reference for both TCP implementers and other parties who desire informat
ion contained in the TCP-related RFCs.</t>
<t>This document obsoletes RFC 4614.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7414"/>
<seriesInfo name="DOI" value="10.17487/RFC7414"/>
</reference>
<reference anchor="RFC7510">
<front>
<title>Encapsulating MPLS in UDP</title>
<author fullname="X. Xu" initials="X." surname="Xu">
<organization/>
</author>
<author fullname="N. Sheth" initials="N." surname="Sheth">
<organization/>
</author>
<author fullname="L. Yong" initials="L." surname="Yong">
<organization/>
</author>
<author fullname="R. Callon" initials="R." surname="Callon">
<organization/>
</author>
<author fullname="D. Black" initials="D." surname="Black">
<organization/>
</author>
<date month="April" year="2015"/>
<abstract>
<t>This document specifies an IP-based encapsulation for MPLS, calle
d MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is
preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Mul
tipath) or link aggregation. The MPLS- in-UDP encapsulation technology must onl
y be deployed within a single network (with a single network operator) or networ
ks of an adjacent set of cooperating network operators where traffic is managed
to avoid congestion, rather than over the Internet where congestion control is r
equired. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not
congestion controlled and to UDP zero checksum usage with IPv6.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7510"/>
<seriesInfo name="DOI" value="10.17487/RFC7510"/>
</reference>
<reference anchor="RFC7656">
<front>
<title>A Taxonomy of Semantics and Mechanisms for Real-Time Transport
Protocol (RTP) Sources</title>
<author fullname="J. Lennox" initials="J." surname="Lennox">
<organization/>
</author>
<author fullname="K. Gross" initials="K." surname="Gross">
<organization/>
</author>
<author fullname="S. Nandakumar" initials="S." surname="Nandakumar">
<organization/>
</author>
<author fullname="G. Salgueiro" initials="G." surname="Salgueiro">
<organization/>
</author>
<author fullname="B. Burman" initials="B." role="editor" surname="Burm
an">
<organization/>
</author>
<date month="November" year="2015"/>
<abstract>
<t>The terminology about, and associations among, Real-time Transpor
t Protocol (RTP) sources can be complex and somewhat opaque. This document desc
ribes a number of existing and proposed properties and relationships among RTP s
ources and defines common terminology for discussing protocol entities and their
relationships.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7656"/>
<seriesInfo name="DOI" value="10.17487/RFC7656"/>
</reference>
<reference anchor="RFC7661">
<front>
<title>Updating TCP to Support Rate-Limited Traffic</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization/>
</author>
<author fullname="A. Sathiaseelan" initials="A." surname="Sathiaseelan
">
<organization/>
</author>
<author fullname="R. Secchi" initials="R." surname="Secchi">
<organization/>
</author>
<date month="October" year="2015"/>
<abstract>
<t>This document provides a mechanism to address issues that arise w
hen TCP is used for traffic that exhibits periods where the sending rate is limi
ted by the application rather than the congestion window. It provides an experi
mental update to TCP that allows a TCP sender to restart quickly following a rat
e-limited interval. This method is expected to benefit applications that send r
ate-limited traffic using TCP while also providing an appropriate response if co
ngestion is experienced.</t>
<t>This document also evaluates the Experimental specification of TC
P Congestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC
2861 sought to address important issues but failed to deliver a widely used solu
tion. This document therefore reclassifies the status of RFC 2861 from Experime
ntal to Historic. This document obsoletes RFC 2861.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7661"/>
<seriesInfo name="DOI" value="10.17487/RFC7661"/>
</reference>
<reference anchor="RFC8083">
<front>
<title>Multimedia Congestion Control: Circuit Breakers for Unicast RTP
Sessions</title>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization/>
</author>
<author fullname="V. Singh" initials="V." surname="Singh">
<organization/>
</author>
<date month="March" year="2017"/>
<abstract>
<t>The Real-time Transport Protocol (RTP) is widely used in telephon
y, video conferencing, and telepresence applications. Such applications are oft
en run on best-effort UDP/IP networks. If congestion control is not implemented
in these applications, then network congestion can lead to uncontrolled packet
loss and a resulting deterioration of the user's multimedia experience. The con
gestion control algorithm acts as a safety measure by stopping RTP flows from us
ing excessive resources and protecting the network from overload. At the time o
f this writing, however, while there are several proprietary solutions, there is
no standard algorithm for congestion control of interactive RTP flows.</t>
<t>This document does not propose a congestion control algorithm. I
t instead defines a minimal set of RTP circuit breakers: conditions under which
an RTP sender needs to stop transmitting media data to protect the network from
excessive congestion. It is expected that, in the absence of long-lived excessi
ve congestion, RTP applications running on best-effort IP networks will be able
to operate without triggering these circuit breakers. To avoid triggering the R
TP circuit breaker, any Standards Track congestion control algorithms defined fo
r RTP will need to operate within the envelope set by these RTP circuit breaker
algorithms.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8083"/>
<seriesInfo name="DOI" value="10.17487/RFC8083"/>
</reference>
<reference anchor="RFC8084">
<front>
<title>Network Transport Circuit Breakers</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization/>
</author>
<date month="March" year="2017"/>
<abstract>
<t>This document explains what is meant by the term "network transpo
rt Circuit Breaker". It describes the need for Circuit
Breakers (CBs) for network tunnels and applications when using non-congestion-
controlled traffic and explains where CBs are, and are not, needed. It also defi
nes requirements for building a CB and the expected outcomes of using a CB withi
n the Internet.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="208"/>
<seriesInfo name="RFC" value="8084"/>
<seriesInfo name="DOI" value="10.17487/RFC8084"/>
</reference>
<reference anchor="RFC8085">
<front>
<title>UDP Usage Guidelines</title>
<author fullname="L. Eggert" initials="L." surname="Eggert">
<organization/>
</author>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization/>
</author>
<author fullname="G. Shepherd" initials="G." surname="Shepherd">
<organization/>
</author>
<date month="March" year="2017"/>
<abstract>
<t>The User Datagram Protocol (UDP) provides a minimal message-passi
ng transport that has no inherent congestion control mechanisms. This document
provides guidelines on the use of UDP for the designers of applications, tunnels
, and other protocols that use UDP. Congestion control guidelines are a primary
focus, but the document also provides guidance on other topics, including messa
ge sizes, reliability, checksums, middlebox traversal, the use of Explicit Conge
stion Notification (ECN), Differentiated Services Code Points (DSCPs), and ports
.</t>
<t>Because congestion control is critical to the stable operation of
the Internet, applications and other protocols that choose to use UDP as an Int
ernet transport must employ mechanisms to prevent congestion collapse and to est
ablish some degree of fairness with concurrent traffic. They may also need to i
mplement additional mechanisms, depending on how they use UDP.</t>
<t>Some guidance is also applicable to the design of other protocols
(e.g., protocols layered directly on IP or via IP-based tunnels), especially wh
en these protocols do not themselves provide congestion control.</t>
<t>This document obsoletes RFC 5405 and adds guidelines for multicas
t UDP usage.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="145"/>
<seriesInfo name="RFC" value="8085"/>
<seriesInfo name="DOI" value="10.17487/RFC8085"/>
</reference>
<reference anchor="RFC8095">
<front>
<title>Services Provided by IETF Transport Protocols and Congestion Co
ntrol Mechanisms</title>
<author fullname="G. Fairhurst" initials="G." role="editor" surname="F
airhurst">
<organization/>
</author>
<author fullname="B. Trammell" initials="B." role="editor" surname="Tr
ammell">
<organization/>
</author>
<author fullname="M. Kuehlewind" initials="M." role="editor" surname="
Kuehlewind">
<organization/>
</author>
<date month="March" year="2017"/>
<abstract>
<t>This document describes, surveys, and classifies the protocol mec
hanisms provided by existing IETF protocols, as background for determining a com
mon set of transport services. It examines the Transmission Control Protocol (T
CP), Multipath TCP, the Stream Control Transmission Protocol (SCTP), the User Da
tagram Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol (DCCP)
, the Internet Control Message Protocol (ICMP), the Real-Time Transport Protocol
(RTP), File Delivery over Unidirectional Transport / Asynchronous Layered Codin
g (FLUTE/ALC) for Reliable Multicast, NACK- Oriented Reliable Multicast (NORM),
Transport Layer Security (TLS), Datagram TLS (DTLS), and the Hypertext Transport
Protocol (HTTP), when HTTP is used as a pseudotransport. This survey provides
background for the definition of transport services within the TAPS working grou
p.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8095"/>
<seriesInfo name="DOI" value="10.17487/RFC8095"/>
</reference>
<reference anchor="RFC8216">
<front>
<title>HTTP Live Streaming</title>
<author fullname="R. Pantos" initials="R." role="editor" surname="Pant
os">
<organization/>
</author>
<author fullname="W. May" initials="W." surname="May">
<organization/>
</author>
<date month="August" year="2017"/>
<abstract>
<t>This document describes a protocol for transferring unbounded str
eams of multimedia data. It specifies the data format of the files and the acti
ons to be taken by the server (sender) and the clients (receivers) of the stream
s. It describes version 7 of this protocol.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8216"/>
<seriesInfo name="DOI" value="10.17487/RFC8216"/>
</reference>
<reference anchor="RFC8312">
<front>
<title>CUBIC for Fast Long-Distance Networks</title>
<author fullname="I. Rhee" initials="I." surname="Rhee">
<organization/>
</author>
<author fullname="L. Xu" initials="L." surname="Xu">
<organization/>
</author>
<author fullname="S. Ha" initials="S." surname="Ha">
<organization/>
</author>
<author fullname="A. Zimmermann" initials="A." surname="Zimmermann">
<organization/>
</author>
<author fullname="L. Eggert" initials="L." surname="Eggert">
<organization/>
</author>
<author fullname="R. Scheffenegger" initials="R." surname="Scheffenegg
er">
<organization/>
</author>
<date month="February" year="2018"/>
<abstract>
<t>CUBIC is an extension to the current TCP standards. It differs f
rom the current TCP standards only in the congestion control algorithm on the se
nder side. In particular, it uses a cubic function instead of a linear window i
ncrease function of the current TCP standards to improve scalability and stabili
ty under fast and long-distance networks. CUBIC and its predecessor algorithm h
ave been adopted as defaults by Linux and have been used for many years. This d
ocument provides a specification of CUBIC to enable third-party implementations
and to solicit community feedback through experimentation on the performance of
CUBIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8312"/>
<seriesInfo name="DOI" value="10.17487/RFC8312"/>
</reference>
<reference anchor="RFC8404">
<front>
<title>Effects of Pervasive Encryption on Operators</title>
<author fullname="K. Moriarty" initials="K." role="editor" surname="Mo
riarty">
<organization/>
</author>
<author fullname="A. Morton" initials="A." role="editor" surname="Mort
on">
<organization/>
</author>
<date month="July" year="2018"/>
<abstract>
<t>Pervasive monitoring attacks on the privacy of Internet users are
of serious concern to both user and operator communities. RFC 7258 discusses t
he critical need to protect users' privacy when developing IETF specifications a
nd also recognizes that making networks unmanageable to mitigate pervasive monit
oring is not an acceptable outcome: an appropriate balance is needed. This docu
ment discusses current security and network operations as well as management pra
ctices that may be impacted by the shift to increased use of encryption to help
guide protocol development in support of manageable and secure networks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8404"/>
<seriesInfo name="DOI" value="10.17487/RFC8404"/>
</reference>
<reference anchor="RFC8446">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla">
<organization/>
</author>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Securi
ty (TLS) protocol. TLS allows client/server applications to communicate over th
e Internet in a way that is designed to prevent eavesdropping, tampering, and me
ssage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077
, 5246, and 6961. This document also specifies new requirements for TLS 1.2 imp
lementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="RFC8622">
<front>
<title>A Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Ser
vices</title>
<author fullname="R. Bless" initials="R." surname="Bless">
<organization/>
</author>
<date month="June" year="2019"/>
<abstract>
<t>This document specifies properties and characteristics of a Lower
- Effort Per-Hop Behavior (LE PHB). The primary objective of this LE PHB is to
protect Best-Effort (BE) traffic (packets forwarded with the default PHB) from L
E traffic in congestion situations, i.e., when resources become scarce, BE traff
ic has precedence over LE traffic and may preempt it. Alternatively, packets fo
rwarded by the LE PHB can be associated with a scavenger service class, i.e., th
ey scavenge otherwise-unused resources only. There are numerous uses for this P
HB, e.g., for background traffic of low precedence, such as bulk data transfers
with low priority in time, non-time-critical backups, larger software updates, w
eb search engines while gathering information from web servers and so on. This
document recommends a standard Differentiated Services Code Point (DSCP) value f
or the LE PHB.</t>
<t>This specification obsoletes RFC 3662 and updates the DSCP recomm
ended in RFCs 4594 and 8325 to use the DSCP assigned in this specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8622"/>
<seriesInfo name="DOI" value="10.17487/RFC8622"/>
</reference>
<reference anchor="RFC8723">
<front>
<title>Double Encryption Procedures for the Secure Real-Time Transport
Protocol (SRTP)</title>
<author fullname="C. Jennings" initials="C." surname="Jennings">
<organization/>
</author>
<author fullname="P. Jones" initials="P." surname="Jones">
<organization/>
</author>
<author fullname="R. Barnes" initials="R." surname="Barnes">
<organization/>
</author>
<author fullname="A.B. Roach" initials="A.B." surname="Roach">
<organization/>
</author>
<date month="April" year="2020"/>
<abstract>
<t>In some conferencing scenarios, it is desirable for an intermedia
ry to be able to manipulate some parameters in Real-time Transport Protocol (RTP
) packets, while still providing strong end-to-end security guarantees. This doc
ument defines a cryptographic transform for the Secure Real-time Transport Proto
col (SRTP) that uses two separate but related cryptographic operations to provid
e hop-by-hop and end-to-end security guarantees. Both the end-to-end and hop-by
-hop cryptographic algorithms can utilize an authenticated encryption with assoc
iated data (AEAD) algorithm or take advantage of future SRTP transforms with dif
ferent properties.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8723"/>
<seriesInfo name="DOI" value="10.17487/RFC8723"/>
</reference>
<reference anchor="RFC8824">
<front>
<title>Static Context Header Compression (SCHC) for the Constrained Ap
plication Protocol (CoAP)</title>
<author fullname="A. Minaburo" initials="A." surname="Minaburo">
<organization/>
</author>
<author fullname="L. Toutain" initials="L." surname="Toutain">
<organization/>
</author>
<author fullname="R. Andreasen" initials="R." surname="Andreasen">
<organization/>
</author>
<date month="June" year="2021"/>
<abstract>
<t>This document defines how to compress Constrained Application Pro
tocol (CoAP) headers using the Static Context Header Compression and fragmentati
on (SCHC) framework. SCHC defines a header compression mechanism adapted for Con
strained Devices. SCHC uses a static description of the header to reduce the hea
der's redundancy and size. While RFC 8724 describes the SCHC compression and fra
gmentation framework, and its application for IPv6/UDP headers, this document ap
plies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP,
since CoAP uses a flexible header with a variable number of options, themselves
of variable length. The CoAP message format is asymmetric: the request messages
have a header format different from the format in the response messages. This s
pecification gives guidance on applying SCHC to flexible headers and how to leve
rage the asymmetry for more efficient compression Rules.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8824"/>
<seriesInfo name="DOI" value="10.17487/RFC8824"/>
</reference>
<reference anchor="RFC8825">
<front>
<title>Overview: Real-Time Protocols for Browser-Based Applications</t
itle>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
<organization/>
</author>
<date month="January" year="2021"/>
<abstract>
<t>This document gives an overview and context of a protocol suite i
ntended for use with real-time applications that can be deployed in browsers --
"real-time communication on the Web".</t>
<t>It intends to serve as a starting and coordination point to make
sure that (1) all the parts that are needed to achieve this goal are findable an
d (2) the parts that belong in the Internet protocol suite are fully specified a
nd on the right publication track.</t>
<t>This document is an applicability statement -- it does not itself
specify any protocol, but it specifies which other specifications implementatio
ns are supposed to follow to be compliant with Web Real-Time Communication (WebR
TC).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8825"/>
<seriesInfo name="DOI" value="10.17487/RFC8825"/>
</reference>
<reference anchor="RFC8834">
<front>
<title>Media Transport and Use of RTP in WebRTC</title>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization/>
</author>
<author fullname="M. Westerlund" initials="M." surname="Westerlund">
<organization/>
</author>
<author fullname="J. Ott" initials="J." surname="Ott">
<organization/>
</author>
<date month="January" year="2021"/>
<abstract>
<t>The framework for Web Real-Time Communication (WebRTC) provides s
upport for direct interactive rich communication using audio, video, text, colla
boration, games, etc. between two peers' web browsers. This memo describes the m
edia transport aspects of the WebRTC framework. It specifies how the Real-time T
ransport Protocol (RTP) is used in the WebRTC context and gives requirements for
which RTP features, profiles, and extensions need to be supported.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8834"/>
<seriesInfo name="DOI" value="10.17487/RFC8834"/>
</reference>
<reference anchor="RFC8835">
<front>
<title>Transports for WebRTC</title>
<author fullname="H. Alvestrand" initials="H." surname="Alvestrand">
<organization/>
</author>
<date month="January" year="2021"/>
<abstract>
<t>This document describes the data transport protocols used by Web
Real-Time Communication (WebRTC), including the protocols used for interaction w
ith intermediate boxes such as firewalls, relays, and NAT boxes.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8835"/>
<seriesInfo name="DOI" value="10.17487/RFC8835"/>
</reference>
<reference anchor="RFC8999">
<front>
<title>Version-Independent Properties of QUIC</title>
<author fullname="M. Thomson" initials="M." surname="Thomson">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the properties of the QUIC transport protoc
ol that are common to all versions of the protocol.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8999"/>
<seriesInfo name="DOI" value="10.17487/RFC8999"/>
</reference>
<reference anchor="RFC9000">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="Iye
ngar">
<organization/>
</author>
<author fullname="M. Thomson" initials="M." role="editor" surname="Tho
mson">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document defines the core of the QUIC transport protocol. Q
UIC provides applications with flow-controlled streams for structured communicat
ion, low-latency connection establishment, and network path migration. QUIC incl
udes security measures that ensure confidentiality, integrity, and availability
in a range of deployment circumstances. Accompanying documents describe the int
egration of TLS for key negotiation, loss detection, and an exemplary congestion
control algorithm.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9000"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/>
</reference>
<reference anchor="RFC9001">
<front>
<title>Using TLS to Secure QUIC</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="Tho
mson">
<organization/>
</author>
<author fullname="S. Turner" initials="S." role="editor" surname="Turn
er">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document describes how Transport Layer Security (TLS) is use
d to secure QUIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9001"/>
<seriesInfo name="DOI" value="10.17487/RFC9001"/>
</reference>
<reference anchor="RFC9002">
<front>
<title>QUIC Loss Detection and Congestion Control</title>
<author fullname="J. Iyengar" initials="J." role="editor" surname="Iye
ngar">
<organization/>
</author>
<author fullname="I. Swett" initials="I." role="editor" surname="Swett
">
<organization/>
</author>
<date month="May" year="2021"/>
<abstract>
<t>This document describes loss detection and congestion control mec
hanisms for QUIC.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9002"/>
<seriesInfo name="DOI" value="10.17487/RFC9002"/>
</reference>
<reference anchor="RFC9065">
<front>
<title>Considerations around Transport Header Confidentiality, Network
Operations, and the Evolution of Internet Transport Protocols</title>
<author fullname="G. Fairhurst" initials="G." surname="Fairhurst">
<organization/>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization/>
</author>
<date month="July" year="2021"/>
<abstract>
<t>To protect user data and privacy, Internet transport protocols ha
ve supported payload encryption and authentication for some time. Such encryptio
n and authentication are now also starting to be applied to the transport protoc
ol headers. This helps avoid transport protocol ossification by middleboxes, mit
igate attacks against the transport protocol, and protect metadata about the com
munication. Current operational practice in some networks inspect transport head
er information within the network, but this is no longer possible when those tra
nsport headers are encrypted.</t>
<t>This document discusses the possible impact when network traffic
uses a protocol with an encrypted transport header. It suggests issues to consid
er when designing new transport protocols or features.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9065"/>
<seriesInfo name="DOI" value="10.17487/RFC9065"/>
</reference>
<reference anchor="RFC9114">
<front>
<title>HTTP/3</title>
<author fullname="M. Bishop" initials="M." role="editor" surname="Bish
op">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The QUIC transport protocol has several features that are desirab
le in a transport for HTTP, such as stream multiplexing, per-stream flow control
, and low-latency connection establishment. This document describes a mapping o
f HTTP semantics over QUIC. This document also identifies HTTP/2 features that
are subsumed by QUIC and describes how HTTP/2 extensions can be ported to HTTP/3
.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9114"/>
<seriesInfo name="DOI" value="10.17487/RFC9114"/>
</reference>
<reference anchor="RFC9260">
<front>
<title>Stream Control Transmission Protocol</title>
<author fullname="R. Stewart" initials="R." surname="Stewart">
<organization/>
</author>
<author fullname="M. Tüxen" initials="M." surname="Tüxen">
<organization/>
</author>
<author fullname="K. Nielsen" initials="K." surname="Nielsen">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>This document describes the Stream Control Transmission Protocol
(SCTP) and obsoletes RFC 4960. It incorporates the specification of the chunk f
lags registry from RFC 6096 and the specification of the I bit of DATA chunks fr
om RFC 7053. Therefore, RFCs 6096 and 7053 are also obsoleted by this document.
In addition, RFCs 4460 and 8540, which describe errata for SCTP, are obsoleted b
y this document. </t>
<t>SCTP was originally designed to transport Public Switched Telepho
ne Network (PSTN) signaling messages over IP networks. It is also suited to be u
sed for other applications, for example, WebRTC.</t>
<t>SCTP is a reliable transport protocol operating on top of a conne
ctionless packet network, such as IP. It offers the following services to its us
ers:</t>
<t>The design of SCTP includes appropriate congestion avoidance beha
vior and resistance to flooding and masquerade attacks.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9260"/>
<seriesInfo name="DOI" value="10.17487/RFC9260"/>
</reference>
<reference anchor="RFC9111">
<front>
<title>HTTP Caching</title>
<author fullname="R. Fielding" initials="R." role="editor" surname="Fi
elding">
<organization/>
</author>
<author fullname="M. Nottingham" initials="M." role="editor" surname="
Nottingham">
<organization/>
</author>
<author fullname="J. Reschke" initials="J." role="editor" surname="Res
chke">
<organization/>
</author>
<date month="June" year="2022"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless application
-level protocol for distributed, collaborative, hypertext information systems. T
his document defines HTTP caches and the associated header fields that control c
ache behavior or indicate cacheable response messages. </t>
<t>This document obsoletes RFC 7234.</t>
</abstract>
</front>
<seriesInfo name="STD" value="98"/>
<seriesInfo name="RFC" value="9111"/>
<seriesInfo name="DOI" value="10.17487/RFC9111"/>
</reference>
<reference anchor="RFC9221">
<front>
<title>An Unreliable Datagram Extension to QUIC</title>
<author fullname="T. Pauly" initials="T." surname="Pauly">
<organization/>
</author>
<author fullname="E. Kinnear" initials="E." surname="Kinnear">
<organization/>
</author>
<author fullname="D. Schinazi" initials="D." surname="Schinazi">
<organization/>
</author>
<date month="March" year="2022"/>
<abstract>
<t>This document defines an extension to the QUIC transport protocol
to add support for sending and receiving unreliable datagrams over a QUIC conne
ction.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9221"/>
<seriesInfo name="DOI" value="10.17487/RFC9221"/>
</reference>
<reference anchor="RFC9075">
<front>
<title>Report from the IAB COVID-19 Network Impacts Workshop 2020</tit
le>
<author fullname="J. Arkko" initials="J." surname="Arkko">
<organization/>
</author>
<author fullname="S. Farrell" initials="S." surname="Farrell">
<organization/>
</author>
<author fullname="M. Kühlewind" initials="M." surname="Kühlewind">
<organization/>
</author>
<author fullname="C. Perkins" initials="C." surname="Perkins">
<organization/>
</author>
<date month="July" year="2021"/>
<abstract>
<t>The Coronavirus disease (COVID-19) pandemic caused changes in Int
ernet user behavior, particularly during the introduction of initial quarantine
and work-from-home arrangements. These behavior changes drove changes in Interne
t traffic.</t>
<t>The Internet Architecture Board (IAB) held a workshop to discuss
network impacts of the pandemic on November 9-13, 2020. The workshop was held to
convene interested researchers, network operators, network management experts,
and Internet technologists to share their experiences. The meeting was held onli
ne given the ongoing travel and contact restrictions at that time.</t>
<t>Note that this document is a report on the proceedings of the wor
kshop. The views and positions documented in this report are those of the works
hop participants and do not necessarily reflect IAB views and positions.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9075"/>
<seriesInfo name="DOI" value="10.17487/RFC9075"/>
</reference>
</references>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+y9624b2ZIu+J9PkVDhTEl9SN0s+XYOeo4suaq8t+3StlRV
fUGjkCSTYpYpJjczKVnb7UG/w/waYObl+kkmvi8i1lqZJFWujYPBYDAb6C5Z
yly5LrHi+kXEYDDoNWUzK15mPy6KZd6U1TyfZefVvC7H9u86m1TL7KpZFvlt
Ob/J3hXjMu/lw+GyuHup/0r++uOi7o2r0Ty/lTHHy3zSDMqimQxuq0U9qP2x
QbUYyciDo+PeOG+Kl72R/P+bavnwMivnk6pXLpYvs2a5qpvjw8MXh8c9ffNl
9ub19Xe9XH6WCV9e9e6r5cebZbVayETw74/Fg/xqLM/Nm2I5L5rBBabQk/fz
+fjXfFbNZVoPRd1blC+zf22qUT+rq6UMPqnlp4db/UEWcJsvFjLRf+v18lUz
rZYve1k2kP/LZIL1y+xP+9kP1Wwmg/J3utw/5R+L1q+r5c3L7OxjfpuX2XUx
ms6rWXVTFvKFN/PRPh/BwormZXZ0epi9Wlb5+D5/4B9GZSO7cZ7fDpfl+Kbo
Z+/OssPjo5MT/Wu1mjfYrp/mZVOM5QBkA+usmmRnt8WyHOV8qpAPz15mv8m8
pjqtfdmT/3GDX++Pqtv2ms72s1fFTTFPVnQ2K5PfcTnviwa7Lt9UQmjN5nol
f3lIv53Pyv0hRvgfc39x/9ZeTL59tZ9d5Pcf5efk61eLYj4qlq2/cA7X+P28
8bVmb9+e//FdqXX0sQ6+DypNdqYHOlzeyg24E/KU985/fv/mJd9v8uUNjmza
NIv65cHB/f29vF0Uzw+P92V6B08O8vGv02p0MLzPjw8Wq+GsHB2M8tmsPjh6
8evh0+OTg3l1X8xmv8oDvx4e/Xr0Ar/cX4wnOr5eyJ3zsh5VmXw2+65aFqO8
brLVAtdlh4/x4mR/Ws2L7Piknx0fHr3APC/PzzdPE1P8tJjJUJwtpyqEvrqV
nTx4fvrs6Pj589b3X8ue3fDGX77+Hns5H+fLsbKDy6qU/T+fVauxcIvbxbKo
a+EVOrN4Y/C/QTjhq9H0Pl/+rf37ohEa2U9WhIUMDp/o7ZBTK2ocBa7+69fZ
n6rVEhyqmmdhejKv7KqYFSMc+XW1KEe1DJ2dl8vRqmxq/ftD3RS3NTYIq9ly
ko9u0Ysnz06enrS3iDvz5lZmUgudZD8L06xkP8aYlm/Y+p4MAg95J1euehgV
vc0bki7/clmNigIjk6CbacEd4YreyfKOjjavaTzbz0e3tpTy4Ohw/+jo5FQo
8eTJ6enxPv/77KS1qrN5Jtsg38a6ZbOLu3y2oizAl0UqFIN8nC8a/VU+E8Zd
NtNb7jr/gL0IvD6r7uQO/3B9ffk4dZx9nNbTfFi2/yBM6TzlS+EP8tuL6m5Z
zcq6TTxHA5EX3d07O3+n22T7dXl8+PeQwPHzZ0dHz9q3xDZHFoozkW0j3xDW
Qr6zWMyKb+tsVt0PZjLD+egh++Ht1SM78WdZ12qZf/zdW3J8ODh8sfmWYIFY
6Nu3g4uzqx+2EEZeT8uJL7A+OP8weCuzfKuzHLyVQxwsn69xpbfJSt5V40L5
AT7zyKLw58Gb79bm/4Sc9d3Zd4Pz69fbuWtOEQq+fLCqD4r5we1q1pQUI+Fw
6oP7qTD9wSKXIzhI9jvROkSqTwZ8jE+tre2nWbPM011IFJufavz/8+lqLiJs
8Ho+krWPyVvsd9n1Mp/Xk2K5lJ+xpo37Yf91EfdLOZtlb/P78Gtu1y/7rd9R
5u1s1SN22vT/fHB0iG09e/XharW8Kx6+ntDzoexVPmoSuXByfPL86EmbPWQ6
Lpjwq7IBP8jOIj8QLl/cFhu1xuzHr2AFr/az6zyf/wE+cF2CAxfL9h8+7Gf/
wj/IZZx3t9/Um+G4mE3zjzIuGF0xTO9ZlqpF63+OwmrzHRSpeLuai86hOrRu
WZ39L6IjNcIv8xlZEekIPH3LHS3uilkFUs3BSHgD/Gw48AGe/HUmd/XXQOYH
01n9q26t/OtX0XNG5cQm8qucyq8c61cZuxwVdetohTVlZ/4m9K/4Js+T7Cy7
0DcfOUM+l2i56Z1/yjt/fTY4Pnz6dPOy62m12B81+X4jxH6wWFbj1UgueLzI
f12JXtk8DKrJQCUVVLmBbJbwgYE8L79q5DgGcj0Ht0Ujql9rnZEs/6IDgVW/
DgNlrzlQHzLXRuJFf5eM1F027yjsJjmbZbykD9lZXVejklu4hf3JVpweHp78
oa24L4YDHKMdzuAOmsegGFU1FZ2BEMqt/JoscjCaybKagXxZfpb/w9fS7Tjn
w3ZFz/mw6NxNnu2evzu/2Nt+zDL1DSIJZP327Or6zd+jiD59+kJsnOO2iLXR
srPMlgLrVLR9UfbFrJH9Bm2OH+RSl6NHNZBsF5Jo7xHKfSvitxDdcTSq2n/4
WRhQPhOFTozItb9c5rPbss7nnb+IVvMuFyXe3ggs4wkM3y7XuMxHH4W/qA75
i1hKOHps5o8fCpESD4MfLl+937yj08VwLrzhYLgqZ+Amg+GsGn2scT2a0eKg
fcXLm2l2mWgpYnXeyzzcsMN+7Z5PZQ/ld8fCjm3M7BXHxE25Pr/cawudY1G6
TjHXP+WjalgL5f1ZjPTZFq4mZz4bzvZvqrsDyuH6QI7yJr+rynFXJMuNuilq
8p8z/J0zptDVw99+kHIqPpn2H0Tn1sklKzh68VzE5hGv44+XZ0fPt+gixXD/
tmz2i/FKprzI2zt7Lr+Bni4CVK7lTOholj8MXuV1MU7XYTMnzVKLN1fFI0Qp
azlbrjrryH4QwZTP8o/Lsp7O8zZ3ES3A7nhKYj9dvX7/5p+y91cXb2gqVsvm
5OTJI1ZtPs9VMRDr7mauapYMCPY/gAgVZitjDOar2yGOcfuf9ptPTWuzrvTR
7L08ygOl9oRXwHWbSi4N55e95wDZh+KmlAv9sE53J3pqcrEv//no2R8ygp4c
Hr94fvh0n/89PmpN8M1YVltOHkD6YB1XA8xLjUy5KpNZ+UnvKs2eD0U+G4ge
UjwmFPflsWK8To2y8tG0fXzPNlnAMGJsoW7IPqLf8wDriouuzRY9ePbiyfGL
/WlzO2sv9urHgzevz7PjJ4eHLwZHL6HWZBdfz1BlNZe5HNaROwThEHAdJRMj
YbQsF2otylHXxQ1IKVMHS93RX1+AOabLG1ydvb/4A2t8+uLw2e+u8RRrfPb3
rPFU+LoQr/wRazGvVoYbUoM28Gy2iyl3eCTONC4MBsIfOrcjodNH13Q4OHrx
EjI4exesoyzREWy7s11+/yye2YugAWx/B9PdI8uyw5OV8unOfXSlht+4vnrZ
Fj37x8fH+4cZ3LPmXJNPNFFXGmTfF3M46jLViiFsbqs7/LQoR81qaYpYbjoV
DLDVuKyyMo730n09O9t3t1ntl6JrLIvRwfXgw+vzgc1sjYU+HxxTn7n67sPZ
uy0GKtQqWE0fRUuHE9H1mYPRVLa3WKr/u54shdMddHjgSJZkN+Y7/L2m4Md6
v4dXO9v9oRL2eJnfFEJMmMeH65ebhvhQzMp8KKp55KK78uxe5KWwvO7K4v5R
o1Stonf5p/I2u5LZ58P84aPrNIFfdf7yVftxWxRwkRyUEHbl7YCkwpjA4dGB
HFxBi+ignglHrQebnhrURV3novQuy9ng6DT5mz+dzwfqHx2I/hFtBVWN85ns
0Nw8bSm5nshgpNhytKzam8tf3efCFWT3xLAVEShinfJazHxaCu/KprxROv5O
Lscv5eC7sm36tcnxcW/AtZi9t9ji63wazdnOQ+/yRtSGe7oPy3olO73lwT9V
dbGYQqN9W4lCWyyrLQ9eIOgzhsH802hUromdnePDw+fZaTN1w9aMnI6Fi4uZ
6JDymG+Sv9rPFov97OmzwdPnbbZx+Bwn8Or1D2c/b7tkbQGeD+voyTw9fvrs
8MU+/3ty2uY41X12uxpNs1E+z4bFNL8rK1HgbXhMc1rMFlk1n5VzUUPGd7D2
4Oj5X7/muP60mmf/nK/5Fuyv7zH823K15c/f5/LnX+T/bfMMCcX9y3T73/9Z
Pv6ncvvf/2Va0F9l/pLWgf7yyy/Zt4cvNjqVj57LafFKzT0cOIpHKfQsHEqI
5R4WmOjDZ7iPOMIXZFN1dvz06D//438/fnbYOeIXuGrHh/Ggj//4Sb84OTp5
/myf/33R9sT/uHaE/Y0H3iedyqTv8tHD1xzy2V2ZfV/NxpN8OdzyyHkuG7fE
51/L1V2B863veee22G6LSvdzNZPrlJ2evKnrlfz3Xf5AN7Zcluz4lHvZUSRg
bAlHpJPvQiTTT1u0I9k/7qPs35MnLw4Pfhstjg5PDg+fvGht3dlYL69IoNUY
RrYGdIRyGNRwZ99EH4C2a5t9Fjf7a3ZS5Ma4zK7ycXEzXVSrbfztvciPWflb
nv08y38rR+s7GWJAk+z8AcYFZCCcOFjEpZ5sdtTP5tV+dvIyey509/zJ8f6a
5XB0PDiiM+rV2duz9+dv3n+/ZRvLm1KmpC6Ven+W3+/Xo5UagdNm9tvBXTU7
fnZQ1vXRwXFbwsM+m4+MHSrX9Anel3LPXkUKvXYK/ZqtvFiJLTnPLuCalNc2
kNvxM9lpUcCz85lI64xWf+KVepvfeyytnwkF7mfyghLgkdiaYsCKMnHcoTte
3jdnrwZnF1ePGY1D+inTjZCXdKMvt783LBphOvm4Js2mb1/LRTmv4KhzP+Qr
PisESCfqeSWmdlt0m5E9Ux9fsSrUGn887vK+HE0r8wts9SN42HXGW7ruxtl+
0bnRvOqnfdvrZyoST44Hp4eq4PGyPXl6WP0dvrMXR0+eHB1ud9afuZEj45uf
KXhC5XrK5DjlvkgNUZcKeCx4p35cQKOUNcET+riB+8/5X6tq2P719f6rjjP/
+/1sIFrOu5WImZbj4gk3tk/VbG1nxdz5Osc6d1JMo1fvvvsjNtZz2bzj7TbW
0cnJi6fCNGBjHW+3YM6D5ULTRNTPegVmNfytGDV1MLqOX2KG2TCvCzO7JqVc
OR00vXdCffNVvgS1HdN8fDO4oF49+OuqHA1u87mI3XxYwo390v48kuUAYDAo
R6PlzWA4XA5GwQE1ML+pP6wgnYUwi6oeTGf1YDkZPT8+ejos65fp55rR4hZ/
e/biCf8kf/vw3blIdgae8eOzJ0/txydHT07Dj0+f+4+np4f+47NT/+3JsydP
7MfTk+c+2OnpixP/8Wn87bOnx/bj06MXPtjT0+fht8/VBcQfT3zcZ8fha89E
dfAfT498hGdPT5+GH5/6154fPn8SfzyJP56GH1+EH2XH/McnRz6d5yeH4bWT
k/DA0+PwwLPj8InnxyfxxzDu8yfxt2FTn7948cJ+fCGWf/zxKP54HH586q+9
OAqLf3H89DD+Nrx2fBxHeCav9QaDQeZhwV7velrWmfMb0aIqGFdgEvSWwL4E
4VcJlGweLQKwkibYpwu3TEtwwlqYZN4get7kItiaikzzrzE6E8M82b1oJomf
hvYdB6+ghmVTEXWDocUl9WrRlZP6Wve7Sylr6rxzxHTl4+CxnIe8AzNeFi9f
l+szIkOPH9fxxwUicHJHuYgpLEYxzETJhOvXPUSyUWJAirqSwfEb9oELE8Zw
P62ymVjNmcfrbGz9u4zUz4QPjoq1j2O9M/k/GeOj8PlxOTFlvRYFuLkvZLNU
dYHbZHW7ULZZAuOBFck4yRkt1HttjF+knpxqFGSd1drJybeAuyoQ9+6cTWv7
xRxd+2a9ryR2W47Hs6LX+wZHpEEucNbP35T455f/l1De7l+q13v/P/39f4z+
vvkm+7NM/KKYlPNSv/X5G1nKYFxM1ihvjKfkozutY97yxSS4I4sX4T6bVfcQ
nQONw/n7Ozj/nAHN4lMzqGF5UVGTl2+zIWChom6mBDISTQ6OvyUBjjx2dXHI
wdcgZHmMk6jhQByuGrGGgF2YuT6qGhF1FJzVt3WgE5nFvOD1q/fFGKzn+aKe
ysvyIqBO8jk9TpkRb4mGSGR5rR2BWlSN8wcZ2PcAi7wp4UkbPnAOeKFYDjiq
nGIDVQ+E8fnz8G755cs+tikoqDuytUKzeiVko8r5qlrVSsi3JdGHkUTMSS1b
vqxuM/ybDnvZuNxCyKQvoAPrEmCifF5gtBGtNI1U2CT1ccIYBrREeCY76Ws8
vpGYoAj79bEVrVm05yiP4ihGBrGWc9qp4xpL4WFiWY+r+/lMTh1UkWiHdF2I
GSO7JAuYNEZk/jSnIbb7rGiK8b7sey3q9bgvz8gf7qvVbAwCARIVXw1v+ag7
YZHy+FRWIfSQlbchGCDk8F25rJs+PypESkWXpw2brLPzt0KHmeiyo2myjd+2
t5jv7sqdJeOcVXJDharAnsBPZg97ODHj9Zno/CCk5WoBvz8mPBR2tS/TzUFa
/eQz+nFs83IlVLFqNlDG7nAFRiXDjjHofE89Q+HNfDQqFjKSmFrdV+W6zXEC
vHE6yrCY4EGfVRgddxCD29ZeFbL8cb+9I21iWdsfOYxZeUs8M+bFi2e0ucib
qQyQ3+XljO7/oSzhvhw3U155MYUqPNr+gD1Ng2GfFG2bJsvBByYFzmx9yU2g
RbtN9ryfz+5D0ezxzjKgsZMtiwmkDS7dXOb7sCjiMXSiOHoD5DLCVyuUR5na
VwuqL680OaIK/Uymxi/8uM5fnTtwnnBJyXaoOgBsSFXotaNsNAPIWSHivEvd
zCCx0oWqLNLf6FYhV6BSKsl27vU+3YjNVcx31iT7qiaDLmrlHKDTyiKichl5
kzrCI6B4RFCsAehsRS97Ym7POfXGxH7Qibrj2Sp6PcvV4D85QOCLj75Prqk/
gr6LJV4FafGAVR7l4FSbP9zHha7BRx4CJ+71eHB8bPmwYTGyg2Kp4kj64Uw2
7VU4Yap48gBDn1HzGpnbrW8P6NAKi8rv82Uhn/5lumXwkrrF8gEMBwOoW9wm
rZxC6Uk2AZOX+2YECDnPIVtv8OA5Hv9mHxEGJZRD4TQsOlM763zTZDxEBK4S
7hXVNRHDf8M1Wg1xzWwWiLkp7x8H1caJ4JIHGTZ+vCCen68ti7+KkG/W6cBk
aUoJZPwypy273iKUxyhFr1WbUvR3vd5PPrbh02xsJeDp6hafJza3Q6TQ6y78
Fl6NhFJ6vbNsshIdaFm4wQCNaG0y69lPeEx3NnAwalet37sCBaqtQTxNVany
luESLUSlhubGF0epi526XeRazjrWWMlEfgA3GU3LYjKjSw90NIMqN6hFrhdR
N25ZCRtMEhgZciNkvKXowG94LcRguM2XZapqKkgJmvMo8ag6wUBbu6tmdwWj
AvZtPLDGQpb5REyKfV3QiFdpNFuJ1KiW5Y2865yW2TL1FG9SGwZRJDcACuKs
/Fj4H+N6XZ/Pds8v3td7HuYhS1vqIZqYM9xrwtSVYGAKvKvqxsVChwx4brrQ
pnUqgEuIRBbjD5u6g/kYNCLbFc6gKIW5yzj8g2Yrwapq92GeN8ig2eODO0Zg
2FGh7rGMswDFiqYpH1qKeFiOHX4RWFoYnbe0FpYI0IBIzE9UY0THEhEnEksU
w/8Zy2x/3O77GMpG+xb2ufO4bThS/plXtp9s/5ZRciHzOaxO0wl8YNuAZXiv
+FSMVo3a+UC9x4yULctv3yqQUo70MlEsRCJOYRSniKXWTVJjv2uS02apx1++
ULjXRWPiRI4gwPzkfMOe+7f7PUO85LPsZmXoRpgeQY0jBcNuICxTDKN7/ObL
F6UUz8PonKE857kP+AueJnJni9egz4V3lhwAUYUh1FVl899GjwN83yUkBnbB
DH3hKp0vukI3q+QfDH3l3S+ar8MDD65CzPX+5qNCeQwgeJ5s4ywtUYATXSEd
ISE3oZ+ivHOVYAQA8agJ1mNei1mtOi/JUC7BUhhJvhTNBEvC0sCs5/nsgWcv
m10Xo0E+FIt1b+NWBp/Duguqxnjj1HwKO+YKzTYnh8o85c1huN/f4b/89OZ8
ky/s82fzJX/5ojYPtmkuNlicYZd+bOUcbNvaU/Ox65wJulUyHv84sL8ofB1D
Yzd6MJ/ueFcofJytT1ZLmo/ypkZejHMt80UJt8kIIAoKpRVjMPiOvSNDgx1o
yqCYiYSV8+Ua+oILKcQ6ELkajIWXTOU8Mf+YDwfoJ/B2sJcH97lKT/qxXBL0
24ZNwFPIrP6bnJgc4upm2uG3TSWvUNzRFFaHCie6LGYUKnRVYq4LuRz9oG6q
VJE/zoqGm4KN+jinQpo3Sms44LAesvz8Rod4AAeEp0Cs8Y8YRZ2aIcvKvYD0
IcW7T2+KUio+kO7A+v4Y+6GjEIbUeJkjkgbHxIPKLyVruWepbiNaL1/frONw
0H0cVHBgQlLcyqzH7kGctxzE0dcIgaZArnDf3EJbl4TJidG5hq2d+/uKhKLL
YI5/6PsLoEOBPaHRTi3roX1WbkTnSttKVw66USqnv6+2IC1eWFQ1LY7EnJzK
Kc9Fs22SJDFh2mMoF1CuibGPDEkGEaZ5W3PbblQQ0ZAIqmySJxBP+7/JTYY7
qiN2nMZhqoN3gGzoc+4rwymbji9aOXDHgJYjEmIp/+b6iFo8o+UKVg71ZtlV
sGcIqTjBZqP1WdrFEGLCoSROt1KkwgKigVeN90oBCL5dqod0qJ8bpdxTxsOr
q/m8mIUdsX9y1jQNoeneyv2E32Zthne0MUluVGqpJgiXHwtPLRcZ74yLgVuA
Mle3bV8iQvLZ7rvrn/awGwsmkODjS1GUzf9rM+oHPWSxWgrhFAZMSOjaN8pm
1NkvOVcIQRcj0HE6Jk8W866EqapFIX/EH0DSZM0rxhtEIpRgacNilEOe0t7U
mzPEIzu/FMOIqO/AKXfljx+uz/d26KIc4QauFjIXuUx95XAfri/7mT71LY0a
YbQLoZ1ginRl3y6FHyKt0OD8H6cUPOouSO5ya89QBeK+oDKxm9eqYEZtcA9O
QjxdwvgRGxl3FR5wv2tR6aNqMV86jHfbVE1fYABguXzYwmeNFcIAfl81xpKJ
iCmHwEgou/5AI5iOITyFQWXh2etxCf9SdjkrgE0QZai6c6FoilJwna+G9qu6
5w5QVjvgSbmi7W+1GV3gbsp9UTlDNks+WaorxEx0obWeJUHeutd+XNZiB6vD
XzU9QhggSSb5kuv+Jvu5mK+6K/e5X8QBPn9zhwfXwjxql2Hs78vmh9VQ5iO3
BjsjSmEjCsF/dyjJjahaK0U8ESZxf0NU8sHv1T75x17vgwlnXLX7YkZahsQV
vhRuIdMlYMqq38JcM3qZU0Ls9a7kNJqcbqjWFnWuucv3BlsuRppaHFgpKqhk
HohjVZUM5TDwL7HJhdFgHf/DId3QnAbZn+Rqv8z+ewtXEzDf8rJw5oMZpc2k
OsD7/0g1Ll+OpslreBK/EjKOr+MXB0Mmp/HNg39EePjH1TL7Dn4QzDp6RxXN
9PkbuXa93lnd8g2TUch67ufmxINVTl/Lg+oXsiU4Ao+Mqa/C1QwLyLqvhIMN
C54VlTn4NOTKwaJWlTmxRsDWbnO9gSv3Pz47/S/hUxXKK/gHW5+5d2URdMh0
HDCYllaijOrkkFyLwtdHqg0TpZFg6ms2ZRFGldAFJkdf1ByR9my84j9XQxHv
QuOr4PcUApJzPjPPIJiLBX98w3SK/t1pjgiTUC92G8cCOn2Q01ZCxprk/v+m
SVT6fcTxivD87tkCQrn8lF1g9H9F0ZV/A6Wdkdk4eUdJVOrJArJc+zJUEeYh
F9zODSZ8wrjbS5B9jYx01Iaa7WI50P6Z3Gyg8TWNfo8kwtgLiS6DqsM0aphT
+71fqCnQkbIJRLA2np5inFRQf1MPADhDaYarC/L0d9kdVE7q1nAepyk+jM9Q
z9nvIYdB9J/SNOQ2G9n8rboosq6/AfJ/ru5pi2nX/bYn0PU6sc3GUP4SnQrO
37p3Y4lAaZLzDIIg+BKzeIS5Xvg7hVdWk17nW0ZmFDU4k74JZl4KbHHKE3q4
I0uQmpEoVSCNFInFMmpazl7VZOHXp5um7kHGrM050aP7apyvO5l7pNugLLZ9
NHDa4YYb45goB+yydkZN1jwJIZFtX9PZoJfJp1PTvvuKaWa93j/IvSP6k491
Xo+Mju5rpgTIOd4UCRQHdrcmwPRlMB+At4Nfj2/ewb2rkBvVupNtjC8r+y3o
G5Xf0/8zbllQjNtyVq1aLB4xpHR10RDnpJY+/KhMIJoM5NkB2IzDQzXA4lDz
2wJuhbJGPA++CRtmlKvzK5/B8AaCZDGrHuTFEb2ZILTJMpdZr0ZqzpnJ9Lg7
W9TQWTWixVp9YtkPXP2h5W1jaKrcP8sGgndzJvCmk7LIPbhjndMOpMUXDo72
D/v+0xE/wH8cqyGQmhTX55dy47fgQiGLmM57fvltnWiwnotBPt2WYq71DvwZ
YSD68Sd0C6ffhvtKP4CfvvYLRMomo/d6P3V17bDz6lcTGyKBdP10cTkYUppE
Rdyp2Hikf2qFEjKz6l4tiajSJ5/X+X/+PK0Wg+HDAP8xcYu/IXD/h8wGM28X
LZwGfTAgXTIc+N3UOhRCgidgJGRsiAlqLvK2GG9LBOPhqBYTG7Bk+logj11D
9Bg+at+MZMOxU6Aq6NzZq+C0vkyd1p+/MZ817ZErIWPubyqbsAoN7l34KYgm
p09+MXWe8tGqzQCfBYSQkDx/HVBYhbtyddrKDSGFwFtwCrVddHcgy1rdobI7
LeBpU0UFy5Bbx5xNojD6cBQDSACPWV83oB994yK55Em4JEUgihJYGA7nk6el
5Lfw3mo+K40j9/vPGMHNP2pqUt2Z1SNT+KrPBD2ob0gHm6/vmP8ZSC8gwO4Z
mpS11SqlzCUyihXeENScqcmCk98yLsLcNu5VeQvlHqj+PGPdpgHcYfGdm7AR
Wt2kCJ6YAMJcNYtVw1nkpo9rqLQzUm5xF+xYwKEt/WrX8Y8+MLEiclkB4NHn
hZJ/QKgI68uziVigFtKIZ5L47C0a5IFKbpncEVZ/oCCkjB461boLBrgqXrtF
JWZdHsfhxn/+HIoCkVX9u9ZI+PfsF16uT9kPSqj/nv2wf/z0xP57Ks8N8L//
Ouj8b+0Xnf/Jixc/X8gw2bPjQxn+5Pmh/EPEQfZuuKjlx8P9U/4oD8oTi2z3
6M97eOL4OR7HS/+ePRmc2FPyj+PBib9wdPgcbxzrGy/4AfxO/vV08NxfkHcH
z/yV46OneOXkI155IvaNvILfyb/eH5xhmMPBsU4OFqj6LqZ69oxTcxfHis+h
lYs9F60KaRg7G7BSOyFq1NXHU/xP928eRiJwt4LawatHXhvvg3m4NNAKptlG
IoE3yWiiAWEBbQBBWl2A/jVYa4ZPvUfZMHUBhftXjN2KaNQxrZ5kc2Oo/3g/
e2OhVhI1o+K6X/A70B8vauAtYA1auEMd0XW1Wo5UQ8up9KvvXqMtil5gOC5I
gEJ0En/coKb1fuuwupuYy40H6g2MOfy+u7DREtIrb28Lb50IuxWkZdk2wBXT
FaZ1y4tjXhQ1GZJzTrVI/b1/HvvUYhNQwRo7VQ3r6p/1NWMv5OcdTYQB1IFx
JIW4vkkAQP558kmU2nJKqhN+4+fhkEfSFdFIxkDj60ELNLuhPUBYH87DlMdk
gVsmry+RNalkXvJmwV8Lnuoyuke/SOB9CvyN4N4Ys7AjMARgCkVTQBd0XItn
KtcXoVh+gi7mkRJ6CgdC9P34xpTu2GxnXNwsC+XDE/lhXN32dyJYDE/W+HOC
jDavyy2C9w4xCBQli35NBLMYiyN5VNe+tLXvPnl6ONAv7uk4LUCYenYQmUNs
Laern7OSK7TbwUjtNFP5Q7Y+/R2ItCcX1Xd7boinrhF3aUVKVY7EyJ5q8gSO
KyQlnL8Fb2zKPm4go0lZzMZ12GqPAUAD2c/+Wcwod70I61gmVoyoRNNqnMI6
i3tWBVJlmkBfqMb8V2CwPMVloUhpuesm8Qs7tPtpNbOPu7cHG9vCO9vR4t1a
WRRDH/JpqDCjaqlK7tjYDZzZOjdQFM5L+LJSLF0uu58/x8RMDRrDv8Eoaij+
2jJXDXHiwF3OBo50mum7Ww83W8wAJ7cT/q97GSN/QpvdAery0zbaeEraoHkC
pmT7YWc6DooR/CA1UUgeQccOqkNhRI0xLs3NU7jwVb0hEKlFsOp8QYE8iz9k
P8oBIV5Lfm4FgRI/TXzUQgMQlHoCI9QVDpuYYCICsFcj+bBQ4LaZBaeUPBI0
v0n2xHSYamm5BqjANFFW+/kzCwELJ1Jr7PL8XH4O0fFx0ciVt/SQS4iRV1XT
zIToUATNKpDB/UAYnJgrhViYKDc4ir/+YszCb2AiiZZd+yf1wNSG4shVfll4
YKZQ9VoUcKBRo5eOWJS6pEkajhn7qY87s0sm1sYYJdzfUH36eUeY/y4o2vFz
ZsT5IuAMCbAVODzj9jVqlrU+p6vlodPo5oaFl4ShwzVcq84+rwgd1H9wjgHd
3pq6w36hGKYTuCVKg9BFWABA7COAimoYjNTLzO7hWFQUP9GIuRjQFOpilTJJ
CjeL6FePEhefpjny8qF4uIjdd8Ct7xq+LNszolEfzyA9HEP2IPkiCVJP5INM
LRDhsUAO0T9k7ZEZAjXrXS/lmhsyjGEgi6J1gCbthCuOKDjydPuhUep17BKH
yJXxb6s6gLKi4rgphyAFZlHpoiqrzL1anxLdg5ET0xre1wyVrpvnhljLpd1c
i8I6Mmt/fb/ovUnZmYFsNgRd1WNrFDAQheGjAVS9pl8sRRk1mKG6Z7Yqo4qn
w861NkXJuJVdY9IynVv0P/7B3TC01r6qZ0It8C+V8XBqNU93F1VTuEYBw5ul
KfayHdTLEYm0k8xAtf2E8KIRHumHWziHkSvKrqOnErTebV3IZdTECs6Fg8rE
VnOC4Qn30FgzjbqQn8W75/fcwMW+rHn2l+q1w/b8aBCSTiMyprozqYdm2Ijx
0eg3hetWrg+8XBBpakTcV4QV3k8fNrDFTTSENXBNyYLu/UYoA6ErP9SoUSUo
T/Uw+FQcko61qIzV34ZD7EyHXwJnABSvsNJtCFAl6koCoS3nphUrqAy3wkB1
uXtqBgYhWXPxGxGFKwUdHKrVpu1IZ2Pm49pwH+Gjn/WBDsBvQ4xlCyeZIxhE
OJYBSVRNQ7wrBO3KSTeLiXjnEKelq2BDOtUG3tQHS7GAcRdRoq5TQFXV4Wrq
ccIxcMIip2GtEUph9/1e2K9YCnX5N4YvFA6UAQ7Ut6+1Jk+LrP67mH2cgB4S
I5UJ1+lvX11N32qHu9uJzIv7vt0oheYSYzuflMvbcG5lvfaY/GqnzifFTnCZ
zKv4aVsRt7I09/VSSzytGpln6mZpp6ilkT8Kmc3T7G9ZKrLzDHjV4sg0Te6D
em+sKHpfy7Q6SHdSf0U9GrvECZoLrG/7nsdku9+TKzIZnyvVI9V8dd4yPREG
cUbuf0mSflrS2rIYiznhjgD2RSdmmCP8FhppM3xjNZSPE1hrgEOTK54oU5fN
KtpJpZVnSyVOzkCrpteYMccM9Xo9SStOeJmD4xVtvSVVDvsJT60DlNjgECmA
k2tPAqiWZFZ7fC9BD9C3hqxYeb5YyF4Ibx+HwVStVZQliAbMSfUk1VzjXwJN
m1vlQzGqREj9rWQRN/UlWwIWKgoTeqBWB8YcPIi2ObB4N8FMQXZAP3W5AWml
rsROAoPKNCKlGcydg3pnES2r8EHjotQ930yiCthUC61+owNY/CnwXOFh3An7
a3rmqtRv/qJqyi7IPZavQadWTDAn5LU9E+M0Ku4BF1G6wrSY7TlDoYL6N1qb
gT96lo2ZDoWl1sHBOXGu0flOiBszJc9sx5Tm3AGEo8DfpkV+V1LpyMe0IHjB
TAUhHCjc5L4fCIUjyXWmpui7658oItKEOc0rU9u11MhfKxuCkwqJW/t2hupR
DQgk9VXVVbhMjvpcph4y6nZr+6ABHw242D/W91BZf+ezYP5Cz7McxGjuueAn
T/RKM03coelOcROpXNIvOFuAnWGl1dkuC3L2s9Pv+9nb69eaQLxH0gJuhSkC
TpdWVoE6vtKE/wGYoFzLzCalPxkU0JKgYBXzm4Y+rpgbB3eNcsGlXeYiXHxO
Hf77TdlygXSgQMXyI0gj1CnhcpTMWlIOM3SOYIUgFloqF2J9sURIPEJzsdkT
0Sly7e2z3zsLmSw6t9L0MWaCctpq4Sheh/QFbzj2uK4WUzKQkONm/BEuqwe7
y4QXOrf14iCKJcuI6wc2Gbt9K4ZgWTNBnmcxFZam5JQ/gF5/4rjpUgAcreYA
ZWokw44rSS9E5sY/dDHVNX5HXULrD9ATaqjkVEUT6ovdL3Zfn7/fM6QwSlp9
+aJuHdWX9zCksDkAR9SZb+F2fAF/s38St/HQFCHA4X9PAVmq7NxU1Xgh2g1e
jksO4JikSkckpGCo+dXqa0smdRW5Ervx1WZD/rPTIeZQfGJFUAvTwlE8bmVL
tSSEnWioKMK2YXRysYGGJ11Fzamr+kevWwso8PkbXBzRVb60ogttb5qauoYe
+ELOu6AOY25YhUvPHnqab5hmDk/o1Kkrt0hk9nVj3tAm+Z7mZdY9vxRqn5Vx
PdEH0iovEgIAk9KccoHZ99Y8ggkmJca5cC97cXQdEJU89Ow6kjf6yvjy0WH/
8PCwFx+399M5zh6yuC+t0Ey/R5TIJ1pK8tjzw+x7OFdVdxhCOsJ7RpxhS17c
9oBfKYJlGNzJMj2ND8fgOuLvrlq521RDAQxpQsbN8kUIatK/bypBzB7tBRit
A/3wMq9+lsJfzf5qn0Mr43LtUFQLULKWsza9l4TLXCA51x5DpvE6Y+ttvvbm
fpaFPOhhEfwLzAdRz3bP8WJ26O3Ebh8dCpCVFaTwh3yUI1vls156x2VpBzJ1
TJdcyKypdI7qciQdo8+gSi1Glj81RSwMEF+A+DXwgp+mrca2RC5Sb4u7m9W2
LHqMSYPfuivYBtGTgdDv5WyepgnAMvYAZ56OR5xTkY9DPtCAtzx5Qn3457aj
Vo5beIntsfASVoDQS20x8RDvYLKd5uiLeij6B6GF6qFJlBuj1bzZ8i5ghWDH
fq5h02awaUiLNMDcgyTfGkBFVGWXiYB8SHUh4Nk+zh5UJyoJiQ4GXOmeYJXD
HdByAPgFQOImUDkqAiLMFVyLnjoZ4m0rvcbdOgk+6qAtDaZehpsWJEPVLEQk
6xqH9I88dcslZcT8o2GHuEFTK7AxFDNvUtLo9o9v2b8ha/HCr32DdO8Yvtfo
OCrWqzKWz5KI19xfV3/JRI5gGiw4e6qT7gS9wZ/wqluswGAUllAIqwXshHHM
nSf3E1tg28eBieCzCxfFdOfqMeF8HGmqvaMpoMNpjVH+xBDjd9SeKhZlzSgL
r5V/GtuulE10vVGIzwN69dAKUijR867UFfsfEirB01bdFZsbXJvMRIEOuoSr
AVlgaQrHfmSYxrRNBJPOsLmQ74OmGoD1R74D9omxAL3UUO+K9VaD65p5dynf
O99KRHO1jOz7ojBWUH7U+6HczIKXQYP0XFkqywGMDtPHPI3tF4tPweCwbHij
vKVtj+aSFnR1WvW6cEMTXtQsV0WMOXbZs61JBhuvlAdPJgMgEFXhVs5WhlQY
djTky7yklk2BLpDCaV9PJmzYIz/+UC1CNets9+3r7PKHV1p24MJ1fi31ZI1/
6h3LX3l6fAzYK0bMXn+SL2ql5uyV3McbdX8mTS3evr54dXa9Zy+j2iteVisY
MMM0MNLrnbkOQi5HSGhf8auyUqZwqN9Oi2EpqW+tMKT4HIoA2QagQ0KJEQIj
U7tdiaifQIgTmmP5jML9kIUCK7QQCyLwVCRGtKUtw96+ynzEZuqB3iBb1L9S
GHR47gaCGuCq/5hbwPHENu5qHkeW3frFdY0CnXUL62BKQPMg7V+aADUcK2ww
czhZGwXN+yYa8w7at+bJyvWQo1HFzXygTUhpN8LX3bO8Wv9l9As8yA5aVnuh
/nLzTqhKJDrWFTVG81O5smLX23ISsvuCsX5Wxhw7JEe/NKmqBsmjarUhtWlc
FAui3W6WWmExLWipqavRwRcn5TpacATpulGjxcwNLi843yylpGvUIOw6KMhT
yxqC09dA3/dY6aZYLqul15SxKqqyFW/mo3KsWdP0M2oRCcIlWgnFfN2166hD
RhfZamGWgyHI0gOzwFniswt/mVbaQw6fW81VdQ0Rew+YgQaokjRdqvm2tqo9
XYiKIQ/km4jGte1YU4OmLL8UCvMBKfO31BFu4RDkpgGi0nC3kkvooQGftkFP
8DzBM67F4HCBdtGMzSX0+RkjsKGGgk82rwnn6PPgXIwjSjGm8jGrW0BmuWBh
M81KNevKx8N/w9JtU2Pyoh0d/UI4CpiDhmqJ+mz2Exna5bJCnUnHszh3EJus
BLXSeKMKBz3ACFpNSLO+lNEYjCxCL/wXyxbkMEJ1LETBECyRaryWpTsuRTBn
b27BaeNtCMhHmwb7uCQGXReSvh3QnvSvJhNjkcXJxKv4uGfTP5qYCfinTd0R
5Wox73rMJQHy269SPH+YDGD9N/ntqgm/82aWS3X30W1J4qcvewRe1pfNHoI5
8kRUIkFdFdIiq0MiVF3HTCI4E3FucyJekPb6mzCvmBileZoWqYz5k2k9ShSz
gUYG7S3cXXkArmKvqmFJsSCwn+aL3yOxKIJch6aSFax0jd3jxYW/2FTOK9th
fF681VjY3EzrWtZFcAkG93srp0YuDjHQKjm1wKXYU7er235w2QZNXodujahK
s1lRXv8VtvN95cq7PghzAylf5V1h4Z1L0eKgrlKbO0tD8Z+/WRwvvjByHWNL
wZJq2Wo7HwpNzXPu/Ob19XehdSi0G/8M/pvtXh5f7qFxQZKB1s/YbuZ5n12Y
dszBieL71DaCFvmqbK6BmkS4BKcwzcltU7flCIRNLDzS+eoFMuC8XJIMftr3
LcRBrebwa9MF6Pm7qtqGTXF9eeapwrcsie01fd9cXWYjMSSrW7LUoVsMnf7r
Y/bgTAoq26i7P1dvNMPrhnrKnlNM+r7l4KtAc1YqpADbpyFMhqLXwFgItHXv
HK3gkNNNMU1UnoIqWlVagnZQzqdFyIN9uFWfaT+b5HfalTlx30VDZ7fYv9nv
Z2cXV2/7kQU0rV7hTDlhC43nh8f7R0cBz4/6SrW5/BRCgict6ApFjRhcvT+b
Pk6+HTSD8PtonOT0ZifqUlKPb+BQhvQSOGB4TRlHvaBJQ/xMqJGs1zeh0GWB
ICwQ4kVA/awWZvWgOrONTlHjw5gqlgzj+f5jfYHrDwfS4Uoe1PSCHPBDsmi3
O/AQl5aX9d02mbSOiVGsZBIxUxZRPZaxKKCN1jKqZrRBv1je5HOFjMSElEz1
IYvQOZiWECResI+w8hEi2pG7qC45Db3txDio/G5/J9No8r0i6hOtMA0vruNP
Wp8PkHtGOu2JsP4wx7qiD48aXzqt4GOWS6brMNMNUMopxUviKrA7fivqgVdk
DdyGpN3K66eyGYthWKpB6rvr5MM4tIpKymqeh2IKC3t7Ix8zBdGojy6BRDoi
ryBY8H2LIxoFBg3EoBCh7oID5yuWRkr7HbSg6KJP36u5lRl6T1XINhHGWpng
4KzbrZW8PDPedqBWLSDwtIV7SFJfkyJharW13UcGuffG8tsn2fezapgjni38
UDQdWT+SBFVYHB+q1n3+489vLgZHL0Tr0afMCwd+jE+K1rVE3sPcK6VMVw05
lEuNdE5JNNfPZIGso+U8aD2uGMWzXhQVvFNojuC6hZq4sKCS7hIYSDE39Wha
VTPWzWGYhNJO3etadS1W7GmxvN21wg9rwbsONxSZhZovcOZBWvRbHrPsDPVU
gECDk+pVBVTK7puzV3ugAVhEYW+tZ6MdTR31BysJ+Oz0yxfM5D3Ub2wLzkcL
h2tDAzqR0k4NQR+596GWqqgQyU4fqfuOFfCiTZFKlGkC1ZiSQ2EXA8adMru1
DUrO6A8h/lJb3UEsxjS7DVV6Rbbk9/4Y0rDeqTLd+rPTCe2K2OVSCLC0gs/t
51Nyi6m1MvgHn2osM+J4CddmdOhwfK/NGZhdamBk980/ifJGZZ2QYU1OFfb7
0RgR6iKUN55C7N8x5Soo+er5Uk+Xh+Og+Pdjioba6eyw+l9QSUbNChsIyUtK
7+YmNtxOm7ul9hzuJw6WpVcH2VmTXbwenL/5J3QTnH9E6knfaWU2FrbPGwhF
5Z8ueVVRM52aHKwccw8vVvYSpk56VOvGhZGPkdpudHH6tlhMLuSTcJxY2BDf
vs+tao/q2kcvXpxi/tfkwRT9yjyMr4y71gijAR8HON7BtLJKbuvFXWwsmVz0
yNqe8laaU1a1i/uITI4oW2KU205cE2JjYZN0JmiHathq03I2XkIHb4xRacxB
5asKScdO6azSb1IV0qQnr1ISyL+cQM7gCbWK4mqczOAtobM7TrNdVbRVwsC2
Oj3Bcf5A1Eg7ayL0SigmjilgaZ1NVxGjoLSfXt2NGuf6Cem5aaIf+4Y2CZfY
/fnyvRWb7ljG6eCoe2SCBILVE1qJiaAXh2aIsoqzJpAgtSSV3zKCslh3NS2m
DzW3lekoq6acWcnEaLqb/r0QG07ob840BZwlUIeiczBUY42GvOiyXVxVz+D8
ndNppCpOKC712E7JfhhPS7mk6gqucovVJiQyVjWs8TdrIVoPCPLq5A0vDvz4
iNhtVWQ2ATUTaJDPez2f1fArA8BREEbg4ZRWtqpj75ODBNOQBS/emj/8vB0H
/fxNqxhS2sNBjZhYR8n7Y+DAd25mYh9BbeQPO4qQkjtkcEizL2pHAzDUFvVv
1oealZPCPbxmAIdK466Ah0LhOhn1RSf1PxQZaVRJoPomN2wr7d7ST4IUDvLf
dUtf8a52TxoHKYUlKtbFAFLQoztJ3qFoleUIWbEq/HMvIL/LJkIxrYuGOQAP
xkVSwDomdGkxM3flqVlAHqH4R/IeChF+MilCz0IjjGElpcnPL97jMnusR+vb
1rHsYChGumSvYBON8swSHDexqfRrvuOWptPArnZ10+sbJ20BVsHTSvGYwVMN
p6Zah8PCsQB05ySq14ZwV8K3KIzXS36xfdV6VEj+t6uBTiztKFMk3548mz7F
6vjdZw/t4RpPz2FAdt/Yjc+ong7lR2YtxjBfquYeXE/+txsQhBBae+qS5Lzf
yvh+ez9/E0r2sNdEZ1kp7iYkqzoZT03xsvBynrXvsF1Ta7VFxw8JWVeCko2V
V+sMYdpohuXlLdeq6CA988CYfXqsTBDqTOtVD1Fh66RXGOY21lY3OojlVJqQ
gxRKykcS6nDNdqm3friC6ySh5chiJINVnPOkf1gQaUnwvssz6KRSFqgBHbPV
9CYPxfpkPJM9gOmzJOTXIlnM9B7Z2xGUWRCjCdvDvH5e2C3Eucum7Sr2U1hf
JLkHfH8GOGNabJ4kJLMemYLJgkthslSrjS+hRWwZK1HBEprQKolZBg5KYo4h
tksUkmqe4MtD4Yi0DLXhXMilbIX9zcfUyr3gUinyA/psSf2wBY1zeaJ/6has
7bi03lmRqagSRcQnbZM3l1GnUhMLu4c/+yyV/rWKAj/8IVREjPiAy1DS98O1
mEuK1j09RVF72UGtCewFfo9PKfMpVtlWhTW/FDWtmaLr47bq6zuo2aJ7IbWt
jYNEVlNMa8AVssJt2JdfUsBQSOCjJzndLEZBtrMmq3UTKiXwnmlWfqTMtZw/
K2oShmO9mU3MN/SJsM1iwoHo1oUNH+bRBoTto8CtFWAnZE/dRBT3LeV4XC28
e4ccgTm1qJHAV0lxHGQ7zw7delEj7ru2f4rUWA3FOp6z3PkkxHcZ+RUFNyQd
8nPeywJPIHxg1Sr6qphpjQDrTxyqBFhf4VD95L0YjgNQIgnRZIox9mDLt5Zr
SdbCmYSyYj+epFkPi7Z6DfvoLyJCJbCBQUjva+EEOPp4SYlAPyMTSzpiqa2G
WnkelcWpeFLW6I161tV9FKSpoAbBDuW2weVlIVDYM9jY8Ouk6doU7akN1dRA
pTYc1lh4Glzpd8UU/edrBfasljdaUKsSw87KDiRJ93NlSVpOJNRb3OZmgzGR
ngYvcncnNNLLCqo3BA0ziVa7CGpjiE31l4UaUr3irXy613u77TL9z9InomLk
9bbXdATwFb6i7EELTykaJ+lt6wCqxnpWAQ+XXf+clInMzoLcAkqcmY+ewcZ9
nFi16K/XWshd8YoqLm7edOeGgeHGpClgmyNmwv24dk8OYtfWpJT1bc1GgN9W
qy2gleBQIbNak99KvCqNIoMEY4dEQ8T4lvOWAeUYDLrGAdVWRLqCreTuMFW5
BXs1x7y1ALEK6aXWow5eEteQhI2hAtk0wQ+1NqdLuYmE7NJYp6IlqDcW2ZuA
W0K40wWUu5TnYpAIvSy996tqkWmFBDKacEQGDZX7XTI/Vm2icTE2bLrplSnF
x+mposSvilwTjjGZ1I4fjQLUVSb6BCybLyyADjz3WDg2TWeh7un2wM7I7A0i
f/tp0zIvBehYDpunY9EnqLNoSEEKMZcfAWFSLbc/HLJ100KCXutgwsKL3phM
Ua6aH5QnxeSa1bwIwJNy6Wb6fradyTieQmOXq5qqqMWrWqqnjIXGqpyVl9Fm
zw5QftIZ2AvQUVhs3nt2f3BBG7IF8m1k6nTTTYYIuqdDTlnWFlw1Kfu++8Pb
KweDPj8+Eq0AYl7DLdDj0m8ylYGIn11rgfv27QDvWzFbLdiPCERVD6azGjVt
MSaL2uJsOaOdC0PmnPnxx9mEQsvZ7sXZ1Q+cGIoMDfCvPzw1DiEj2I9QeMxY
8afroAufaz0/VVsTNgEV6RYG0vm7s+/2Qi1jnxd+K/OKJcrqBGamngOYTESV
a1A5xeqpQYgeJLXGSN2v4XljrjBq3TGuazRdIS9T3sO3EUu4WcnwZrHe5xbF
ilYoiQIunNViFtFs0THmal47Y20/+8WQ3zk/NKB+oWthZE1vun6mtDunnXUT
EgznxbukneECwG7lam600vRhPse6ct4JmZ1pkxhgsP5goecDqzEIYJiD5pTT
jYEW0DxNnEZSk9CCn9rClztpx7fSSgeE14I4YK2kc9ktiaOjVOkMtBfQ8iKY
0Acosb5gqky1A7XdGu+muMQcZflWBYbnG8r1FaiLK7of78T3r68986Bv44Cu
fSDvk6tDeEl4rT5gExXOz2imHTlHFcsf53t+/Tpacwkpdz6C1Du2N/bKAkaP
wwIb5bpLOORW2cF0Aftom8rvx17I4WLojcSh2OgmCDtzcW84UtnvikjZipBc
HtjNW+6zqxqq+KjLXPa0rJXw7ShAMz542Sq1+O7d1eXxoVkr2Xux7tZV1PeP
2XyPqqk5nzXYj1oe7eqmHc06XI2O2+9RzZUYS0efajGiW6LNvMegnlVwaHcK
efv+YHOMy2z6jLqW0n5HYzlpb23uzjlykXlxH5SjTUNR4MaEw8BNuGETWQOt
NtaZt454LNaaNFcKS7A6OAY1dbwU/DyO/TXTX0OC01R1Suv2E0iolyd1T4BT
2FNrBBDs0a2HQ5JPopDJSluaJQ9sDEUITnJXEkI/gd16L/EwMPlkHX4d4ai0
s61KjubkwCcUmlsF0LvqHPds3RB6EgROUi1ciY76peeYdZJwU0kRdJzAKj2H
o4uVIdm6mRsyCdLSF3HiOknV/tRwpbvIOrTz5v44H1zQv40SVO7q7joO2vGk
4PdgYbti0OkbG2qK5R7ayWOyQGv/q84Hy9rrzBpNDx8Gtu+m6EXlLp6HS8fo
DQ6Fg/SS8y1aOgraIFDf35DPlxOt2Zs3wSGdaitRwe6UO3J44aQxCET8EA0x
dMZGOoUuvJU7s2HlWqdvxTizeQRamytWOjwIXu0sHo7fOu2ubE2TPUK+Rrn0
x887CYP764cfzbpS+W6SqJk0hx0B5KTbqgtEh735zcA7SXZ7AEOHswwdekSD
tQzrFsLFUQCxT8oms93x/HrgnY+o5yWchbJULeDdes7NNo1dCpdcLdJGRE2S
vJUcOvf92zregliTGegVVCVyiLDnXCSpWi03fOuUfDh1vkCLGBoXYASRLuFi
g8Gkpch4rdrgvHa3Q5adD5QMZGfnwANKWBNLRWGu2y8kOxq7jqaJjBFU7lqO
8rl0bzcJc6ICS386tL8x9KxaC6JBMTIebCOvZN+Pv7po8fp3sYSEGDGhFa8m
B6ByY6eJXLz6LLijZy7/bAbahpMbknaDUeRxlzKtbpBqSmk1cbskLKVi6uDH
omDBgVvUbHAf/TrcNUnwi7W6bA6W1LHpaiRw8Haxd9xBFc4mAu4geop72RvZ
l0Fl//zC3lh0bCvgNWpsgViDFeVxvKSbtmlvlr+DQooWWbObsqnmpDktytlM
ObC+oI3QWpAcK5U2yctlyIG3VrERbxarZriaFXoxXHdS+6wcmStZIY6YW0Vw
PKtv2ZOYo5d1tVxLNWsDin+C/2f1zdiATZN6HQIVv6jVBVGj/oEJ7WrylYbQ
Dg0/W4jT2JzDEilKVHJXW1REdUUzy8xYOJTuUOVFPQTzutBi1SCJCe0ZTQ6w
mO7YoAFJVFdoFOv1S+5Th4jHpQYYPX+gBqrGPBIY6OpNgr0M7p/bOcR+KsyX
Kut2oXQUPNNdVWcfCh6iFkbhWo4NEyK4sclAVGf3k+/FB03xjzhcH8sVNwN1
oy1hq1x3nDJzqm2TIuV6+0x9TvfJe6G0O5yOupsQqnJuWBj5dtyZCIWJFWoS
SXDW8RwmasLuDhrYh3/vpBW+8KcdrewdSV8X5K15yZ0td0yDua3SvGnam3Kt
KFlCs5WYBK3J+jCXk6q1KmxUN81+MbIWo7PKZ5yaGQH9dRWM2K3GUDwsxmj3
LhFt8SXLywxCaIdyeqcfVG8vcgj3JvMzHhnFOLLG4hVHpoN4zWa4f2V2qZtW
HbB6i3hqcjB0UuSbOryFrknakowl0eweRNQV4xZm/Wu/i9ovjhHjptqjlRef
S8SDcEwV4gqhCJr1iqB+YH1aU7StNFltxauNnIWwrcDy5u/3k9uaATNaa21o
o11GPPLYmo5eqj7jLRU0kGFTNrPCy4U3OXG8u/mtlvz2CprxpscZ+F0PX/D2
U4p+dynUhCCQlqxM5h2s03gNAD+JkL6N2w38nEd7fNOT8mIsCbLQK8CSXHx+
k5K4G/Bh4TO3hajOIkDOL3/quwPfSvlpjidl/Zr+BKGfNt/oVhVn/UyHgLQr
ya+39thQLjV01XukI0iazlVXA3Po7szy8RgpOmmjI0s3ptZBhm9lXtJq8d2O
0m7ixQrQm26xM26lnw7FGkUKjVoY4rrLghAHUnlNOqa3b9ZoWQKwOV+AVs4c
d5RxnzlLno8tBM4GyUmicSRbt0N1h9r9ZJ1OVEDXIY0jbIN8ZVXOGm8A3LRf
Sv3lhDvHP+G6KgpQ6wq7PIznk5QbSozlsP0BKMotaw8XzN/ETo3hLzvpECgN
I0I62h5aZVe/VwlwuUP6V8GvlzSFa7fPSSTphqdTDmtWVhEqHVtQiduWtjjo
FIdWFdgQeqqvZJAD4YqXCZotLWk9fFhj+XXikUwDViiRAs9tO1aUFNVlMpr2
KozOznUHbdLmM5RciXPKQ+uyRDsxWVUSWCPr0iYnrKhizQRC9W/FBwv/xs7G
jHmPV2mtZ5xGUGfXu/LF9/Za69vAhK0it7x1YFlyXjQ7VdnC0ICYQQkMZT2g
aowNuKsFsrRyMo1X9a2qzRQzSlQsioKiOmXwN6wbVEnJ/Uqb0MC5nRv4FsnG
gbgYIkXvbNZ23XPnm19EZ3OhpFyC6E5I0GtUYFWwHszf6mzJGL/6JHy9G3wQ
2VlwgvlTWC3tc6dR189YIne1wMnnNZvABFGYpnqxRAumlVYHsunSUU2jT4sM
uzRMbTOTFxGtb/lVXvKVQjc1jlsuFTWAiEFK2Jt2t0zr7lkTYqJDlBM4Ei0t
2+vVKW0qiV3KvYnulPRgE7QkVZ67krXRgjattX1rTT90vzdudESiqy9yN/AU
KrpBEwg2oS6X7jDvyJxajAQmcsvpiUZ1L9iYHknv4ryTImQWUcFeVeP84dsI
EJuPa1F1Ckcqt40OBW51ZqG1V81GjbDSNQeMpdbrZqQay37b32O0XfutHcr7
k8ydH2qsmJmtpIOKvjLDAh5WWgfoY2CkQjdksJXqYAyqKz5vKxuwUZiREi5l
tOGYj9a18ahruU+N+iJCoUOA8/Olx5ipfCgg3/rK6y2G0WjAgmj6J3trIYld
hN7Uld3tF5aP6529vrkjyZrMcEL4OXKazui1N0pTfLCjkSwkkNiE8exowAas
jo4HTHKpiCsQ23kSqTpDUqN/c/f86uwNu1pdkbtteuQKj1hjPDyu9gekbogC
kOMkvm9zEWvNZ8ugsHq1WT52TspoYZWGHjb4jPtWcUpuAyaScmJ+VdS9vEy8
2qb3t89Jj4HP+9w29cLBHfTBkktka78Ka++8i52vVJfF+aLwH4sxeYGKjYun
00kPR8ZVd7TtoPcBht8r4AQ5paAmlnXyUCg1aQ95TKzlXzPZpP3dGYNgUlIz
e9jvvZmEjBeiWglAr5au4sYhrdwZLo5aLF226YXqEi+qee81DrNL5TjUm2XH
HVE+AtYIxnIR6mmq61ATU75mI0wUq0N4HPfFhoeyXM3KMUIs/QjswKXzJ7R2
VO0tctttRpLqku2IXFp3FCeqlJKyYXI9df2ZK6fU8lbMtjCHv0OMA+0uQw3v
oQYib7S7eoBiWT3gxD4LRImKMEW8FrEzcqxdHeS/8st+u8iRS/5QCDjAakpr
4myrDzRdxzk6UuNqtYCn7Apc5dLAxeAol+YtoIlSb96qZcgnyD3ZGyhP2Q3h
T56ObU1+h+U41gNeH00kEhUMXEeN27anJIR5cXVZ7zkbYNwDekdhlefjkehn
EpRi+kXlNvuaXsHtTaaqyv66pyq2cTECMFVusfLCcqb2vEkw1Ikekr1ayVat
gJo7ezU4u7jSjuaoPrwSYntQ2KXXJHHTjlK9GFUGaQjFWD2JIpYu1wJrAJYY
GkDPuPS0i1Ksx1zTaMztQV2jXi3hotac6rayoQUjZJ/axbEDb+zmtRzYwSad
BANfch7sBUnWsh7zxKNRzmNzaKYIq4zUvyeWWER9eum8tjJoUw+ZjwFgHDLW
gxgGd4k9n0KgPukkZ5UiHmwNhtRJ1Bkga7RFozmJQ7CqvaKIZaDyr1zlt5xd
TLpnAKXBZn+b/0ZBzPqBdO1vOHn5pddG4EhMvB51U0yyOzFqWhcCWgs2Za7D
sLQLoUf52HtMJmi4AIIYWuVSq28nN8rr0taNaPVFt7z958+vXv9w9vPrkBei
/2QlU25oqE2hBUXKTvU6ISVVuOB4hbxhfEj9A3Eus4coh3JNTIlwldU8/Zup
zYm6LFexYiDJNsMwy5GvwGzFeVodGEdrwz3bggi5mZ7skX5ZgZSW1qNIbii0
N1aIzvHaqEpOI3Ml3CUiNFir+y6naWkWF69f09B1qok+x6fPv3zZi+fE4wul
msukc7IzUUXxWAVlLKbfO1NprWYCYzFuO5gVUloMw0RB6q8liu7V2duz9+dv
3n9PIN2PsJMW8RJvol9TXG7zJfINW/g1Bf/jRoaSnBO5irVSDIeBYh4dPNxU
L7eDQ5yUc+GdsKp4fp8/n1189+HspwvM7oyR3ZAE6Oi1kVa5WdLPT/ZeaWqP
TqGvx3eFKiRGvt5GdBqs+qAvtN24ns9ELTeAzKhubluS5mKSVFV3Dq1Meb7t
5lnRk+xWZyCANS3W3dNuBY7BvqpFFMwUIKpMtBhJPwmEbSonoFQ91qsbJSFV
cMu6g3aVL0eh2FeAk4Tt974PEf9v/fq00mS57DLNfov3WbJ6PPwqd8FgDXxD
jl01TxNBya7OLoVXgfaimFdbyCDhKmyHLMVPoT8q6s69a0tULladFNbyW1Sd
xsz28xCVNsmPwjz00biHb5A0D3GcIxvGJhiJZbWyO+hagsI7HAOjvmRVWNLq
Vxs7MNpl3++9suhHyN/4/WBeWaRCVdm0mfxJXQ7vApe2cnGPfGg7FnChIrFH
y1XjpTVaje7CnJ3nJiGVDfpOupV3+WyVNP1+rC8gGskqgzY9zzWsfG1CrXcg
y5mAHzhCKHYJNhHn5ZVHHLakLobYRMWpJe0jw11qZZwTsBQKTTFUYhlK4HaN
pUTYBNTxW9xqO10YGWXq42qqpCOxlnsIG2vcaSO0J5lfoL6mYln7Pn+AO1Av
6K7VLn3Y8+xzOgPucu2zQ1EU+jdoFQgRNQM4YnEn153lreI86slKMtYDnwkr
YWQvkL9TEOPMWN+NyV/5qAKG3G0XSdNUwlYJnVDxZ4Nbfx55xF+q1/1OX4xl
RCuzr2Ou8NDk9ieXbL5xCzyvtZp/yyA+2yy6+UUrvJwC5pUymA2n1lo/XmWl
fINbaeMvL1MHp8U1iw2Z8+/KdcbP34hoKWgoeueQjSEJUh3ErIb3gJMsDSk9
s6rlUc0Ifcc2xPq9f7uxpFaCgrslFFoRwt1B1WGHBS83mA8peYoA8bOCxp1M
Gu8OEawdKnnqTE0pAlvUpFsUUmO8MGfStcFIilwjMggIYcY9R4Y8uj6/zGpg
0TXyQi6GpMRc1Qj1fPLLIRkxdJD4cH1tTVJilfQsLRmWtYMt39YbDmA/y8KR
munbKpAeKtYEG0K7oyTn20pyIJVt2KQ6bipMZ6zoJl+sPWWOlmV5c0O/hW8G
zqq9V0ol3sg2QLQiHqSN/mi5KLpywpMC0yZlIU+1YgkNgv+nKytTuUiTzcO6
Zf8QCombHPuBhc0GgdDDI2rjvG8CzgoWyU6WkxD4vrUSEl6nKKAEvSbA0yPR
cIIBROUmrYYRUrbN023EgF2M3FJd/3q+87HnAscSdpZw6przqAjtJSwRmsUM
rZQgUHuDyI/AFIXh3Kp+UmosRhbk/HfoddVUlYj3y/Mh0qYfhbXAXEbWgTAd
uxiQQ4T6YMjSt+plLBWGT0EYmag3H+y+KG8LA1TZSccJdLqFJl7Z6LDwRIl1
OIY21mblsZAkEquLQN+G1lq0m+FmqY/d22ZZGMqb1lrw4NWHVFC4k/Hz59dv
z66u35xbC7jQ44GZrZoHbr1pA00kTgogJRGVVAIqWpRT1q7qseg8KOC+ajd6
A1UlLbi0oGsoteapWQ812iyR3N6VKHsl+mV2dVvBZx2ySvc3tSNQhdnUkw7T
dBaRhpvEAseWjztujPWSaD9+KESUPAx+uHz1Pha5qMr6IYVqQwrO8ctUi6+1
aHmrYCnXElJjFTgXLnBsAZlECpxH/FYSMr2LNp1ak/zk+RHr+xAgaXH+BKDQ
ViKbzaq4bojj2VNNAstJNINybn0ctexkSpk2dodpyFZpORJtvdp3AlZeZgnQ
MK60BBETb9pUYr78s/M/9zwra9eBnpvS3WKS9zyYbHt9NrbsaWZ+Hlh1hKKj
gof5mSJn0i6mymh7er3Keasgo7Bqt5tctMzKtGO5TEKW0+/RuNYvhxihwi6j
hRS6TjsK04rQOevoeSAoOb6kczXOAdaFtdRk+iTSR35aeD8f/Cqf9UIizfpL
FkL1lM1+d16zWS/U+6X7MDjJcI5NKEiaduoAPVvX6ziUkiX3+6FhMXn+Ycye
lMid1mug4/Q2EKy5wEVnKrw7Sk4MakfW99blbAvCWbL8D3s8EP5POWa3rJz3
sAprOZpepX6WVoVVvyKAsmqQedlIq5UoGs0i2lOTHJxmVHgQjdpAr6vpJoY6
9PBwAT3m6srYtKInoJec01iPAAkGJUFInIs2XQlHyztrfOwXXgHZ0A/s+/tz
hJvPtdnouU2uB8uSlAz1xusykG2gqa+WqPROw2mrxZBsWeJCofJxwIBu7ETc
15bSqjvQERlvZbSP+WFtyjRWnxeVIQasWDY3qaaVlgbrx0lqaJxZ7vRhpIVf
1gpdJiqF8jBv3mQ5itgDc85rzXTFRo4K7a9t9rVWnVM/v9ZkTron7/co8e6x
Mhlt3nWwx5BvS4MfIxQ0Doempd7gP62WhVvTSNqqGGQ5tli+KfL/yk/+WzCh
63umY9AFTv0o0mLYgbaSswXFYo2AO16UjmLifgOYsFrJIwo9goz8kzGrQNY6
0l7K6mfbmizVKmTq2ODU6G7bwlV2syo1pa4MEmUwRJ8Ma8nkrrE0uVSD2wpt
CDjaCDpuf6ALNwplDZV+Vdvv/EnFRU7nqfekrrwU0+YVjItRWbfq98pZUIEL
S1hvBKQHmXm8mj5PFJ5KsXRdtDJd1j62QRk6SKqko2b0bYcPpNWMqJKj5Evt
jVaRzELl0ureWzZWdu1l9B6ys5rlhAxGc33G7ixVxmr3eOeXYtiq/PEzY/Wv
Q8R195ezn1/vYWq/8TttXzA02JjP2Y4MsyWFfHFwfPj06cuk3slfIjzodVze
a0s+vIyRf830I7qu1/v82ccS3de+pBGrooO1LJYhkzHCCPrwMQWsHiEdtjME
byIBSTdsQnB2Ir66NIlxcq02a/pkvxPb4OiBFmUq4wpN+qwUhpaQqIuNk/yK
CYIAGdPIQ8nb2HcghduGGWiQIvGceSTBIrrakaJWZV4UtJspKnXtgt7yuoFL
MoZ5oyvdeiV0M8/dYR6OvoWoFjV/qRVcGXSRJyF+WSGCqkLwuKYL1sZnrHAm
KiNzOqwjSj11AxG+K/Y4sdBVLUanurosmBTI8fTw8ORlu/SNAs+yC+aYnL87
v9gzYDBbzySA2/OL98HPKaoFDdvMw4Jq2uUzmKfzcbelULMhnSetAuNhKGCz
lLHXVo+KH3X/PdvdG5ZQdgcSGu2pGZ4GyNWpYrqay06PDawmxmVuLQ4csWug
6AfvXqYBp4UZHTu15nvtqPZmaTyxqDvTLTgxtZLXCu04IUcgbG0ht8YxO0xS
zc5Y38EyrRqcswIE3EepNVa0vQj/EDEOOsX+mjsSJ2fg9uFvgTsG/FDCklkQ
cNKapKZjNopP5zVctgFkiIczM4GFHCrTbAOi2R81d0t0VQafj+2WMX0V8Okm
yA2G9EfeQTDWJlWi1NppKHCu1L5L1Li1SE1AWjDmSR+gcB3hMEl8x3X9sqmL
2cQtLuLhYnNyLfIfSmoyXL5amOKBCXdrRtiJkI5dpw0I8SrpnxMDiLJKi6AO
Qvy9Fcmt4sULTT2VCXK12EViLzIVELjdIiDu6aNgGBcg00+iYc0eojNvsVou
qlrrsW8oA/sqxM9wrNfUd1CbrFUEdVuxV+9RR7Xwi/ZHdaiA13207pDC5LKd
bePsYBcd8Ov+FlJsiPOZ0bQkTlgpPuTKJZHp4HOeM5FlkT/AoxtTdnQem2YQ
8+a3fzd/pOxtgj7a9Of2hJKuxHldKj6DFElaccwmgtUgaHJmdncPwDRCQFQ2
VdVHdeaqH4m4ApzAy17vf5P/9WK5b528x2n4h8H2/yUv2ptaKu0r39u2U1/7
2fU3d+s9XVGPMTMIuZ32knaiF3VtQ1ifdLFqHBEvrElTh2ONyoi4alNTzGtg
4/DxYJQzgw3wnjgJ3Z3tU9DivU4Bmd579dwdP3tieU7y0JurH1+9++47oAf1
J3Xao4la8rVNJLztyx9YBaxV6Hk9n4p3BOM/OnLeuRkRTpW6LcMIXsto3ZF6
ZabZKbZbk70OX5zSofreOsKHFpePVOCvzc9iaCJEa604jvFkNVs0NspQd13A
j2Dl/hnyDdCrVnJRWKclOxhWK2e9Ig2Zh3XGqUWS0R6OAXTdHi4JkjPrGoPu
06eyFthP9iY7GyIS7FKevSzZ1ScVMB0d2fh0qwT6+vmIbjKD6nTj4JzwZp+d
3yz3pQGIKHpKUZaJxnhh3qoN5659tFVAfDHwwaYdZ0PQBlq7xTnX4ClRQvgM
POmvH53RnQpnoVcEax2k+c7RAEUQKtRetmJC1p4+/Hr382f/2MDxAoDd4cp8
3VxX8zjb1ZyTXS/I1p2ue39bU1Slf8MM4yfSOQpZuV96XtxrkZFILesooOgo
+MtPb869xdnhYaiCuUxbK6UZneb+MYA3qwKjiJM5UTYALjRXwpBo9E2FFIiB
7t+G2f3+JKKrzwz7jygyPlOAW7+tncS66bldvdDHd2oYBEU/tAN8OoutLhwq
mYjL5EkOROX7wTASAC7JMe17c9/7tN49AmLlqGw8hYLh2HUdTjmUgmBCNk3w
98G579unFeFjdCsClLZJFRt2uZrH9FnKTf7rl2IYXokNPum8wit1knL7VQtM
YKif0r6LidajZthIG0nhIruUGFiFOQ8v0QDwOIslaKjnKdWhtPIq1LuxFYJZ
oU61pgjKP3++fG/AgXmDZhUWHjGJaGerYQPn2C7hkUvZtBof7GdvHBPbalDB
Su/qhumvd3QNGMsUTEmXx9/8cjnWqZqvtdWCP8Gdo+0jRr2k7IMnTm/W7tc5
iiYKdlO0vYBkJ0e72/QiXuP2DfYTSEgMI7J+KCQcuQGCgdZ9opr/PiOzgBjG
OHhifOzo6CRWCd4+OTBLOKc3ohzXIsJeiOuLgVzXMnM3cZA1BWHbJtGJbH4l
q7f1td+wpE60h3eci7sACLqXPZQ9tXYSoRcDjJI7w24EruOlLr5GWCZ1vnBk
4fySoveAJs3K4RJl0Q3q19eOiZR8Bopj2N5QJlbGM0RI9EabvZU8p43J6kZx
BHC5VuYZQhDRmnc/tUA5HSCs6uH7EeFA6tQIuzJlVx64SVdFaMCmGXbB0xCY
KSaU7IKvnq14W2v3zojafTLO8NkJCHVvP4SUMaKJl3HiOkQf1YDTMGcI/URx
YikiLZ52i0vQSPhOrhq9o74Vy4IRKwYNzT76yqH0Ardjl0Hoa3oosHNo++Jq
euhNjE44YzSNxIq7tRl2tQ656JuTQTNa3KIA+bMXT1h/fC8cj6ldw6JTVz4J
9rKJs9X+nOzoRuXt+kFArQGqr7mJrZCOtWS2bUffT9zAv66KFct/VZ1KdXWa
COTYrWo27lIu/IkW0uRwioDdMrdhYfi0MMl9BEUeuYuu1p3/eHkGD5L85+i5
se5Xwux0b0coySoiY1CORsubwXC4HMQrPrBhwdlztarrNMQU0PDmgh/rdNmU
o+62UC89tXjtUYVce6VYw/MUWrsBf/nNtsiFezU311lrk1C3LgXbRWwdkz7Q
AB2/v6X3vwVuIC5IC2Hhgb3M2t3ZHMwTrxWTrIaM4sLU4ztCpVP5J4OSwa6y
K4sTD3dhGmotdZujxry1MaIQtJH/lI+qYS2n8GeRC7M67bhzfHh4BBOe194q
77Cj2RpFzEBqgRR+euUq/vMnR8zNoh9Tp+qQmUy7Bce+QCaIvTZRvl3lxgIV
r8fCmyj9DbXaabu1GQxoczP2GSGLSbWwM+sFvGGhqcaqqW4ZLlr78moxZq26
OZ3V5iifB6zCQPPbPJq1XYUfxa6uAKvkqEUILqIo8yT3hk5afTpx4bVRk+vp
Ckm6s6YaxUQGVS0tjT7tst54whWJcapdxJa3j2h3PwWTcIt+t8lmjAbjTxeX
sUpCsPvnDzHbIal4WQVOhrA9cH964NZBGoegYsTawMng6xKkk95RJyLalDHq
+i42IuvhTm4RShxDOEtx411XcDoDzb+zebNipYJ0w28Y6KBwt2p8ZRMlMvbG
QgpWICJJCVGQ7NombVu125PFfGwBI4UVJ7DptGF8GjSAiqgk2fY3qF2AQk4b
p5F7DZugSRKU4492sWU2Icerp3eAbjdibUaFtj2qxohXWw3VVwhsnRsc4NI5
ijm1nqvD741xp9x6iQZsxYZaTlqWNlB1vGLrenm7FNaX/npx4ZDR0mUDIY6g
QMB8nvhv4jf7dljo0wgZnbjCPJJUELsNk1zGeQmX9TK/z2AiJRdS8QLZ7g5N
p+urnb2BHnCs2W9m1fUV3Le82ReXrlZAFJMAzUroAjdjM0cttlN7/65kJTKx
jpc4VVpgrY+C7csRLK6Zl+ZB9zKF8WMY8+rcB31x/LQzKC4RRAiIW/dWg+o6
h2fIa1USHXHBVI/0U/J91cgoqKHWKYlW7kQzSSMCY1BNBogbZ8NZxYxId3Nf
fbiWL8n/X5+UKwfdBpkOSxdWyX6ybQTd2ly5TVZiydwVOrG/f/JyV36iCpLI
dUxKdyTSXIx55EMZNykE00oe9O5F3XLe9MIoCi4nug86mVWtIntwd8NMLcoG
FTK1a6n2S6Xk7pZki9S2n/3IwZMC1R9FhjJdE7+wS5fwyqRtZtKJh9TgF9MR
GXoOBBCkfRutwLTjhteNlrXufdrzLLQsBqMYaAcAq/KhtRaSEhBYv6ypFTHS
FNJ2Ezc5xkRVj6XWEy/DJLTqS/nQJiaUyEpLWhgXsxbkuc/yISGXRaHE6s5C
paq5C1aFfEfS6ms5AL7ogkGB0OaHUG3N27EAndQQL7ib18qBYWs/e3pMWzsZ
C1kQxZzVvkgYFhJJX3t69OKw/VqK97E+lEllWCCVDGvIW7pia7qJnVSoYEWC
jRm2ODxduLF9r0aKOmVWpycUpUS3TuFmOAEWVxeGKVrEldoExMy6/fCBeI+6
FXNzx9VGgWy1L7Qpjfmjz8vlaCWM4JXIho/u2fgJkAKRkpjIlSMQXJg+sUyJ
umxW3kIA2sscsmTGdzZ4a1R5aVTH8qJE2hGwXqG/b6liXX6LEbTQths8cheT
eqYRBpp4YKLMMHcUhIl62He6a9xRg0FTMgrzZapeo5cQSlfr6jq9yPJPKOK9
AB29uC0j0aRmDCCkLX2xA+t2LnAxuy3U7c7r+ShfyDLV5nh3+fYKc4A03tmg
gsCVc3p0SFfOm8l2NaPjhdbZI3XMP6a/p9BvEuel17CFayKm7e40y3IBMMjI
9ndo+ytzNNaMg/IiJCGbzTR1tScY/QFZnruL8RH0iFgS7YCGHjXHWAQMRESp
eH2L5E7HLHRto6bhzZB8P2BJg/hUEpfq87obHD3Az2TPvBjY2GIuG8JjZkJv
DJ1lhq0VFQfSuE6teV+ZBb/nWiR33mqVQzNZhifRrbPrvg5S1m5GbDjt/eyM
txPAnlldqFuUaxGRjlLHy4dF42Z7a7cz+yOukyYGavF1MKE0owA91ZrQljt5
KEBn4H6eP6igI9URCsNbFApetkIULERhIsIqFIixKhdM24F1Le4EO6gcvB/r
njqusx/6qnAadM0Un1JAvlkYebt1rSwHN5uTxD3GFm0yvzzQKqo0IYs2sB6k
nH9MLPz8WRfgmz/gKoRY2i13yhRCFQAl9o5h86lmad+y0D3OSSIk49GIMv1t
YFiuDdTUD4XJwEYeEhTrepXzNLYPb49tXRumZmmXZWxD1Q6iuNIclw37mdNf
hwFEIK8PFiCDd+qx7nwIIsgjjrg+HO3kBDO4lB9P0F86FnI0KCnZYTlq0h5V
+5aAbuOW6zwVUw6hSx7efDPf3VT1ZJctwbu3YM+CpogA2+WHIIVbstE6Jy6C
kpbC7PR1tadrFtaxHxYebhXNAK9OB5AadkXRHh1ASasOaZSKGPH0Cd+/eH/l
bjasOH7Lh/CPYYXKWUyQ0n/Ksg5/aEcYEYcihdCCbOxA7RweoG9QUnY99GxX
X4O6YFBu66a0pC6kZyXJwz5GULy7YdQ7K+wbl8oti5Sx0tKSvcByyWg3ZHF+
6YeZJnGZOvFLJIiU2KrOikB227v3s5gQqEaj1gnr5D7ye/U2o9YrDs4riykE
xWJpmYrM5wspj2hXV3lZhFTLdeG1McfRQqodw9dDiknyZqiW74lofVXAtSZV
d2c2JDOqIcJwDmXgul7lsp+0mWaYRSZ4G0uUUU1KPHrJdhcMLrIkcl8DyxG/
Xre0ss4iFQ4OnjpmwRfOJDaqDVgWs7g8kWNsMb4Xx8dHxBCNx4Yd954Jit7d
iUrJTlIYKmEZngVI34wHB4cPyq6s61atBctulmx1AJbDtmVJF7SgOsRN/Lbe
HDlw8FcZypl1quCMNpm1dndCGCz1Kq9dtw16mFcHKmstohhaCFIXYM3R+SbL
pptaljg71aWRXuo+IwaFwjbsSdNhUhPGoAPJ0GBsoTDO3OvYrTXU0gPpNG60
fIQwNb1+G40n3zxrx5JW5rAGLBZ5tHTEQVMN4E5mKEyxNQhfWg3j6IdnWdIQ
k8PTKprbymRaNU9zkDZZkkQib6xHFkv15Ddl7DLnF/mY+tOE+R1svCh8/LED
DWhMpj0yXBYuBdjf++L+QyGsUF0Jp8+PAfoI6Sdcmscq6IWDkwsA7JKpsYpI
Ce0v2g0BNhRSwPGYUrkhoEZS8z8j9Crb8erVh6jRRrCuF6WZJfqbGc0Bh2CJ
Bc2DXiFNfI1OPZp36jj6nRigq7yQK1ZpJj42m4n+EyqahOB81r6rySpDiw3d
gY3f1Ezths32xqyfiK2Qp7ttwdL1x/ggbUYc66BuHrRi8mOxzS10YFMl0gFd
R4LAeyuy5pPHLYPDSLc29mkP+W51aeIkDkfVUasbqeKuEapJDqeISfNNM5a9
5Me74+kxylA3s2qYa44r8TyEyNyq4vwI37S8nUe+rILp6+CT2s0hJseB0HCT
EuiwSpFQqOVrBu2nTmA1eswPfB8aZ1GVvNdQOeoGwcGMeu5uK6XhL/fvElXK
/kFiEgxXGkOi9+HW61xbYwd83Isywoczt0Y8hemmSayrry6GuLSlXUCrYtVU
8W9myVlGtEFP5ThqC85t25EQmiNviPPX8YAbUvvbg+MW5EsVyv1sA9KyA1iN
Cru1XKEW3G8D8dQ08pqDo6bTmz36p7GHW1lNUmBtyjpXphp65p8uhRM4Cqi/
g+POXGARtSGkXp8yBZTEADB9DW4TmBcm+RNsTP+jdqZjrQZWv4Oi7PsTLH/w
Qpc26Hs9Y+hd6Jepe27mo48jq9Xm8xSPFdTsKSpaseymlRrOqiQvnhCaJAVh
O7+wMNXfs14mgsUM5dfqkijGBiD4/M1G/0avt9N50ny13iWymS4LqnrIilEI
/7vU51GMt5acSWH5So0aNKkUXnJRiskH/zVs6jp7J+z3Rq/Y7sWHd3tJC3BV
azQRMvG1HNSF6OIQmR2He/ysgi00LpJMd8nmTAqjM30hCc9D2DRs88sejd3l
WikXAw1tronjEeT1r6ulVTYKGjSvEuwZ2r4hr16T4HfXk+46zS8SjbDritr7
f2DyPNDEg/gQNLh/EP70D48tThVnIqWgNtBhX0drUhQJd6m1elV4awBLtEs/
TWf5p5x9OEPchWuj03FtjKC1azOxYkIuqEFiLfwwiEtvv7l2MN1zmVYLlJVA
HZQN56KVYcO7E/mh1tjT7ea7tXZCnv2beh5r96/Ke8n3WZnEqSTiXLZ8ab0O
D3kc7edh4R1lreTMGr4Hx6hVAFTGxtl1Wip3IDWpWxVRZOCulnVhSl2yGJ5r
pPk4/aRZb/7gfoLYF9Nq7XmJrv5XLFyO6XXs7khof1hNEtE1KnQjz5HQaV15
KD6aoRGzGDbtXRg+eNvNzBqCfUL8mKM4iUPTHGc8rFyiTDxPW95BpDu7Kaob
0Zim6DRRqBNVJVoss+9dX7onsmU2RCIp0rXVRRkNahYrh+UtDbHEEG7o67dG
94EmkIpGjHhdOq7PCVxBdKo6QqLv3OWzcryT7QLkVdx5Bp86ZiGmmBgFqknI
BFTzyI00Q8VR3mU3TXqDehUcBt2avZ8/xw/FQI5ZxcVxcRt/qfG47zUGwMon
SX1/fDdKc2Xjr+OMP3+TBorUfvBq5Vr+vnv3HEAGKERp/NZdUvEydLyr/bQs
1dwKzlsvh0d5u5JAPt8gHBb0zYHf/R7nNyZv01equ0BP8kv1n7yZs7Iklghu
hCjhfKBA6rWvRrijfv73vx38CpQjcYtCe+QkRivX4241w0FaoD1qbGpTijU1
D7OzutnL6FPRA5nYXFtcjcNYv6Ru8/K+4VP/8z/+z4lMH6XSZOX/+R//V4v9
FrG+O9/x7reO62FhNRTUF3WvPVKNoYSktMN8InoLv91l7FTmrR87xGd2oxdq
B1KjoHUbuy2v50RZm/QCgZrZQxjO3GCsORdms/PGNs/tnavBpU5OvvK+aCaz
8pPWBKKK/QG1w1DgeAf+2vMfL86uLv/56Bk8tuqINEwA1u2NHEIumta7Wvve
InzvTr/jpk2KKVSl3RuhmNu5mN9on2NLQ0MbIC0bpja8qi/ULDQ7b95JBnJf
YohBeft2kU7zudnBeRh3fVjNXeuQq9b2jR2Vm9ai1+9CWuun1FJ92nvPeaph
gzUqVMxm3Om1+3Bv7lydaumboFTiraSGyJ1An2WLf9dJ0iCLjYKgksscr1GS
Mstz044UaYsKyj63uqrQ7uL67VUSSvRESH84ee78st8NqFO2dPpgjJOqiqt5
3E6YfdZ4JqgzCSg4Sv12pMY8VuaBZnFcLbpaldrIi5OO2GIoQklBI3Ntr6kA
aQRfIU9HT04tzS7FBrcjzLCfTGvnJvc3BplXtZk+bX90mpVsyKputVF9I6K1
iMh4e5Ud7T/JvLcnisvVUygV6sw8OWEZhrnVTwEo0VEG4ZNHViphI8BiE7Ii
wDs+EbagwT2U+S7nLGQ3V7AnYKNlMUNN8DfzuGSF+esDGq/XEFW3H4J/LpIf
eyLveH9PsdKXOxbgFuEI15ce8nkMMb65sH148eJFWOVdEUoNqwsKfPvr57N5
Hl5Z7mclgv72GeksrvSmt/6imrKq3JqfUfeTaG7bn0zP1U61yP+6EoZOR5Re
7dT55PiD433UYAuZZkQ23dLtYPE5hCvKWowxp87WX90Q7YAh2oUzkoI3Cdog
+OFo6pXzWGq6gyfB2N86TMQqMkFC36K1kLzTjsAbVM47fvrEyOvgLIyLud8M
62FM1RTPYA4H6Mo7bO5wWeVjpHEKAWUvDp+e+o15egpa2unorfmSGOqIKftB
78B5W+3sQzJzMj+GlcRqPq/vrLwbtiSESDZkuuysw3PYrGHi4cRinOoirVoW
Sutk54bDUddfcEd6TmDH2TpaV9TN/TfYZI4mWb9sv24eE+2pbj6ojhZU1m0f
6RuXCj9fvncc7Fy97CGXKmkl1Jqg4Uc2KeJ/VCWOuCvKNKIL9WJ4zFpvs2LL
471/c+k184qQp+ygExXwMRgf3Oi6QjWRNphGP6iRJf/ZZBttMMF6vR8eMQCt
O6IqTvNiAsHTMetawLx2u+ptSiy1opVYsEtKxrZi0EfmD2AYjzyg+HZtz77t
sXBpHvWzrWV7KX8Ni009RNe/t6Zt7spb5E02S/5/kOTjKyvdr9JZj5WQGxY6
FNS+1rlQWQ4nx0ocIqZTEGeTFtFBaahwI5jod7uQ35dUHhIfQXfF8RutLkZE
WcR6odAlk246hlBTXpT2G26vUQN+NmQrv0hrU1bG1Lt7k+h5eJNZbZSAaDy9
UqQ/S4NgwvjKd4rH3Xaa39JlqEb0HeuGxBpDoy5fJ0AVTEspZFIu5Zw9SkLg
kRbNiJ6bR8hIXWahh1qboDX1zQuIOO8wdLFX0WkXpn30Y4wtoeik4j40AtzF
vVbQZQyDupOWuTQTRzl6rtAfY7zIzUKJJ/rmKmrMDp7SuZbmpNUpQ7I8avXG
a6qZJ9jNVk56mKH5PDb4O0rvlGA9GzxEtaUZ4Y7QspBAZbxamxB6wDTsdXIp
kexNq0eLVKpgUnppC3gDrtK/ZzzBbFPf0lDNfASDPniaQtxXXU6EEqUJ5o9s
IPdPaeuxk2Z6mvU1iX09k2EVOdIayxmnpqr5qr07p3rRAmU2ye1Oyna5GwH1
HdDNWMkjnyEF+iFB/tDnqOfWQpi519GSSRCM027i2dl8HDQqtENhF6Nu4ZbB
1dn7CxFeg8yaPia1jrPQu74Ol092t65z5gi4GOKQaf1VjqvF01y9LGaG0Ie4
oIzzKiOPPNwPub8OhtbsdOy6o58sa2X0YG5OO6xQsnOYlv9qJdMSMBHbHAft
GdpSpwIUQ94aG+57u2Xi4z7xZo0s+RPVPPtpXd9kZ/7zP/6PumU9k2s3ebOq
EZPbudDufonKcomwypj9I30brhDcLKK7alOaxu7Vh+vLvR2z7p4dP9l2uAnO
i98MYYEYHtv03WbLd9slAn8nRhOitDcr2Wm5TwV3wb5jNRZhVSLj6eq7D2fv
XnMZ6aJKK9EIi9QSh7B0txj8z9EHVRGxV4yZtBiqDERkQ0T6lo05UY2/xV6b
7uWwsgntCGAAucbsaxQCtjbxdIsgC6aqUVrv8bX2WwXl/579jImnvoCkis72
ckjD4gG4Sewkga6PqAmjaWUVI4LE3aakxAZlotazGmNLlSDYLLpZLQyPqkwh
UKQwqYB1p6MhcZN5wre60NaNWq2zcIt09Ydk0LE2I1kU+UfZ3dWS/GJZ3CqD
UdS5NW5aIg3OEvhjwMtro1NQEUeonKmq0zfA/Fe1pqo656rYw3OWtLgwnXm8
ocf5WhKYKfjLYvjQ4Yi+dpYlC3ZAp1WD0XKJ6v11IzsHzfA9i+DJLV4NSzmt
plq1orVpPUXNbdVb5s1MubnGXPqPCWQU6rey7C0aCSXV6sbR20gLuBfCracq
pAE/YHJ1cPkHqevrTkqVr8FyaYwY2jMYUeNxwBfHubDR2bJlr8QkWPMCGQ2x
kXSESesFI/u0dt6z4lM0iNligjDu2MDL3ftJ1FIlVajFpIjXDeq3h1Dcq5Og
NZ8fo2I0Uxp/KYYfrs/3LOL4uLNrN0nN8XyQva0292vlQa/n4002dyu22eu9
3g5M+ePWdgxCbqMz80BssUz3H5+PQtfomYkmVSI2jAYf2EIoVvChicnUtnG2
cxlaer+LLb3fkNOdUac2Ka2NvR+podH3rVBmtalROMOAmOjNssi1FhJ+UNsP
FxbKlpYvXBbafkG47qQxO+lK7tlYQYiQmgrh99bQjUmuUPDS/DFekcWR0+pl
TaKAAwuaMPL19srKNlKAEig+C6OrUhszU7iepWhoJSta/t+tXU1P20AQvfMr
Vj1WMRZST6hCiiAgGgcQoSD1tiFOYnC8yI6J/O/73uys4xirpx4dx94P787X
zrx3KG5Xz06CVxpmV5tNPG6lSfDeGbfT3mO5ybr17gPzCT65+9rDXNvPdPYf
pFOLAKdOOfBawT/0FeTEWf0ln5Gj1Bg+bNb7p19TWO0M60qWTONJTKjg9lbR
5TmxVw+3EjzWRCaZ1EBBo4lZHrzwiLXFBiCEnhyU0z0rAMplYf4Vn2wj16uj
hKGBaEhddCTlsAfqCwOLcBoeBtNBdSmOKjW/AikNVQcNZVZoaU8/wNmNHxw6
u2j+LUX4RTAN3S63x6tSNVv1l2VwxzsF6WKutYeQOyKRhZz80BXVmxp9V3A7
xWdWBnI5qjjIi8pmiir17SmIHvHsmdXzGaDxPD32EYVNUDTK5jgsUFqnv3JD
yS4BGS2U7GkHeE6RBQyVnRNsFd0yHtSiM/Od1hjSZ/c70L+HorADj5gjbmrq
AxU1s7glwfVadeCj8r17fAal1iLwlSpJTYmZ3UNIHUorgklBgUPmE18T1D6t
u0s19GqAXt5q8nju/PSen5yY7+bnZrf7qM7jeI3vXC9O0WAsSne/jrbuo4qX
pV3tIvmJ11E7x5H7oMCKF7lbxOxdnEtxXrR0r8N/Pd0uL6DNlpm3yynLziUe
9/sxUVQYb1W4gBysfk3Ao1Mz+HYyvzETcqYHlsN5mv6HkfhS7/js7MeFzKCH
bRPsAXM7vhv3DIt+SljrOzC0FqjlqP35rE9xDu5P/0XtDa0na2O0ArhU9jK5
BhDnWy4JB+N3sLh7/5XMdLhqvM1cCmjU/qi4E2PB+IQk7tBpoRziCMevzLfJ
06XyOWCKLDnssE3GsC8tWXHMjast9j/23MiMbYnOXdv8fWQuNyUaTlL6TpBW
VzypuYfYHZkJ2YaemwJSamRu8rQomEyFG1NW3Tw6plsmaZVn0EE2W9M1S2Du
W3NVFwsLDZfU0LvmAU3WuDezMMDvnEDDbJhWNMM0mzm2NHoxI/LOpFiTY2vE
4h58kCk6tiksLiELpEQZjrEt3qBrZ7hT4s40Q0/xovfNG0zuL4N5wkZu0IGa
AdgXSr/E7tkY1jYcgzlDOaveQHHxbqasqmXDsHIwuKLJMzz3TEaZxsy3TZW7
T95epFBNePGO0jmhtTch9QxclD+WXGFzjJm6/sXSZjPTegttNzK/3KZA62QT
LGViMCeYNTbPNXVnGbK6xCp5YWqVTxWQ2AHR9OggV/VaCwKoYFKyMYVSg+1W
kYWiKDJM2Dz5C4tauIW6VgEA
</rfc> </rfc>
 End of changes. 205 change blocks. 
2865 lines changed or deleted 1021 lines changed or added

This html diff was produced by rfcdiff 1.48.