Domain Name System Operations G. Akiwate
Internet-Draft T. Pauly
Intended status: Informational Apple Inc
Expires: 1 September 2025 28 February 2025
Service Binding Mapping for Service Levels
draft-gakiwate-dnsop-svcb-sla-parameter-00
Abstract
This document defines a new SvcParamKey for use in Service Binding
(SVCB) and HTTPS DNS resource records which enables authoritative DNS
servers to indicate that a service should be used by clients having
specific service levels or use types, such as "interactive",
"background" or "realtime". By providing this information, clients
can make informed decisions about which service endpoints to use
based on specific applications needs at that time of making
connections.
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://gakiwate.github.io/draft-gakiwate-dnsop-svcb-sla-parameter/
draft-gakiwate-dnsop-svcb-sla-parameter.html. Status information for
this document may be found at https://datatracker.ietf.org/doc/draft-
gakiwate-dnsop-svcb-sla-parameter/.
Discussion of this document takes place on the Domain Name System
Operations mailing list (mailto:dnsop@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/dnsop/. Subscribe at
https://www.ietf.org/mailman/listinfo/dnsop/.
Source for this draft and an issue tracker can be found at
https://github.com/gakiwate/draft-gakiwate-dnsop-svcb-sla-parameter.
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/.
Akiwate & Pauly Expires 1 September 2025 [Page 1]
Internet-Draft Service Binding Mapping for Service Leve February 2025
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 1 September 2025.
Copyright Notice
Copyright (c) 2025 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. The "sla" SvcParamKey . . . . . . . . . . . . . . . . . . . . 3
4.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 4
4.2. Example Use . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6.1. SVCB Service Parameter . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
The SVCB and HTTPS resource records (RRs) provide clients with
instructions to connect to a service while avoiding transient
connections to a suboptimal default server [SVCB]. However, there
are scenarios in which a server deployment might want client
applications to interact differently with the service based on the
specific client needs at the time. Traditionally, the solution to
this problem has been to create separate services --- one for
"interactive" tasks and another for "background" tasks. However,
there are scenarios where a service with a single hostname needs to
be used by both "background" and "interactive" clients.
Akiwate & Pauly Expires 1 September 2025 [Page 2]
Internet-Draft Service Binding Mapping for Service Leve February 2025
The document defines a new SvcParamKey "sla", short for Service Level
Attribute, to provide a standardized way for a client to dynamically
discover different service endpoints offering different service
levels using SVCB / HTTPS RRs. This parameters allows client
applications to filter out which services apply to them at the time
of using DNS answers to establish connections.
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. Motivation
In modern network environments, deployment scenarios often involve
diverse application traffic types, such as interactive video
conferencing, real-time gaming, and background file synchronization,
each with distinct performance requirements. Interactive traffic
typically demands low latency and high responsiveness, while
background traffic prioritizes throughput and efficiency over
immediacy. Moreover, where in the network enviornment these demands
can be relaibly and efficiently met also differ.
The "sla" SvcParamKey enables authoritative DNS servers to signal
these distinctions, thereby allowing clients to route traffic
intelligently. This capability is particularly useful in load-
balancing scenarios, where providers can allocate interactive traffic
to low-latency, high-performance servers while directing background
tasks to cost-effective, lower-performance infrastructure.
Allowing clients explicit control over which service level to use
benefits a range of stakeholders, including service operators, by
improving quality of service (QoS), optimizing resource utilization,
and enhancing end-user experience.
4. The "sla" SvcParamKey
The "sla" SvcParamKey, short for Service Level Attribute, is used to
indicate that a service described in SVCB RR supports a specific
service level use type. A endpoint can support multiple service
levels. To support multiple service level types at different
endpoints, multiple SVCB / HTTPS RRs SHOULD be used.
Akiwate & Pauly Expires 1 September 2025 [Page 3]
Internet-Draft Service Binding Mapping for Service Leve February 2025
The presentation value for "sla" SHALL be a comma-seperated list of
one or more integers (1-octet) indicating the service level use. A
service endpoint may serve more than one service level. A lower
value indicates a more cost-effective, lower-performance endpoint
while a higher value indicates a low-latency, high-performance
endpoint. A sla=0 can be thought of as a endpoint supporting
"background" tasks such as performing backups. A sla=1 can be
thought of as a endpoint supporting "interactive" tasks such sending
messages, while a sla=2 can be thought of as a endpoint supporting
"real-time" tasks such as invoking a voice assistant. This documents
defines three service levels, and restricts the values of sla to 0,
1, or 2. Future documents may choose to extend this number.
The wire format for the "sla" parameter is a sequence of service
levels each denoted by a 1-octet numeric.
4.1. Client Behavior
The "sla" SvcParamKey in the SVCB / HTTPS records indicates that the
domain owner recommends the use a specific endpoint for a specific
service level use type. On receiving RRs with the "sla" SvcParamKey,
clients SHOULD use it as a filter to decide which RRs to use when.
Since this document only defines three service levels, a client
SHOULD ignore any SVCB RRs with an "sla" value greater than 2. It is
possible that certain RRs are never used by some clients.
To use the SVCB / HTTPS RRs, the client first determines its service
level. The client then filters down to only SVCB / HTTPS RRs that
match its own perceived service level. A SVCB / HTTPS RR is
considered to match if any of the "sla" values associated match the
client's service level. A RR without a "sla" value is considered
equivalent to sla=0,1,2 and thus matches all client service levels.
Once the client filters SVCB / HTTPS RRs to ones that offer the
service level it desires, the client proceeds with processing the
remaining SVCB / HTTPS RRs as normal. If no RRs match, SVCB
resolution has failed, and the list of available endpoints is empty.
To prevent this behavior, service operators SHOULD ensure that the
complete set of SVCB RRs contains all "sla" levels; this can be done
either by having each level explicitly in some SVCB RR, or by having
a SVCB RR that does not contain the "sla" parameter.
4.2. Example Use
A service that supports "interactive" and "background" endpoints can
signal support to the client by populating SVCB / HTTPS RRs as so:
Akiwate & Pauly Expires 1 September 2025 [Page 4]
Internet-Draft Service Binding Mapping for Service Leve February 2025
svc.example.com 7200 IN SVCB 1 background.svc.example.com (
alpn=h2, sla=0, mandatory=sla )
svc.example.com 7200 IN SVCB 1 interactive.svc.example.com (
alpn=h2, sla=1,2 )
In the above example, a client that determines it wants a "realtime"
(sla=2) service level will first filter for RRs with an sla value of
2. In this case, only one RR satisfies the constraint and the client
can use interactive.svc.example.com endpoint. The service operator
can also use the mandatory flag for the background service, so that
clients who do not support the "sla" SvcParamKey default to their
endpoint of choice.
A service operator can also have the same service level offered at
multiple service endpoints, as seen in the following example:
svc.example.com 7200 IN SVCB 1 interactive.svc.example.com (
alpn=h2, sla=1 )
svc.example.com 7200 IN SVCB 2 . (
alpn=h2, sla=0,1,2 )
With this additional RR, a client that determines its application has
an "interactive" (sla=1) service level will match both RRs. After
allowing both of these RRs, the client will the proceed to process
the RRs as before. In this case, since the RRs have different
SvcPriority levels, the client will prefer
"interactive.svc.example.com".
5. Security Considerations
TODO: Security considerations
6. IANA Considerations
6.1. SVCB Service Parameter
Once standardized, this document would ask to add the following entry
to the "Service Parameter Keys (SvcParamKeys)" registry.
+========+======+===============+===================+===========+
| Number | Name | Meaning | Change Controller | Reference |
+========+======+===============+===================+===========+
| TBD | sla | Service Level | | (this |
| | | Attribute | | document) |
+--------+------+---------------+-------------------+-----------+
Table 1
Akiwate & Pauly Expires 1 September 2025 [Page 5]
Internet-Draft Service Binding Mapping for Service Leve February 2025
7. 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,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[SVCB] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.
Appendix A. Acknowledgments
Authors' Addresses
Gautam Akiwate
Apple Inc
Email: gakiwate@apple.com
Tommy Pauly
Apple Inc
Email: tpauly@apple.com
Akiwate & Pauly Expires 1 September 2025 [Page 6]