]> Cisco

Canada fluffy@iii.ca

Cisco

USA snandaku@cisco.com

transport realtime quicr Real time systems often run into the problems where the network bandwidth for logging is shared with the real time media and impacts the media quality. There is a desire to transport the logging data at an appropriate priority level over the same transport as the media. This allows the logging data to take advantage of times when the media bitrate is below the peak rate while not impacting the peak rate available for media. This document specifies how to send syslog type information over Media over QUIC Transport (MOQT) . Discussion Venues Discussion of this document takes place on the Media Over QUIC Working Group mailing list (moq@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction Each device that logs publishes its log messages as MOQT objects. The devices or systems publishing the logs are referred to as resources and have a unique ResourceID. Track names are set up such that a subscriber can subscribe to the logs of each resource separately, and can pick the log severity levels it wants. A log collector subscribes to the logs of the resources it wishes to monitor, and MOQT relays cache logs so that they can be retrieved later, when needed. The data model used is consistent with the OpenTelemetry logs data model and a superset of the data model for logging. specifies a layered architecture that provides for support of any number of transport layer mappings for transmitting syslog messages. This document describes the MOQT transport mapping for the syslog protocol.

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.

Architecture Overview This section describes two deployment models for logging over MOQT. In both, resources publish logs as MOQT tracks (see ) to a relay, and log collectors subscribe to them via relays. Relays cache logs so that collectors can retrieve them later.

Logs Sharing a Session with Media In this model, an endpoint such as a realtime conferencing client publishes its media and its logs over the same MOQT session, and thus the same QUIC connection, to its ingress relay. Media and logs share the congestion control context of that connection, and MOQT priorities (see ) determine what is sent when the available bandwidth is limited. At the relay, media and logs are forwarded to different destinations: media to the other participants, and logs to a log collector, possibly through other relays. | Participants | | +--------+ |==================>| | +--------------+ | | Media | | | Relay | | +--------+ | logs | | logs +--------------+ | | Logs | |==================>| (cache) |-------->| Log | | +--------+ | (pri 128..240) | | | Collector | +------------+ +---------+ +--------------+ ]]> When congestion occurs on the endpoint's connection, log messages of the higher severity levels are the first to be delayed and, with OBJECT_DELIVERY_TIMEOUT, dropped, while media is unaffected. The relay continues to cache what it has received, and a collector can retrieve logs for a time window of interest later (see ).

Logs as the Primary Data In this model, the endpoints, such as servers, network devices or sensors, send logs as their main data over MOQT. Each endpoint publishes its log tracks to a relay, which may aggregate many endpoints, and one or more log collectors subscribe to them. | Relay |------>| Relay |---->| Log | +------------+ | (cache) | | (cache) | | Collector | +---------+ +---------+ +-----------+ +------------+ ^ | | Endpoint N |---logs----+ | +-----------+ +------------+ +--------->| Dashboard | +-----------+ ]]> Collectors discover endpoints and subscribe to the severity levels of interest (see ), while the remaining levels stay in relay caches until needed (see ).

Resource ID Each Resource that creates logs has a unique ResourceID. This is created by taking the MAC address of the primary network interface in binary, computing the SHA-1 hash of it, then truncating to lower 64 bits. Note that SHA-1 does not provide any security properties here; it is just a hash that is widely implemented in hardware. If this is not possible, any other random stable 64-bit identifier MAY be used. The advantage of using a MAC address is that many other management systems use this address and using it makes it easier to correlate with other systems. The disadvantage is that it reveals the MAC address. When carried in MOQT names, the ResourceID is encoded as exactly 16 lowercase hexadecimal ASCII characters.

Logs and MOQT

Track Naming Each resource publishes its logs under the Track Namespace consisting of the following three Track Namespace Fields, each encoded as ASCII: ) ]]> The Track Namespace Prefix ("logs.moq.arpa", "v1") is common to all resources, which allows a collector to discover all resources (see ). Within a resource's namespace there is one track per severity level. The Track Name is a single ASCII digit identifying the severity of the log messages it carries: Severity levels

Severity	Track Name	Default Publisher Priority
Emergency	0	128
Alert	1	144
Critical	2	160
Error	3	176
Warning	4	192
Notice	5	208
Informational	6	224
Debug	7	240

In this document, "lower levels" refers to Emergency (0) towards Error (3), and "higher levels" to Warning (4) towards Debug (7). Using the serialization format in , the Informational track of the resource with ResourceID 8f2c4a1b0e9d7c63 is rendered as:

Groups and Objects Each group in a log track holds the log messages produced by the resource during one second. The Group ID is the start of that second, in seconds since the UNIX Epoch (00:00:00 UTC on 1 January 1970). This satisfies the requirement that Group IDs increase with time () and allows subscribers to express time ranges directly as Location filters (see ). Each log message is one object, carrying a Log Record (). Object IDs start at 0 in each group and increase by one for each log message in the order they are produced. Each object is self-contained, so a subscriber can use any object without other objects of the group. All objects of a group MUST be sent in a single subgroup with Subgroup ID 0. The publisher sends each object as soon as the log message is produced, keeping the subgroup open until the end of the second. The publisher MUST then end the group with an object with the End of Group Object Status () and an Object ID one greater than the last log message, and close the subgroup. The Datagram delivery mode MUST NOT be used. Seconds without log messages have no group. The publisher MUST include the Prior Group ID Gap Object Property () on the first object of each group, set to the number of seconds since the previous group minus one, except on the first group it publishes after starting, when the previous group is not known. This allows relays and fetches to know that the intervening groups will never exist, rather than leaving them in the unknown state. Object IDs within a group are contiguous, so the Prior Object ID Gap Object Property is not used.

