]> University of Aberdeen

School of Engineering Fraser Noble Building Aberdeen AB24 3UE UK ietf@raghavkejriwal.com

University of Aberdeen

School of Engineering Fraser Noble Building Aberdeen AB24 3UE UK gorry@erg.abdn.ac.uk https://www.erg.abdn.ac.uk

FAU Erlangen-Nürnberg

Computer Science 7 Martensstraße 3 Erlangen 91058 Germany matthias.hofstaetter@fau.de https://www.cs7.tf.fau.de

Web and Internet Transport Standard Communication with Network Elements This document defines qlog events for the Standard Communication with Network Elements (SCONE) protocol. The events record the sending and reception of SCONE packets and changes to throughput advice. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Standard Communication with Network Elements Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction describes a protocol where on-path network elements can communicate their perspective on the maximum sustainable throughput for QUIC flows to endpoints. This throughput advice suggests an upper bound on long-term average throughput, independent of and complementary to real-time congestion control signals. This document defines the qlog namespace and events that record the sending and reception of SCONE packets and changes to throughput advice, allowing for debugging of implementations and reconstruction of the packets received. The event namespace with the identifier scone is defined in . summarises the qlog events described in this document. Overview of SCONE qlog events.

Event Name	Importance	Definition
scone:packet_sent	Core
scone:packet_received	Core
scone:advice_updated	Base
scone:advice_expired	Base

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 when, and only when, they appear in all capitals, as shown here. The event and data structure definitions in this document are expressed in the Concise Data Definition Language and its extensions described in . This document follows the language used in :

• "Throughput advice" refers to the information communicated to endpoints by network elements in the form of a 7-bit rate signal
• A "monitoring period" is the time over which rate signals apply (67 seconds ).

SCONE Rate Signal Data Type A Rate Signal n in the range 0 to 126 maps to a ceiling bitrate of 100,000 * 10^(n/20) bits per second, as defined in . The value 127 carries no throughput advice.

CDDL Description of SCONE Rate Signal types.

Note: The events defined in this document also contain the throughput advice (ceiling bitrate) so that QLOG tools need not implement the mapping. The rate signal is definitive, while the throughput advice is for convenience.

SCONE Event Schema Definition This document describes how the SCONE protocol can be expressed in qlog using the event schema. Per the requirements in , this document registers the scone namespace. The event schema URI is urn:ietf:params:qlog:events:scone.

Draft Event Schema Identification RFC-Editor NOTE:: Please remove this section when this is published as an RFC. Only implementations of the final, published RFC can use the events belonging to the event schema with the URI urn:ietf:params:qlog:events:scone. Until such an RFC exists, implementations MUST NOT identify themselves using this URI. Implementations of draft versions of the event schema MUST append the string "-" and the corresponding draft number to the URI. For example, draft 00 of this document is identified using the URI urn:ietf:params:qlog:events:scone-00. The namespace identifier itself is not affected by this requirement.

SCONE Events SCONE events extend the $ProtocolEventData extension point defined in . Additionally, they allow for direct extensibility by their use of per-event extension points via the $$ CDDL "group socket" syntax, as also described in .

SCONEEventData definition and ProtocolEventData extension

scone:packet_sent Importance: Core The packet_sent event is emitted when an endpoint includes a SCONE packet in a datagram it sends. The event records the rate signal in the sent SCONE packet.

CDDL Description of the SCONEPacketSent Data.

Note: The version field is optional, because it is fully determined by rate_signal: the two SCONE versions differ only in their most significant bit, which is the least significant bit of the Rate Signal (). It uses the QuicVersion type defined in .

scone:packet_received Importance: Core The packet_received event is emitted when an endpoint receives a datagram that begins with a SCONE packet, once the endpoint has processed the coalesced QUIC packets in the datagram and therefore knows whether the SCONE packet is accepted or discarded (). The event records the rate signal carried in the received SCONE packet and the outcome of processing it, regardless of whether the packet is accepted or discarded.

CDDL Description of the SCONEPacketReceived Data.

