<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.19 (Ruby 3.3.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ihlar-scone-masque-mediabitrate-01" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.23.2 -->
  <front>
    <title abbrev="MASQUE throughput advice capsule">MASQUE extension for signaling throughput advice</title>
    <seriesInfo name="Internet-Draft" value="draft-ihlar-scone-masque-mediabitrate-01"/>
    <author fullname="Marcus Ihlar">
      <organization>Ericsson</organization>
      <address>
        <email>marcus.ihlar@ericsson.com</email>
      </address>
    </author>
    <author fullname="Mirja Kühlewind">
      <organization>Ericsson</organization>
      <address>
        <email>mirja.kuehlewind@ericsson.com</email>
      </address>
    </author>
    <date year="2024" month="October" day="21"/>
    <area>Web and Internet Transport</area>
    <workgroup>Standard Communication with Network Elements</workgroup>
    <keyword>media bitrate</keyword>
    <abstract>
      <?line 37?>

<t>This document specifies a new Capsule (RFC9297) that can be used with CONNECT-UDP (RFC9298), CONNECT-IP (RFC9484), or other future CONNECT extensions to signal throughput advice for
traffic that is proxied through an HTTP server.</t>
    </abstract>
    <note removeInRFC="true">
      <name>About This Document</name>
      <t>
        Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ihlar-scone-masque-mediabitrate/"/>.
      </t>
      <t>
        Discussion of this document takes place on the
        Standard Communication with Network Elements Working Group mailing list (<eref target="mailto:scone@ietf.org"/>),
        which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/scone/"/>.
        Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/scone/"/>.
      </t>
      <t>Source for this draft and an issue tracker can be found at
        <eref target="https://github.com/mirjak/draft-masque-mediabitrate"/>.</t>
    </note>
  </front>
  <middle>
    <?line 42?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>This document specifies an HTTP Capsule (RFC9297) that can be used with CONNECT-UDP (RFC9298), CONNECT-IP (RFC9484),
or other future CONNECT extensions to signal throughput advice for traffic proxied through an HTTP server.</t>
      <t>The extension can be used with the HTTP CONNECT method when the :protocol pseudo-header is equal to "connect-udp"
or "connect-ip", as well as with future CONNECT protocols that use the Capsule Protocol.</t>
    </section>
    <section anchor="conventions-and-definitions">
      <name>Conventions and Definitions</name>
      <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
      <?line -18?>

</section>
    <section anchor="indicating-support-for-throughput-advice-signaling">
      <name>Indicating Support for Throughput Advice Signaling</name>
      <t>A client that wishes to receive throughput advice capsules can indicate support by sending a request header
with the boolean-valued Item Structured Field: "Throughput-Advice: ?1". The HTTP proxy can indicate support
by sending a response header with the same boolean-valued Item Structured Field: "Throughput-Advice: ?1".
See <xref section="3.3.6" sectionFormat="of" target="RFC8941"/> for information about the boolean format.</t>
      <t>Once support has been established, a proxy <bcp14>MAY</bcp14> send THROUGHPUT_ADVICE capsules at any time during the
lifetime of the stream that originated the request.</t>
    </section>
    <section anchor="throughputadvice-capsule-type-format">
      <name>THROUGHPUT_ADVICE Capsule Type Format</name>
      <t>The THROUGHPUT_ADVICE Capsule has the following format:</t>
      <artwork><![CDATA[
THROUGHPUT_ADVICE Capsule {
  Type (i) = 0xTBD,
  Length (i)
  Bitrate (i)
  [Average Window (i)]
}
]]></artwork>
      <t>The capsule has the following fields:</t>
      <t>Bitrate: The maximum sustainable throughput that the client can expect for proxied traffic,
expressed in kilobits per second.</t>
      <t>Average Window: Indicates the duration over which the bitrate is enforced, expressed in milliseconds.
This field is optional.</t>
    </section>
    <section anchor="applicability">
      <name>Applicability</name>
      <t>If the sole purpose of the communication between a client endpoint and a network element
is the exchange of throughput advice, it is <bcp14>RECOMMENDED</bcp14> to use more lightweight approaches
than HTTP proxying, such as <xref target="SCONE"/> or
<xref target="TRAIN"/>.</t>
      <t>However, in cases where clients connect to the Internet via MASQUE proxies and also want to
receive throughput advice from the MASQUE proxy, it can be beneficial to communicate directly
with the proxy using the already established communication channel.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TODO Security</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="capsule-types">
        <name>Capsule types</name>
        <t>This document adds following entries to the "HTTP Capsule Types" registry:</t>
        <table anchor="iana-capsule-type">
          <name>New Capsule Type to register</name>
          <thead>
            <tr>
              <th align="left">Capsule Type</th>
              <th align="left">Value</th>
              <th align="left">Specification</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">MEDIA-BITRATE</td>
              <td align="left">TBD</td>
              <td align="left">(This document)</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="http-headers">
        <name>HTTP headers</name>
        <t>This document adds following entry to the "Hypertext Transfer Protocol (HTTP) Field Name Registry":</t>
        <table anchor="iana-http-field">
          <name>HTTP Field Name to register</name>
          <thead>
            <tr>
              <th align="left">Field Name</th>
              <th align="left">Template</th>
              <th align="left">Status</th>
              <th align="left">Reference</th>
              <th align="left">Comments</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Throughput-Advice</td>
              <td align="left"> </td>
              <td align="left">permanent</td>
              <td align="left">(This document)</td>
              <td align="left"> </td>
            </tr>
          </tbody>
        </table>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. 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="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8941">
          <front>
            <title>Structured Field Values for HTTP</title>
            <author fullname="M. Nottingham" initials="M." surname="Nottingham"/>
            <author fullname="P-H. Kamp" surname="P-H. Kamp"/>
            <date month="February" year="2021"/>
            <abstract>
              <t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8941"/>
          <seriesInfo name="DOI" value="10.17487/RFC8941"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="SCONE">
          <front>
            <title>A new QUIC version for network property communication</title>
            <author fullname="Matt Joras" initials="M." surname="Joras">
              <organization>Meta Platforms, Inc.</organization>
            </author>
            <author fullname="Marcus Ihlar" initials="M." surname="Ihlar">
              <organization>Ericsson</organization>
            </author>
            <date day="21" month="October" year="2024"/>
            <abstract>
              <t>   This document describes a new QUIC version.  The proposed wire format
   and a set of procedures can be used to communicate throughput advice
   between an endpoint and an on-path network element.  Throughput
   advice are sent in QUIC packets of a new QUIC version.  These QUIC
   packets are sent adjecent to established QUIC version 1 and 2
   connections, within the same UDP 4-tuple.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-joras-scone-quic-protocol-00"/>
        </reference>
        <reference anchor="TRAIN">
          <front>
            <title>Transparent Rate Adaptation Indications for Networks (TRAIN) Protocol</title>
            <author fullname="Martin Thomson" initials="M." surname="Thomson">
              <organization>Mozilla</organization>
            </author>
            <author fullname="Christian Huitema" initials="C." surname="Huitema">
              <organization>Private Octopus Inc.</organization>
            </author>
            <author fullname="Kazuho Oku" initials="K." surname="Oku">
              <organization>Fastly</organization>
            </author>
            <date day="14" month="October" year="2024"/>
            <abstract>
              <t>   On-path network elements can sometimes be configured to apply rate
   limits to flows that pass them.  This document describes a method for
   signaling to endpoints that rate limiting policies are in force and
   approximately what that rate limit is.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-thomson-scone-train-protocol-00"/>
        </reference>
      </references>
    </references>
    <?line 141?>

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA7VYbXMbtxH+jl+xpb9YHR0bxprG5kRxaJGOOJVIRaTiyWQy
HdwdSCK6A84AThQr27/FP6Sf3D/WB8DxTS9tpplKMyJvsQB2n919dk9JkjAn
XSG61DrvTX68GpC4dUJZqRXNtCEr54oXUs3JLYyu54uqdsTzG5mJFuNpasTN
dusDFcp4ZesCqhl3Yq7NqkvW5YzlOlO8xK254TOXyEXBTWIzrURScvu+xofI
JU+lM9iYfNVhtk5Lab1dblVh43AwfctUXabCdFkOpS7DdgvTa9slZ2rBYNkL
xo3gsPCdSImrnIbKCaOEo6nhylbauBZbanM9h+UV9CYOWtzkdKLLslYSdnso
ltItaCScV6VBIUqhnG2xa7GCJO8ySigYTI3F7EaoGiYR/W8HE0UvW+8g9+j/
4I/x8pLLAvKA1fdSuFlbm7lfmOOkOsVSKc1v/PovEdlH0Gwxxmu30MabjY1E
s7ooYjjOuclqS0Mfj7CEw7mS/wjGdmlgZGatVmFJRFPKsKUdQvi9aBTamS4f
Od1bRn/71z8XhVhKlf/eG/y29nUtmm37tzClTYndN4CbSTXbeWJJkhBPLdzO
HGPThbSEzKs9yGQrkcmZFJY4KbGkk5iq9Pzy7cmrr199c4B05g4ZrCgVVFuR
x2CdjEejwck0uepfrHVfHhxuxMNGevTyCFJUkHYLYQCCq41Ya22LzJLTTZE9
Uj5whsH42Uxm0Ro4UBl9K2FMo42sptPp9IKsMDfCtKPTpczzQjD2zCe80Xmd
eXj/AwTNIf8PENgfB4HWIPxX56cLscNgD+yGGY2jjQ2lQCVgcSFUWOziBqcz
XVBlRZ3rZCF4DtMBm3hfe/s0tVB7SmQuqXOUJKzbCGTVOiRuaSmKInz6O+95
vb7ARmhhW7h4jfxFs9z2wTvRCkTiAkSevfpiJpUMz9FVEBB5BrLg4KvJFLeH
TxqNw/fLwY9Xw8tB33+fnPbOzjZfWKMxOR1fnfW337Y7T8bn54NRP26GlPZE
DJz/s3cWVrXGF9PheNQ7a5H0KO6mGOjXQ4YgSM+8lREOseCW5cJmRqZ4wJ43
JxdfPneO6O7uT0ibrzudVx8/Ng8vO98c4cEHKN6mVbFqHoHbivGqEtz4UzhA
R8ORjhc2hMEu9FIRMk8AzT//4pH5tUvfplnVOfquEXiH94RrzPaEAbOHkgeb
I4iPiB65ZoPmnvwe0vv29n7ee17jviP89jWataCk8/L1dyzWfx56DXrIpK58
wwsFNd2WWS+W2WTd6RnrUVZIH72QoUtpFyKUqBGZALM+3edtqDgZrxRkmwvT
FQoUQtjAcQgaknUUC4ttyjLVuhBcJTe8qJEVQydKmqCPZ756cnorRZGju20N
T6LhXXrdabVpuq5sTxGrR+1g9+xA+8fA0Biy5QeLXvUHrWETIZC/ExFol160
X7T/SnpGIaFfHXWQ0D4Im24FHZ7q2u0CQXENmTtW2RbLBfI6FWArYMjTwscm
R7I3biNDgos0Pb0cX/1wenE1/Xuv/9PwZLANEULK1YqchJt5beJsJ1ghZyLI
YGeAwWFyKmMKaCPnUnEXmFesQxgo6uFFayabYoKht8GJSFZPq3qn/MEzXRR6
6S2KzqOHf/r0iT298Q5zQrjnuTygY/rqdvqmfwjZmVBzhBNS9uXzl89v4uSz
ef6lh27B54LeIUf00st/ZR/DXcHS7Gm7fOAt7GqO7IbEK/mtLOsSQUJQAFRa
7BVJwNCf05SVT05xi+Yba3HT1GKTO2RYQ3bayI3XstCY3ND4kaRWoNXkAH7f
ge66zEW0F2GNWaVvfGYvZNbUWIOD72Y+9zKfO3u3lbJAToVbbDuOC8Flv0VX
/kweW1OvqgrcmMpCuhVjwyZpkLpU1abSdpNI2d7Am2LW9enL12AgWystfatA
2vpRLM7CIs7CTEaPxG224GreHHqPfg5JhtFohzc9XfnWWmo0oELOF7jV/yW0
C6N5BkZjCIva4QyE9xARBFSI+t3d6wk69uB4mPTbv2nDbfN68r6WWbLu4ahj
TGjQnV72hqOgi3GixGjaaANuqXbUAd2pXgpE5dCjnXGLiC19h2rgAIPGWcI7
4B3fvLDc4O2iec+KCRNHAvQ6TUvuyVqzpwl6ZnQZzts5YhVwa2akVCgMF5mM
I842ZkgmiWNdsdpSdeSa2jbUARtAFflql5LuRd0HT4mYOWBFsI5b+enGSlAv
Xw804/54sxqbV2/Ue6D27Nmm/P1Lkr0/1fIc49C2YiEyMvYvb2trb8713GFb
ILS5BN+tUNcf9vmL6AP95HsAPidxXG5cwgqUk70fagR0fyEJyueD/rCXvBki
W6YDfzLYKtzwfM+DAyjfdemZ5IonDRUl3lUKr+rHrdHO60qwMvRm74IwLfKz
5XGrIPy2Pga4gsuxzf0etFZbrHC4cZin4+vyDGSynk/puT/1IHZCGvmeedmg
2Aow7ixQcHIqyqrwCQUkHXd4zQziS4FjhW9x1Cj6N+RQCk8DfA/jx/DeUcQx
Dxq1v2jz88GTa8mVB+SRaOwobgOzcK5KIjc2YQkw77j9VFTWkfG2pTy7DnSa
XSu9LEQ+D67jmvi/DZEft2aoceE3hALhG01Mtf8GYqFB78ARAAA=

-->

</rfc>
