Standard Communication with Network Elements R. Tang Internet-Draft Google Intended status: Informational 4 December 2024 Expires: 7 June 2025 CAP Conformance Signal For SCONE draft-rjt-scone-conformance-signal-latest Abstract This document proposes conformance signals to be sent by CAPs when they are able to adapt to bitrate indicated by the SCONE signal so that CSPs stop policing. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://RenjieTang.github.io/conformance-signal/draft-rjt-scone- conformance-signal.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-rjt-scone- conformance-signal/. Discussion of this document takes place on the Standard Communication with Network Elements Working Group mailing list (mailto:scone@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/scone. Subscribe at https://www.ietf.org/mailman/listinfo/scone/. Source for this draft and an issue tracker can be found at https://github.com/RenjieTang/conformance-signal. 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 7 June 2025. 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 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. Introduction 2. Conventions and Definitions 3. Proposals 4. Security Considerations 5. IANA Considerations 6. Normative References Author's Address 1. Introduction The primary objective of SCONE is to facilitate communication between CSPs and CAPs regarding throughput advice. One of the main motivations is the recognition that traffic shapers are expensive and inaccurate, and they should be disabled if possible. A paper (https://static.googleusercontent.com/media/research.google.com/ en//pubs/archive/45411.pdf) was pubished on the prevalance and harmfulness of packet policers specifically. However, the ability for CSPs to unidirectionally send signals to the client does not provide CSPs with assurance to disable them. In addition to determining the format and delivery method for throughput advice, the working group should also establish the conditions under which CSPs SHOULD deactivate their traffic shapers and transition into trust-and-verify mode. This helps CSPs by reducing the costs of traffic shapers and CAPs by reducing the workload of congestion controllers. 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. Proposals The following proposals assume the throughput advice is transmitted from CSPs to CAPs in the format of a QUIC packet. 1. The CSP default marks the 4-tuple flow as conformant when its SCONE packet is received by the QUIC client. The CSP SHOULD not disable traffic shapers until it confirms the QUIC client has acked the SCONE signal. Because the CSP lacks visibility into packets containing ACK frames, it MAY only deduce the QUIC client's receipt of the signal by observing the cessation of SCONE packet retransmissions by the QUIC server. If the CSP gives an unrealistically low throughput advice and the QUIC client decides to not follow, the client SHOULD not ack the SCONE packet. The SCONE protocol SHOULD also specify a limit on the number of SCONE packet retransmissions. On retransmission timeout, the QUIC server MUST not retransmit more SCONE packets, and the CSP SHOULD consider the current flow ineligible for SCONE. 2. The QUIC client signals conformance by echoing back the SCONE packet. Upon accepting the throughput advice, the QUIC client MAY send back the SCONE packet along with its ack packet to the QUIC server. Upon receiving the SCONE packet, the CSP SHOULD drop it and disable traffic shapers. The QUIC client MAY refuse the throughput advice by not sending the SCONE packet back. 4. Security Considerations The transmission of the conformance signal MUST employ the same security protection mechanism utilized for the original SCONE packets. 5. IANA Considerations This document has no IANA actions. 6. 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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Author's Address Renjie Tang Google Email: renjietang27@gmail.com