SCONEPRO W. Eddy Internet-Draft A. Tiwari Intended status: Informational A. Frindell Expires: 21 November 2024 Meta 20 May 2024 APIs To Expose SCONEPRO Metadata to Applications draft-eddy-sconepro-api-02 Abstract This document describes API considerations to provide applications with network-supplied information about acceptable network flow rates. Since this information is expected to be signalled from the network within the stack below the application using the SCONEPRO protocol (to be defined by the IETF), it needs to be made accessible to applications in order for them to pick proper video rates, or to otherwise confine the application behavior within network-defined limits. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 21 November 2024. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components Eddy, et al. Expires 21 November 2024 [Page 1] Internet-Draft SCONEPRO APIs May 2024 extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. SCONEPRO Background and Introduction . . . . . . . . . . . . 2 1.1. SCONEPRO API Motivations . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Application Stack Designs . . . . . . . . . . . . . . . . . . 4 4. Potential SCONEPRO Metadata Provided By An API . . . . . . . 6 4.1. Consideration of CTA Standards . . . . . . . . . . . . . 6 5. Potential Browser API Extensions . . . . . . . . . . . . . . 8 5.1. Potential Network Information API Inclusion . . . . . . . 8 5.2. Potential WebTrans API Inclusion . . . . . . . . . . . . 9 5.3. Potential HLS/DASH Support . . . . . . . . . . . . . . . 10 5.4. Other JavaScript API Options . . . . . . . . . . . . . . 11 6. Potential QUIC API Inclusion . . . . . . . . . . . . . . . . 11 6.1. Potential MoQ API Extension . . . . . . . . . . . . . . . 12 7. Potential OS APIs . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Editor's Notes . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 11.1. Normative References . . . . . . . . . . . . . . . . . . 13 11.2. Informative References . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. SCONEPRO Background and Introduction Video traffic is already 70% of all traffic on the Internet and is expected to grow to 80% by 2028. New formats like short form videos have seen tremendous growth in recent years. Both in developed and emerging markets video traffic forms 50-80% of traffic on mobile networks. These growth trends are likely to increase with new populations coming online on mobile-first markets and the observation that unlike text content, video content consumption is not being limited by literacy barriers. On the other hand, the electromagnetic spectrum is a limited resource. In order to ensure that mobile networks continue functioning in a healthy state despite this incredible growth, communication service providers (CSPs) will be required to make infrastructure investments such as more licensed spectrum, cell densification, massive MIMO etc. In order to flatten the rate of growth, CSPs in several markets attempt to identify and throttle video traffic based on user data plans. There are several problems with this kind of throttling: Eddy, et al. Expires 21 November 2024 [Page 2] Internet-Draft SCONEPRO APIs May 2024 1. CSPs can not explicitly measure the effect that throttling has on the end user’s quality of experience (QoE) making this an open loop approach. 2. Traffic detection and throttling for every flow is compute intensive for CSPs. With distributed UPF (user plane function) in 5G mobile networks more nodes in CSP network may need to support traffic detection and throttling. Traffic detection can have inaccuracies and these inaccuracies are expected to increase as the content delivery industry moves towards end-2-end encryption like TLS 1.3 and encrypted client hello (ECH). 3. The unpredictable and non-transparent behavior of traffic throttlers used by CSPs confuse the bandwidth estimation and congestion control protocols being used within end-2-end video delivery sessions between content server and client. This results in poor quality of experience (QoE) for the end user. 4. Content and Application Providers (CAPs) are designing algorithms to detect the presence of such traffic throttlers to counter their detrimental effects. These algorithms have their own inaccuracies in detection and add compute resources on the CAP side. An alternative approach is for CAPs to self-adapt the traffic corresponding to video flows. Since CAPs control the client and server endpoints and can measure end user QoE, they are in a better position to do this self-adaptation in a close loop manner. This alternative approach has already been proven to improve user QoE in production deployments [YouTube]. For this alternative approach to work a standardized secure on-path network interface is required which will enable CSP controlled network elements to signal the desired traffic profile characteristics to the CAP client/server endpoints. The Secure Communication of Network Properties (SCONEPRO) protocol (previously known as SADCDN) is being proposed in the IETF as a working group [SADCDN-Charter] motivated by this alternate approach. 1.1. SCONEPRO API Motivations The general problem statement for SCONEPRO is described in the video optimization requirements document [I-D.joras-sconepro-video-opt-requirements], including the shaping or throttling that CSPs perform. While this problem currently has especially large impact on a few large content providers, solutions for SCONEPRO are generally applicable to any applications that use QUIC [RFC9000] and are subject to throttling within CSP networks. Eddy, et al. Expires 21 November 2024 [Page 3] Internet-Draft SCONEPRO APIs May 2024 General use of SCONEPRO metadata for any applications can be facilitated via an open Application Programming Interface (API) that could be implemented in appropriate QUIC stacks, web browsers, or other libraries. Depending on how the SCONEPRO signaling protocol works (that is to- be-defined by the IETF), the SCONEPRO metadata may be available at various different places in the protocol stack spanning operating system, browser, and application code. This document tries to initially make no assumptions about how the SCONEPRO signalling works, and so considers possibilities to integrate the metadata into APIs provided from OSes, QUIC libraries, web browsers, etc. The purpose of this document is only to demonstrate that general API exposure of the SCONEPRO metadata is achievable without prescribing a specific API solution. It is envisioned that one or more specific API solutions will be defined either through IETF or W3C, to correspond with the SCONEPRO protocol specification. At least in its current form, this document is not intended to be published as an RFC. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Application Stack Designs There are a variety of different application stack designs that are relevant. The main assumption for SCONEPRO in general is that QUIC is used. Applications could, for instance, either use QUIC directly through a linked software library, or applications could be running within a browser, using QUIC indirectly via browser APIs. Specific protocol solutions for SCONEPRO will be defined by the working group. In general, the SCONEPRO network rate-limiting information could be discovered by an end-system in several different ways; potential network signaling approaches are described in other documents (e.g. [I-D.ihlar-masque-sconepro-mediabitrate], [I-D.brw-sconepro-rate-policy-discovery], or others). General classes of information signaling include: Eddy, et al. Expires 21 November 2024 [Page 4] Internet-Draft SCONEPRO APIs May 2024 1. Via the QUIC stack, with the information inserted by an on-path SCONEPRO network element. 2. Via other IP or transport methods below QUIC (e.g. IP extension headers, UDP options, etc.) that might be inserted on the path. 3. Via the OS, with the information coming in network advertisements separate from the transport connection (e.g. via Router Advertisements or DHCP). These methods are not necessarily mutually exclusive. For instance, a DHCP option could indicate that certain classes of applications are throttled at a particular rate, while a SCONEPRO on-path mechanism could also provide more explicit per-connection indications of when throttling is active as well. +================+=============+===================================+ | SCONEPRO | Information | API Definitions | | Solution Type | Visibility | | +================+=============+===================================+ | QUIC-based | QUIC | Specific to each QUIC-library, or | | | library or | browser APIs. | | | web browser | | +----------------+-------------+-----------------------------------+ | IP or UDP- | OS and | Socket API extension may be | | based | possibly | needed, e.g. to expose via socket | | | QUIC | options or other means. For | | | library | mobile apps using native stacks, | | | | OS extensions may be needed. | +----------------+-------------+-----------------------------------+ | Other | OS | Per-OS and/or socket API | | approaches | | extensions | | that are not | | | | on-path or | | | | per-connection | | | +----------------+-------------+-----------------------------------+ Table 1 For solution types that are not QUIC-based, the QUIC implementation could use socket or OS API extensions in order to get the data and convey it up to the applications via its own API. However, QUIC library APIs are not standardized; they differ between common QUIC libraries, and so this document only suggests in a general sense of how the QUIC stack should convey this information to applications. Eddy, et al. Expires 21 November 2024 [Page 5] Internet-Draft SCONEPRO APIs May 2024 The following sections consider first the types of metadata that could be provided, and then how that SCONEPRO metadata might be provided in different cases of APIs including potential: 1. Browser APIs 2. QUIC APIs 3. OS APIs 4. Potential SCONEPRO Metadata Provided By An API There are existing collections of metadata that are available for some types of adaptive rate streaming. Examples include those defined by the CTA-5004 specification [CTA-5004] and CTA-5006 specification [CTA-5006], which standardize JSON objects or HTTP headers conveyed by streaming media clients and servers respectively. These CTA specifications are also expected to be usable by intermediaries. Another example that could be built upon is the proposed flow metadata identifying the DownlinkBitrate [I-D.rwbr-sconepro-flow-metadata]. 4.1. Consideration of CTA Standards Several of the use cases defined by CTA-5006 are relevant, including: * Provide an estimate of the throughput available between an edge server and a player, such that the player can use that information to enrich its decision about which bitrate to select, especially the initial bitrate decision made at the start of playback. * Provide a means for a CDN to instruct all connected players to limit their upper bitrate, in response to an ISP request to reduce congestion on the last-mile network. * Allow a CDN to signal to a player a suggested playback bitrate in order to optimize collective QoE. The "CDN" notion could be replaced with an ISP's on-path throttling device. As a specific example of metadata for SCONEPRO, CTA-5004 allows clients to indicate multiple types of rate metadata that are related to adaptive coded rate selection in the face of throttling. Which of these options are used depends upon the client, but could be one of: Eddy, et al. Expires 21 November 2024 [Page 6] Internet-Draft SCONEPRO APIs May 2024 +============+==========+==========================================+ | CTA Data | Units | CTA Description | +============+==========+==========================================+ | Measured | Integer | The throughput between client and | | Throughput | kilobits | server, as measured by the client and | | | per | MUST be rounded to the nearest 100 kbps. | | | second | This value, however derived, SHOULD be | | | (kbps) | the value that the client is using to | | | | make its next Adaptive Bitrate switching | | | | decision. If the client is connected to | | | | multiple servers concurrently, it must | | | | take care to report only the throughput | | | | measured against the receiving server. | | | | If the client has multiple concurrent | | | | connections to the server, then the | | | | intent is that this value communicates | | | | the aggregate throughput the client sees | | | | across all those connections. | +------------+----------+------------------------------------------+ | Requested | Integer | The requested maximum throughput that | | maximum | kbps | the client considers sufficient for | | throughput | | delivery of the asset. Values MUST be | | | | rounded to the nearest 100 kbps. ... | | | | Note: This can benefit clients by | | | | preventing buffer saturation through | | | | over-delivery ... | +------------+----------+------------------------------------------+ Table 2 The CTA-5006 also allows the server to convey a maximum suggested bitrate. +===========+=========+===========================================+ | CTA Data | Units | CTA Description | +===========+=========+===========================================+ | Max | Integer | The maximum bitrate value that the player | | suggested | kbps | SHOULD play in its Adaptive Bit Rate | | bitrate | | (ABR) ladder. If the player is playing a | | | | bitrate higher than this value, it SHOULD | | | | immediately switch to a bitrate lower | | | | than or equal to this value. | +-----------+---------+-------------------------------------------+ Table 3 There are two high-level approaches that might be viable in reusing CTA data types within an API that supports SCONEPRO: Eddy, et al. Expires 21 November 2024 [Page 7] Internet-Draft SCONEPRO APIs May 2024 1. Append entire CTA-defined objects as optional components of dictionary or other data structures used in APIs, e.g. as a "cta5005" object that would be able to fully convey all of the CTA-defined metadata. 2. Append only selected fields from the CTA specs, reusing the definitions, but only including specific items of interest for SCONEPRO's problem statement, and leaving other CTA-defined metadata to be conveyed through the existing CTA-defined methods. The API can be agnostic to how the data is conveyed between network or on-path SCONEPRO devices and either clients or servers, but the same API can convey the information to the applications, regardless of how the network signaling works. The semantics of the maxium suggested bitrate from the CTA-5006 match the needed semantics most closely, though since it is for an ABR ladder, it should be described carefully to apply the proper bitrate definition that the throttler is using for "on the wire" packets (including header overhead, etc.) versus the pure media payload stream bitrate. 5. Potential Browser API Extensions For browser applications, there are multiple different browser APIs that might be extended to include SCONEPRO metadata; notably including: * W3C Network Information * WebTransport using QUIC * HTTP Live Streaming (HLS) or Dynamic Adaptive Streaming over HTTP (DASH) client libraries * Any Javascript HTTP requests that directly or indirectly use HTTP/3. In either of these cases, the corresponding W3C API definitions are the proper place for actual definition of API extensions, and this document is merely exploring possibilities. 5.1. Potential Network Information API Inclusion The W3C Network Information API [W3C-NetInfo] is supported to some extent by several, but not all, common web browsers today. It provides the possibility for an appliction to determine what underlying connection types or "effective" connection types (e.g. cellular. bluetooth, etc.) may be in use, with a corresponding set of performance parameter estimates including: Eddy, et al. Expires 21 November 2024 [Page 8] Internet-Draft SCONEPRO APIs May 2024 * Round Trip Time (RTT) in milliseconds providing a delay estimate. * downlink in megabits per second providing an effective bandwidth estimate based on recently observed application layer throughput or properties of the underlying connectivity technology. * downlinkMax in megabits per second representing an upper bound on the downlink speed of the first network hop, based on the underlying connectivity technology. The downlink and downlinkMax could be leveraged as places to put the SCONEPRO-discovered rate limit for an application, since anything greater than the SCONEPRO-discovered rate would not be expected to be usable for the application. Alternatively, another field could be added to the NetworkInformation interface in order to specifically provide the SCONEPRO metadata. In any case, a good property of the Network Information API is that an application can hook event handlers to be notified of changes, so that if there are limits that kick-in or are lifted midway into an application's lifetime (e.g. due to some mobility, etc.), the application will be able to be easily notified and adapt. 5.2. Potential WebTrans API Inclusion In the future, WebTransport (WEBTRANS) might be used by SCONEPRO's targeted types of applications, such as browser-based adaptive streaming. The IETF WEBTRANS working group is liasing with W3C as the IETF defines the protocol specification, whereas the W3C defines the API to use it. This case is similar to the IETF RTCWEB and W3C WebRTC WG coordination in the past. The same model of collaboration between IETF and W3C should work for SCONEPRO metadata, and the information provided could be discussed with the WEBTRANS WG in the IETF and notified to the W3C later, either through common participation and/or formal liason statement. The existing WebTrans API definition from W3C includes a "getStats()" method, that is defned in order to asynchronously gather and report statistics for a WebTransport underlying connection. It returns a WebTransportConnectionStats object that is defined as a dictionary, including a number of items such as: * bytesSent * packetsSent * bytesLost Eddy, et al. Expires 21 November 2024 [Page 9] Internet-Draft SCONEPRO APIs May 2024 * packetsLost * bytesReceived * packetsReceived * smoothedRtt * rttVariation * minRtt * WebTransportDatagramStats datagrams * estimatedSendRate The estimatedSendRate is an unsigned long long, in bits per second, calculated by the congestion control algorithm in the user agent. This would be in the "upstream" direction to a CSP, though, rather than the "downstream" from a CSP, so is not useful to a client application in receiving indication of a downstream throttling rate from the network. Since other measurements are already included and the WebTransportConnectionStats is a dictionary, it seems natural to extend it to include additional optional fields, such as an allowed media rate, or other types of fields providing the application information that the underlying host or stack have discovered about the presence of throttling or explicit signaling of allowed media rate on a path. Such extensions might be including at a "MAY" level of conformance statement (rather than "SHALL" as used by all of the currently- defined information elements), as the allowed media rate will not be universally present or even useful for all WebTransport applications. Alternatively, it could be set to a "null" value similar to how the estimatedSendRate is sent when it is unknown by the user agent. 5.3. Potential HLS/DASH Support Client libraries for HLS and DASH will use the underlying Javascript APIs or other underlying APIs, and might rely on them for SCONEPRO metadata support, as discussed in the next subsection. Eddy, et al. Expires 21 November 2024 [Page 10] Internet-Draft SCONEPRO APIs May 2024 5.4. Other JavaScript API Options Typical HTTP adaptive streaming applications using existing browser API options would be ideal to support as directly as possible. There are different ways to transfer HTTP/3 data provided to JavaScript applications that might be applicable. For instance, things like jQuery.ajax() or the "Fetch" API may be used. In this case, there is little or no information about the network path state provided, though there are either jqXHR or Response objects returned that (for instance) allow HTTP headers to be conveyed, and in both cases could be extended to include SCONEPRO metadata. These are returned at the completion of the HTTP transfer, however. It might be more difficult to support more dynamic updates such as providing the metadata to an application mid-transfer so that an application might quickly switch to other media rates for future video segments being pre-fetched. 6. Potential QUIC API Inclusion While there are no standard QUIC APIs, and there are multiple different styles in use, many QUIC implementations include objects in the API that represent the QUIC connections directly, and allow setting callbacks for connection-related events, or allow direct querying of connection state. SCONEPRO metadata could either be supported as a type of callback event, triggered when the metadata is received, or it could be included within other connection state in a polled or interrogated data structure. Other QUIC implementations may leave I/O and management of sockets or other aspects to the application, external to the QUIC library. In this case: 1. If the SCONEPRO metadata is visible as part of the QUIC connection, then it could be provided through the QUIC implementation's API. 2. If the SCONEPRO metadata is visible to the OS or as part of a socket API, it could be provided to the application via the underlying OS or socket abstraction libraries used by applications. Eddy, et al. Expires 21 November 2024 [Page 11] Internet-Draft SCONEPRO APIs May 2024 6.1. Potential MoQ API Extension While Media over QUIC (MoQ) is being defined, it is intended for media streaming over QUIC, which might be applicable to SCONEPRO, in case adaptive rate streams are detected and throttled by CSPs. As yet, there is no standard MoQ API, an MoQ session is currently scoped either to a QUIC connection or a WebTransport session, so it should not be difficult to expose information learned by either transport stack to MoQ applications. 7. Potential OS APIs If SCONEPRO signaling is implemented via QUIC packets, this section is likely to be moot. OS APIs would only be important to consider for SCONEPRO metadata to be exposed in the cases that it is discovered through some lower-level possibilities such as IP extension headers or options, UDP options, DHCP, etc. In applicable cases, the OSes supporting SCONEPRO might extend their sets of socket options to support a getsockopt that permits reading SCONEPRO-received metadata, such as a maximum bit rate. Another possibility would be to allow such information to be retrieved via an ioctl on relevant sockets. Several popular libraries and higher- level languages wrap system calls like getsockopt and ioctl already, and could be extended to include SCONEPRO metadata. A challenge might be that the application would likely need to periodically poll the OS for this information, as there may not be a general way to register a callback or hander for when the OS notices a change. This may be one reason, among others, why supporting SCONEPRO signaling via the QUIC connection itself is more desirable. Another challenge relates to information such as a maximum rate per flow type discovered via DHCP or other means. In that case, it may be difficult for the application to know how the network will actually classify its packets, and so it may not be clear what rate is relevant to assume. This could be another argument favoring QUIC- based signaling, in terms of applications being able to directly make productive use of the information. 8. Security Considerations General SCONEPRO security considerations are discussed in the other documents covering specific network-to-host signaling methods. Existing APIs that expose information about the network path to applications have documented security considerations, especially with regard to user privacy. For instance, there may be concerns that Eddy, et al. Expires 21 November 2024 [Page 12] Internet-Draft SCONEPRO APIs May 2024 such information can be used to assist in fingerprinting users, defeating anonymization, or otherwise exposing more information about the user to the application than the user might explicitly consent to. Such concerns have been document, for example, with regard to the Network Information API. By providing additional information about throttling rate limits within the path, SCONEPRO could increase the amount of information availble on top of that provided by the current APIs. For instance, if the rate information is very fine-grained, it could be useful in fingerprinting. Generally, however, the CSP throttling information is currently very coarse grained, as it is used today. Additionally, the application providers authenticate their users, and their is not an expectation of anonymity in popular platforms today. Beyond this, it is also the case that information provided by SCONEPRO can already be learned by CAP endpoints through various other mechanisms (e.g. the effect of on-path throttlers is clearly visible by observing application traffic packet flows). SCONEPRO simply makes the signaling explicit, rather than requiring it to be observed and inferred separately. 9. IANA Considerations This document has no IANA actions. 10. Editor's Notes This section to be removed prior to any potential publication within an RFC. * The "CSP" term is overloaded, especially with regard to web technology, and might be changed to "carrier", "network operator", etc. in the future, but would need to be consistent with terminology in other SCONEPRO documents. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Eddy, et al. Expires 21 November 2024 [Page 13] Internet-Draft SCONEPRO APIs May 2024 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . 11.2. Informative References [CTA-5004] CTA, "Web Application Video Ecosystem - Common Media Client Data", September 2020. [CTA-5006] CTA, "Common Media Server Data", November 2022. [I-D.brw-sconepro-rate-policy-discovery] Boucadair, M., Wing, D., Reddy.K, T., Rajagopalan, S., and G. S. Mishra, "Discovery of Network Rate-Limit Policies (NRLPs)", Work in Progress, Internet-Draft, draft-brw- sconepro-rate-policy-discovery-01, 7 April 2024, . [I-D.ihlar-masque-sconepro-mediabitrate] Ihlar, M. and M. Kühlewind, "MASQUE extension for signaling media bitrate", Work in Progress, Internet- Draft, draft-ihlar-masque-sconepro-mediabitrate-00, 9 February 2024, . [I-D.joras-sconepro-video-opt-requirements] Joras, M., Tomar, A., Tiwari, A., and A. Frindell, "SCONEPRO Video Optimization Requirements", Work in Progress, Internet-Draft, draft-joras-sconepro-video-opt- requirements-00, 17 May 2024, . [I-D.rwbr-sconepro-flow-metadata] Rajagopalan, S., Wing, D., Boucadair, M., and T. Reddy.K, "Flow Metadata for Collaborative Host/Network Signaling", Work in Progress, Internet-Draft, draft-rwbr-sconepro- flow-metadata-01, 26 April 2024, . Eddy, et al. Expires 21 November 2024 [Page 14] Internet-Draft SCONEPRO APIs May 2024 [SADCDN-Charter] "SADCDN Working Group Charter", 14 May 2024, . [W3C-NetInfo] W3C, "The Network Information API", 11 May 2020, . [YouTube] YouTube, "YouTube Plan Aware Streaming", 21 March 2024, . Acknowledgments This document represents collaboration and inputs from others, including: * Anoop Tomar * Matt Joras * Bryan Tan Additional, helpful critique and comments were provided by: * Lucas Pardue Authors' Addresses Wesley Eddy Meta Email: wesleyeddy@meta.com Abhishek Tiwari Meta Email: atiwari@meta.com Alan Frindell Meta Email: afrind@meta.com Eddy, et al. Expires 21 November 2024 [Page 15]