Log Record The payload of each log message object is a Log Record, encoded as follows using the notation of and the variable-length integer (vi64) of .

Log Record

• Timestamp Offset: The nanoseconds to add to the Group ID, in seconds, to obtain the time the log message was produced. The value is less than 1000000000.
• Facility: The facility as defined in , from 0 to 23.
• Hostname, App Name, Proc ID, Msg ID: The HOSTNAME, APP-NAME, PROCID and MSGID fields as defined in , as ASCII strings. An empty field corresponds to the NILVALUE.
• Message: The MSG as defined in , as a UTF-8 string. This is the Body in .
• Attribute: A key-value pair, where Key and Value are UTF-8 strings. Attributes carry structured data. The keys "TraceID" and "SpanID", defined in , and "InstrumentationScope" have the meaning defined in . Other attributes map to Attributes in .

The severity of a log message is given by the track that carries it and is not repeated in the Log Record. Receivers MUST ignore any bytes following the fields defined in this document, to allow future extension.

Track Properties Publishers SHOULD include the following Track Properties () on each log track:

• DEFAULT_PUBLISHER_PRIORITY: see .
• DEFAULT_PUBLISHER_GROUP_ORDER: Ascending (0x1), so that collectors receive log messages in order.
• MAX_CACHE_DURATION: the retention time for which relays may serve cached log messages. Lower levels are typically retained longer than higher levels.
• OBJECT_DELIVERY_TIMEOUT: for higher levels, a timeout after which a stale log message is dropped rather than delivered late.

Priorities Logs are expected to yield to the primary application under congestion. The publisher SHOULD set the DEFAULT_PUBLISHER_PRIORITY Track Property of each log track to the value in , or another value that keeps lower levels ahead of higher levels. These values are in the lower priority half of the range, behind the MOQT default of 128 typically used for media, with Emergency at par with the default. Subscribers can adjust the relative importance of logs against other subscriptions in the session using the SUBSCRIBER_PRIORITY parameter, which is considered before publisher priority.

Discovery and Subscription A collector discovers resources by sending SUBSCRIBE_NAMESPACE with the Track Namespace Prefix ("logs.moq.arpa", "v1"). The relay responds with a NAMESPACE message for each resource namespace, and NAMESPACE_DONE when a resource stops publishing. For each discovered resource, the collector subscribes by name to the tracks of the levels it wants to receive continuously, for example levels 0 to 3. Resources that start publishing later are learned from subsequent NAMESPACE messages. Tracks of other levels are not subscribed to and remain available from the relay cache via FETCH (see ). Collectors can further select log messages using MOQT Object Property range filters () on application-defined Object Properties, which are outside the scope of this document. Range Filters are only available when the relay advertises a non-zero MAX_FILTER_RANGES, so collectors MUST be able to process unfiltered tracks.

Retrieval of Past Logs Since Group IDs are times in seconds, a time range of logs corresponds directly to a range of Locations:

• A collector retrieves past log messages for a time window [T1, T2] by sending FETCH with a Location filter from {T1, 0} to {T2, max}. The request is served from the relay cache, subject to MAX_CACHE_DURATION.
• A collector that wants recent history followed by live log messages sends a SUBSCRIBE with a Location filter starting at the Next Object, together with FILL_PARAMETERS whose Location filter selects the starting point of the history. The relay delivers the history on a fill fetch stream and live log messages on the subscription, without gaps or duplicates ().
• A collector that only needs live log messages subscribes with a Location filter starting at the Next Object.

This enables "just in time" collection of logs: resources publish all levels to a nearby relay, while collectors subscribe to the lower levels and fetch the higher levels for the time windows of interest, for example around an error.

Examples On 31 December 1999, a server publishes two Informational log messages in the second starting at 23:59:59 UTC (Group 946684799), and one more five seconds later (Group 946684805).

Log track example

Use with MSF An MOQT Streaming Format (MSF) catalog can direct a client to publish logs using a publishTracks entry with a packaging of "moqlog" and a role of "log". In such an entry:

• namespace is the Track Namespace of rendered using , with %resourceId% as a placeholder for the client's ResourceID: logs.2emoq.2earpa-v1-%resourceId%.
• name is the track for a severity level (). A catalog can include one entry per level it wants the client to publish.

IANA Considerations This document has no IANA actions.

Security Considerations TODO

References Normative References Cisco Google Google Meta This document defines Media over QUIC Transport (MOQT), a publish/ subscribe protocol that runs over QUIC and WebTransport. MOQT leverages the features of these transports, such as streams, datagrams, priorities, and partial reliability. MOQT operates both point-to-point and through intermediate relays, enabling scalable low-latency delivery. Despite its name, MOQT is media agnostic and can be used for a wide range of use cases. This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. [STANDARDS-TRACK] 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. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. Informative References Akamai Cisco This document specifies the MOQT Streaming Format, designed to operate on Media Over QUIC Transport.

Changes from the -03 Version

• Aligned with draft-ietf-moq-transport-22.
• Added an Architecture Overview describing logs sharing a session with media, and logs as the primary data.
• Track Namespace is now the tuple ("logs.moq.arpa", "v1", resourceID), replacing the moq:// URL form, and the Track Name is the severity level as an ASCII digit.
• Each group holds the log messages of one second, sent on a single subgroup and ended with an End of Group object, instead of one group per log message.
• Log Records use a binary encoding following the MOQT notation instead of JSON, with timestamps relative to the Group ID.
• Added the use of Prior Group ID Gap, Track Properties for priority, group order, caching and delivery timeouts, SUBSCRIBE_NAMESPACE for discovery, and FETCH and fill for time range retrieval.
• Added use with MSF.

Acknowledgments Thanks to Tim Evens for contributions and suggestions to this specification.