The reason field MUST be present when outcome is "discarded" and MUST NOT be present when outcome is "accepted".

scone:advice_updated Importance: Base The advice_updated event is emitted by a SCONE-receiving endpoint when the effective throughput advice changes as a result of processing a received SCONE packet or applying the monitoring-period rules defined in . Following the convention of other qlog *_updated events, the event records both the previous and the new effective advice, and an optional trigger field indicates the cause of the change ().

CDDL Description of the SCONEAdviceUpdated Data.

This event could be emitted in the following common cases (non-exhaustive):

• When throughput advice first becomes effective, for example, after processing a SCONE packet carrying a known rate signal. In this case old is absent and trigger is "packet_received".
• Processing a SCONE packet that lowers the effective throughput advice. In this case trigger is "packet_received".
• Advice from a previous monitoring period expires and advice from the current monitoring period becomes effective. In this case trigger is "period_expired".

This event SHOULD NOT be emitted when advice from a previous monitoring period expires, but the advice in the current monitoring period does not change the effective advice; that is, old and new SHOULD differ. Note: This event aligns with an API transition. It might or might not align with the boundary of the 67 second monitoring period. For example, implementations that do not use timers for SCONE monitoring periods could choose to emit this event when the application is next informed of the SCONE advice.

scone:advice_expired Importance: Base The advice_expired event is emitted by a SCONE-receiving endpoint when previously effective SCONE advice expires because no applicable throughput advice was received during the monitoring period, as defined in . This event is emitted only when the end of a monitoring period leaves no effective throughput advice (). If other advice becomes effective at that point, for example advice received during the monitoring period that just ended, the advice_updated event () is emitted instead; the two events are never both emitted for the same transition.

CDDL Description of the SCONEAdviceExpired Data.

Note: For the same reasons as in , this event might or might not align with the boundary of the 67 second monitoring period.

Security Considerations The security and privacy considerations discussed in apply to this document. The events defined in this document record the rate signals and throughput advice that a network applies to the traffic of the logging endpoint. A qlog file containing these events therefore reveals the policy that an access network applied to that endpoint, and can help identify the network or infer the endpoint's subscription, as discussed in . When qlog files are shared beyond the logging endpoint, the data minimization and anonymization guidance in is RECOMMENDED for these fields.

IANA Considerations This document registers a new entry in the "qlog event schema URIs" registry (created in ).

Event schema URI:

urn:ietf:params:qlog:events:scone

Namespace

scone

Event Types

packet_sent, packet_received, advice_updated, advice_expired

Description:

Event definitions related to the SCONE protocol.

Reference:

This Document

Normative References Mozilla Private Octopus Inc. Fastly Meta Ericsson This document describes a protocol where on-path network elements can communicate their perspective on the maximum sustainable throughput for QUIC flows to endpoints. This throughput advice suggests an upper bound on long-term average throughput, independent of and complementary to real-time congestion control signals. Akamai Meta Apple qlog provides extensible structured logging for network protocols, allowing for easy sharing of data that benefits common debug and analysis methods and tooling. This document describes key concepts of qlog: formats, files, traces, events, and extension points. This definition includes the high-level log file schemas, and generic event schemas. Requirements and guidelines for creating protocol- specific event schemas are also presented. All schemas are defined independent of serialization format, allowing logs to be represented in various ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Akamai Meta Apple This document describes a qlog event schema containing concrete qlog event definitions and their metadata for the core QUIC protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. 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. 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.

Change Log RFC-Editor NOTE:: Please remove this section when this is published as an RFC.

• -00 was the first draft
• -01
  • Add Matthias Hofstaetter as an author
  • Added security considerations
  • Moved CDDL comments to above variables to follow other qlog conventions
  • Advice events now follow other conventions (using new and old)
  • Highlighted that advice events may not always align with monitoring period boundaries
  • Changed version field to QuicVersion type and an optional field

Acknowledgments The authors thank the European Space Agency (ESA) for supporting the QUICOPTSAT project, under which an evaluation of SCONE over satellite networks was undertaken.