Standard Communication with Network Elements R. Tang Internet-Draft Google Intended status: Informational 4 December 2024 Expires: 7 June 2025 Client Conformance Signal for SCONE draft-rjt-scone-conformance-signal-00 Abstract This document proposes conformance signals to be sent by QUIC clients to indicate whether they are able to adapt to the bitrate indicated by the SCONE signal, so that communication service providers MAY 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://rjt- ietf.github.io/SCONE/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/rjt-ietf/SCONE. 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." Tang Expires 7 June 2025 [Page 1] Internet-Draft Client Conformance Signal for SCONE December 2024 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 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Proposals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Implicit Signal . . . . . . . . . . . . . . . . . . . . . 3 3.2. Explicit Signal . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Normative References . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction As outlined in the charter, the primary objective of SCONE is to facilitate the communication of throughput suggestions between traffic throttling network elements and QUIC endpoints. One of the main motivations is the desire to disable traffic shapers and policers when possible. However, the ability for communication service providers (CSPs) to unidirectionally send throughput advice signals to QUIC endpoints does not provide the CSPs with information on whether the QUIC endpoints are conforming to the suggested throughput. As a result, the CSP has no assurance to disable throttling. A paper (https://static.googleusercontent.com/media/research.google.com/ en//pubs/archive/45411.pdf) was published on the prevalence and harmfulness of throughput throttling. From an ISP's perspective, it requires additional machine resources to run traffic shapers and policers, and dropped packets result in waste of network bandwidth. From a QUIC server's perspective, retransmissions incur extra costs Tang Expires 7 June 2025 [Page 2] Internet-Draft Client Conformance Signal for SCONE December 2024 to server resources. From a QUIC client's perspective, packet loss harms the user's quality of experience. Although communicated throughput advice SHOULD prevent packets from being dropped by traffic policers most of the time, short-duration bursts are common within certain types of network connections, causing the problems mentioned above. 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, where average throughputs are sampled to make sure the content and application providers (CAPs) are behaving as expected. 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 network elements to QUIC clients in the format of a TRAIN (https://datatracker.ietf.org/doc/draft-thomson-scone-train- protocol/) packet. As the technical design of SCONE evolves, the proposals in this draft MAY evolve as well. If the reasoning in this draft is well received, conformance signals MAY also be integrated into the SCONE technical solution proposal drafts. 3.1. Implicit Signal The traffic throttling network element SHOULD default marks the 4-tuple flow as conformant when its TRAIN packet is received by the QUIC client. The network element SHOULD not disable traffic shapers until it confirms the QUIC client has acked the SCONE signal. Since the network element lacks visibility into QUIC packets containing ACK frames, it MAY only deduce the QUIC client's receipt of the signal by observing the cessation of TRAIN packet retransmissions by the QUIC server. In the case where the network element gives an unrealistically low throughput advice and the QUIC client decides to not conform, the client SHOULD not ack the TRAIN packets. The SCONE protocol SHOULD also specify a limit on the number of SCONE packet retransmissions. When the retransmission limit is reached, the QUIC server MUST not retransmit any more TRAIN packets, and the network element SHOULD consider the current flow ineligible for SCONE and Tang Expires 7 June 2025 [Page 3] Internet-Draft Client Conformance Signal for SCONE December 2024 keeps its throttling device on. 3.2. Explicit Signal The QUIC client SHOULD signal conformance by echoing back the TRAIN packet. Upon receiving the TRAIN packet, if the decision is to conform, the QUIC client SHOULD send back the same TRAIN packet along with its ACKs to the QUIC server. When the client-initated TRAIN packet reaches the network element, it SHOULD be dropped and throttling devices SHOULD be disabled. In the case where the QUIC client decides to not conform, it SHOULD NOT echo the TRAIN packet back. Since the network element never receives the conformance signal, it keeps its throttling devices on. 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: rjt.ietf@gmail.com Tang Expires 7 June 2025 [Page 4]