<?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.24 (Ruby 3.3.6) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ihlar-scone-masque-mediabitrate-02" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.0 -->
  <front>
    <title abbrev="MASQUE throughput advice capsule">MASQUE extension for signaling throughput advice</title>
    <seriesInfo name="Internet-Draft" value="draft-ihlar-scone-masque-mediabitrate-02"/>
    <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="2025" month="March" day="03"/>
    <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)
  Rate Limit (i)
  [Average Window (i)]
}
]]></artwork>
      <t>The capsule has the following fields:</t>
      <t>Rate Limit: 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>A proxy that intends to rate limit proxied traffic can notify clients using the
THROUGHPUT_ADVICE capsule. Reasons for rate limiting traffic through a proxy
include enforcement of access network policies, proxy resource management and
proxy service differentiation.</t>
      <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="TRONE"/>.</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">THROUGHPUT_ADVICE</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="TRONE">
          <front>
            <title>Transparent Rate Optimization for Network Endpoints (TRONE) 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>
            <author fullname="Matt Joras" initials="M." surname="Joras">
              <organization>Meta</organization>
            </author>
            <author fullname="Marcus Ihlar" initials="L. M." surname="Ihlar">
              <organization>Ericsson</organization>
            </author>
            <date day="3" month="March" year="2025"/>
            <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
   what that rate limit is.

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

<section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>TODO acknowledge.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA7VY23LbRhJ9n6/opV+sLYEb2arEZkVxGImOWCuTCknFlUql
tgZAk5wIwCCYgShGlr/FH7JP3h/bMzPgTZR2U5taukokei7dffr0BY6iSFhl
M+5Q6113/MNVj/jWcmGULmiqKzJqVshMFTOy80rXs3lZW5LpjUq4JWQcV3yz
Obq3hRJZmjrD1kRanulq2SFjUyFSnRQyh9a0klMbqXkmq8gkuuAol+a3Gl+c
KhkrW+Fg9MULYeo4V8bZZZclDvZ7k7eiqPOYq45IsakjcNzA9Np0yFY1C1j2
UsiKJSx8zzHJIqV+Ybkq2NKkkoUpdWVbYqGr6xksL7FvbLFLVimd6jyvCwW7
HRQLZec0YOu2Ui/jnAtrWuKal5CkHUEReYOpsVjccFHDJKL/7WKi4GXrPeQO
/e/dNU6eS5VB7rH6VrGdtnU1cwsz3FTHWMpV9au8/ltA9hE0W0LI2s515czG
QaJpnWUhHO9kldSG+i4efgmXy0L97o3tUK9SiTG68EscTMn9kbYP4bfcbGgn
On/kdmcZ/f1f/5xnvFBF+kc1uGPt65qbY7taRKGrHKdvALdQxXTrSURRRDI2
cDuxQkzmyhCYVzuQyZScqKliQ5IKXtBpoCo9H709ff3i9VcHoLO0YHBBMVNt
OA3BOh0OBr3TSXR1drna++rgcC3uN9LjV8eQIoO0nXMFEGxd8WrXJskMWd0k
2SPpA2cEjJ9OVRKsgQNlpW8VjGl2g9V0PplckuHqhqt2cDpXaZqxEM8c4Sud
1omD9z9A0Fzy/wBB/HkQaAXCf3V+MuetCrZnN8xoHG1syBmZgMU5F36xAw1W
Jzqj0nCd6mjOMoXpgI1/q519mlrIvYITG9UpUhLWrQWqbB2SNLTgLPPfTucD
r1cKTIAWtnnFK+Qvm+W2C96pLlBIrIfIVa8znqpC+efgKgoQuQpkUIOvxhNo
9980GPrfo94PV/1R78z9Hp93Ly7WP0SzY3w+vLo42/zanDwdvnvXG5yFw5DS
jkig5v/knIVVreHlpD8cdC9apByK2xRD+XWQIQjKVd6yYotYSCNSNkmlYjzg
zHenl58/HR3T3d1fQJsXR0ev7++bh1dHXx3jwQUoaNNFtmwegdtSyLJkWblb
JEBHw1FWZsaHwcz1oiAwj4HmX392yPzSoa/jpDw6/qYROId3hCvMdoQes33J
3uEA4iOiR9Ss0dyRP0B6197uTzvPK9y3hF+/QbNmio5evflGhPxPfa9BDxnX
pWt4PqEmmzTrhjQbrzq9EF1KMuWi5xm6UGbOPkUrThiV9ek+b3zGqaCSyTQK
4yUSFELYIHEJGpKxFBJLrNMy1jpjWUQ3MqvBir7lnMbo44nLnpTeKs5SdLeN
4VEwvENvjlptmqwy25WI5aN2iAd2oP1jYGgM2dQHg171J60RY2bwd8y+7NLL
9sv2l6Sn5An9+vgIhHZBWHcr7JGxru02EBTWwNxhkWywnIPXMaNaAUMZZy42
KcjeuA2GeBdpcj4aXn1/fnk1+Uf37Mf+aW8TIoRUFkuyCm6mdRVmOxaZmrKX
wU4Pg8XklAcK6ErNVCGtr7y8CqEvUfuKVpVsggmG3nonQrF6eqtzyl081Vmm
F86i4Dx6+MePH8XTB+8wJ3g9z9UBndAXt5Pvzg4hu+BihnBCKj5/+vxp5Fhw
oXJl16Kfu2gYcsb0HjTRCyf/Rdx7dd7Y5GnTXOwNTNvc2vH0y+WtyuscoUJo
AFec7aSKR9Jd1SSXoyjfogWHjFy3ttDqDgXWwFETKuS1yjTmN7R/UNUwGk4K
+Hd96KySnYPJCG7glr5x/J6rpMm0MAf6nuYYmDgG7WjLVQZmeS2mHYYG77U7
okt3pwwNqluWGTTGKlN26QpHoGGYVVDwcd4XDqcu8/g/cNOjUGirpssGF4OW
uOLkkyxu04ilcW3RQbe53h9cD0zNjBCMwmyYZHXKK599ewLXZZLAb4yAYQYv
NRzCSHTYuAJQdI3tiG4BqENTw+gaVt3c4epfqqZTtBm0ao84sOk3WYRcprKu
Sm3WmZXsvAHEUOzyWa54AdBKrYIaP5sGwzi8HAgVgsu3yVwWs+bSB/X4kJSf
FbcaiQuDmzVyXTmsZnNodX8J/bPSMkGJFwhbsVVEAeYhyAzWIAfu7t5MRsNB
76QfnbUxM/2qmvc1jJf4u5pq7u89L1D5UFns0k0wRqG8ytXQMjwbrldDg+oO
unvbnj1bp7h7ETIPJ1eZpmYrJSGqVOhRDpvWzizr6oNpIZAzhZq2ROJ+2K1R
4fOBfnS1Ht/jMBY38cEKDkR7H2qEtLfoD+xTFxtRnbym5zveHODAXYeeKTAs
aggeObfJv5qftAZbryfeYt+LnTtctcjNkietjPCvde+h8+6HtvZHkFtucMPl
lcX8HF6PQen1PErP3a0HofPRwPXIUYNoy0O6tRDgnHBeZi4zgaiVFq+VXjxi
nynJBnf3RuwTfx/oLXC3cX4M862NDv6HjdkpWn8+uDKKhHaAPBKNrY2bwMyt
LaNQBZuweJi33H4qKqvIONtimVz7wplcF3qRcTrzrkNN+L8MTk9aU8yv7A74
ZJHrnZhi/w3sXbqjsBEAAA==

-->

</rfc>
