



Domain Name System Operations                                 G. Akiwate
Internet-Draft                                                  T. Pauly
Intended status: Informational                                 Apple Inc
Expires: 27 December 2025                                   25 June 2025


            Service Binding Mapping for Background Requests
           draft-gakiwate-dnsop-svcb-bg-priority-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 client can use an alternative endpoint for
   "background" requests.  By providing this information, clients can
   make informed decisions about which service endpoints to use based on
   their specific applications needs at the 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-bg-priority-
   parameter/draft-gakiwate-dnsop-svcb-bg-priority-parameter.html.
   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-gakiwate-dnsop-svcb-bg-
   priority-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-bg-priority-
   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 27 December 2025                [Page 1]

Internet-Draft  Service Binding Mapping for Background R       June 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 27 December 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 "bg-priority" SvcParamKey . . . . . . . . . . . . . . . .   4
     4.1.  Client Behavior . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Example Use . . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Operational Considerations  . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     6.1.  SVCB Service Parameter  . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

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, server
   deployments may wish clients to interact with a service differently
   depending on the context in which they are operating.  For instance,
   consider a weather application.  When running in the background, the
   application may retrieve data infrequently and can thus tolerate
   higher latency.  In contrast, when an user is actively interacting
   with the application, the same requests now require low-latency



Akiwate & Pauly         Expires 27 December 2025                [Page 2]

Internet-Draft  Service Binding Mapping for Background R       June 2025


   responses from nearby servers.  Traditionally, such use cases are
   handled by provisioning distinct endpoints --- one for "interactive"
   requests and another for "background" requests.  This approach does
   not work in scenarios where a service with a single hostname needs to
   be used for both "background" and "interactive" requests.  Moreover,
   this static partitioning imposes rigid service delineation and
   prevents clients from adapting dynamically.  In practice, a client
   may, based on local context, dynamically determine that a request
   typically considered "interactive" can be fulfilled using a latency-
   tolerant path, thereby improving resource utilization and reducing
   operational cost.

   This document defines a new SvcParamKey, bg-priority (short for
   "background priority"), to enable clients to dynamically discover
   service endpoints suited for latency-tolerant requests.  The presence
   of bg-priority=1 on a service endpoint signals that it is optimized
   for background requests and can be selected as needed by clients.
   This key allows clients to filter down to endpoints that 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 types of application traffic, 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, whereas
   background traffic prioritizes throughput and efficiency over
   immediacy.  Moreover, where in the network environment these demands
   can be relaibly and efficiently met also differ.

   The bg-priority SvcParamKey enables authoritative DNS servers to
   signal these distinctions, thereby allowing clients to route traffic
   intelligently.  This capability is particularly valuable in load-
   balancing resource-constrained scenarios, where providers can
   allocate interactive traffic to low-latency, high-performance servers
   while directing background requests to higher-latency but more cost-
   effective underutilized servers.





Akiwate & Pauly         Expires 27 December 2025                [Page 3]

Internet-Draft  Service Binding Mapping for Background R       June 2025


   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 "bg-priority" SvcParamKey

   The bg-priority SvcParamKey, short for "background priority," is used
   to indicate that a service endpoint described in an SVCB or HTTPS
   record is optimized for background, latency-tolerant traffic.  The
   presentation value for bg-priority SHALL be either 0 or 1.

   A value of 1 indicates that the endpoint is designated for background
   requests, while a value of 0 indicates that the endpoint may be
   optimized for interactive or real-time requests.  If the bg-priority
   paramter is absent, then the client must assumes that the endpoint is
   designated for both background and interactive requests.  The wire
   format for the bg-priority parameter is a single 1-octet value, with
   only the values 0x00 and 0x01 currently defined.

