| Internet-Draft | CAP Conformance Signal For SCONE | December 2024 |
| Tang | Expires 7 June 2025 | [Page] |
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.¶
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.¶
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 (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.¶
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 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.¶
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.¶
The following proposals assume the throughput advice is transmitted from CSPs to CAPs in the format of a QUIC packet.¶
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.¶
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.¶
The transmission of the conformance signal MUST employ the same security protection mechanism utilized for the original SCONE packets.¶
This document has no IANA actions.¶