4.1.  Client Behavior

   The bg-priority SvcParamKey in SVCB and HTTPS records indicates that
   the service operator recommends the use of a particular endpoint for
   background, latency-tolerant requests.  Upon receiving RRs containing
   the bg-priority key, clients should treat it as a signal to guide
   endpoint selection based on their current operational context.

   To use SVCB or HTTPS RRs, a client first determines whether the
   current network request is suitable for background handling.  The
   mechanism for making this determination is implementation specific
   and left to the discretion of the client.  For example, a client may
   provide an explicit signalling interface that allows an application
   or user to indicate a given request is background in nature.  The
   client may also rely on the local operational context to infer
   whether background handling is appropriate.

   If the client determines background handling to be appropriate, the
   client filters the RRSet to include only those records with bg-
   priority=1.  If not, the client filters the RRSet to include only
   those records with bg-priority=0.  A record that does not include the
   bg-priority key is considered to be suitable for all traffic types
   and should always be included.

   Once the client filters the SVCB / HTTPS RRs based on this
   designation, it proceeds with the remaining records using standard
   selection logic [SVCB].  If no suitable records remain after
   filtering, SVCB resolution is considered to have failed, and the



Akiwate & Pauly         Expires 27 December 2025                [Page 4]

Internet-Draft  Service Binding Mapping for Background R       June 2025


   client should fallback appropriately.  To avoid unintended resolution
   failures, service operators should ensure that if any service in a
   set contains the bg-priority key, then at least one service exists
   for each bg-priority=0 and bg-priority=1, or else at least one
   service exists without the bg-priority key to catch all traffic.

4.2.  Example Use

   A service that supports endpoints optimized for background i.e.,
   latency-tolerant requests can advertise support to clients using the
   bg-priority SvcParamKey as illustrated below:

   svc.example.com 7200 IN HTTPS 1 . (
           alpn=h2, bg-priority=0 )
   svc.example.com 7200 IN HTTPS 2 background.svc.example.com (
           alpn=h2, bg-priority=1, mandatory=bg-priority )

   In this example, a client that determines a request is suitable for
   background handling filters the SVCB / HTTPS RRs to select only those
   records with bg-priority=1.  In this case, only one RR satisfies the
   constraint, and the client uses the background.svc.example.com
   endpoint despite its higher SvcPriority (i.e., lower preference)
   compared to the other advertised RR.  If a client does not support
   the bg-priority key, the client will ignore it and continue using the
   default endpoint (SvcPriority=1) as before.  The service operator can
   use mandatory=bg-priority for the background designated RR to ensure
   that a client lacking support will skip this RR entirely.

4.3.  Operational Considerations

   If a service operator does not explicitly include bg-priority=0 in
   the default HTTPS RR (as shown in the example above), a client that
   filters for background-eligible endpoints will treat both RRs as
   valid matches.  This is because a record without the bg-priority key
   is considered suitable for all traffic types.  After filtering, the
   client will proceed with standard SVCB selection logic and prefer the
   record with the lowest SvcPriority.  In such cases, the client will
   select the default endpoint, even if an endpoint optimized for
   background requests is available.

   To avoid unintended selection behavior, service operators should be
   cautious when mixing RRs that include bg-priority key with those that
   omit it.  Explicitly setting bg-priority can help ensure more
   predictable client behavior.

   Additionally, partitioning traffic across different service tiers may
   interfere with connection pooling in some client implementations.
   This could lead to increased connection overhead or degraded



Akiwate & Pauly         Expires 27 December 2025                [Page 5]

Internet-Draft  Service Binding Mapping for Background R       June 2025


   performance in scenarios that rely heavily on connection reuse.
   Service operators should evaluate the impact on connection management
   when deploying bg-priority based routing.

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     | Reference |
     |        |             |              | Controller |           |
     +========+=============+==============+============+===========+
     | TBD    | bg-priority | Endpoint is  |            | (this     |
     |        |             | suitable for |            | document) |
     |        |             | background   |            |           |
     |        |             | traffic      |            |           |
     +--------+-------------+--------------+------------+-----------+

                                 Table 1

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>.

Acknowledgments

   Thank you to Ben Schwartz, Ryan Watson, and many others for their
   feedback and suggestions on this document.




Akiwate & Pauly         Expires 27 December 2025                [Page 6]

Internet-Draft  Service Binding Mapping for Background R       June 2025


Authors' Addresses

   Gautam Akiwate
   Apple Inc
   Email: gakiwate@apple.com


   Tommy Pauly
   Apple Inc
   Email: tpauly@apple.com









































Akiwate & Pauly         Expires 27 December 2025                [Page 7]
