Expressing Quality of Service Requirements (QoS) in Domain Name System (DNS) Queries

2.2.1. Requirement TLV Encoding

Each TLV expressing a service requirement can be thought of as being binarily encoded as shown in Figure 1.¶

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|     Type      |    Length     |
+---+---+---+---+---+---+---+---+
|  Value (Length Bytes Long)    .
.                               .
.                               .
.................................

• Type:

  4-bit unsigned integer indicating the type of service requirement.¶

  Length:

  4-bit unsigned integer indicating the length of the value associated with the service requirement in bytes. The presence of an explicit length makes it possible to skip unknown / unimplemented service requirements.¶

  Value:

  The value associated with the service requirement.¶

Although the DNS does not constraint the octet values within a label, for ease of use and due to user interface restrictions, label octets are commonly limited to a subset of printing ASCII [RFC0020] character values. Furthermore, for name matching purposes, the DNS does not distinguish between octets having the upper case and lower case codes for an ASCII letter and in some cases the storage of a label in the DNS and/or its later retrieval may change the value of an octet in that label between the values for upper and lower case version of an ASCII letter [RFC4343]. To avoid possible problems with this DNS case insensitivity or possibly problematic byte values such as zero, the TLV or sequence of TLVs is included in the DNS name label in hexadecimal notation. There are more compact encoding that avoid these problems, such as a customization of Bootstring similar to Punycode [RFC3492] or Base32 [RFC4648] but for simplicity and to make the encoding into names more easily readable for debugging and other purposes, hexdecimal was chosen.¶

2.2.2. Requirements Types and Value Encoding

The following types of service requirement are initially defined:¶

Coarse:

A general indication of the most important service being sought encoded as a one byte integer patterned after the IPv4 ToS (Type of Service) value specified in [RFC1349]. (This is "coarse" in contrast with the more precise service requirements defined below.) The following values are defined:¶

0x00

Normal service.¶

0x01

Minimize cost.¶

0x02

Maximize reliability.¶

0x04

Maximize throughput.¶

0x08

Minimize delay.¶

0x10

Minimize jitter.¶

Bandwidth:

The bandwidth requirement is encoded as a float32 (32-bit IEEE floating point format [ieee754] number). The unit is bits per second. If more than one TLV of this type occurs in a DNS name, all but the first (leftmost) are ignored.¶

Delay:

The delay requirement is encoded in 24-bit integer format. The unit is microseconds. If more than one TLV of this type occurs in a DNS name, all but the first (leftmost) are ignored.¶

Jitter:

The jitter (i.e., delay variation) is encoded in 24-bit integer format. The unit is microseconds. If more than one TLV of this type occurs in a DNS name, all but the first (leftmost) are ignored.¶

Loss Rate:

This lost rate (i.e., the percentage of packet loss) is encoded in 24-bit integer format. The basic unit is 0.0000001% (i.e., one packet drop per 1 billion packets), where (2^24 - 2) = 1.6777214% is the largest loss rate defined, 2^24-1 means no loss rate requirement, and 0 means the drop rate should be smaller than 0.0000001%. If more than one TLV of this type occurs in a DNS name, all but the first (leftmost) are ignored.¶

Using IEEE 32-bit floating point for the values when appropriate provides a compact notation that can encode up to approximately 10^38 and down to approximately 10^-38 with 6 to 9 significant digits of precision [ieee754].¶

2.2.3. Complete QoS DNS Names

The on-the-wire encoding of a domain name beginning with a service requirement label would be as shown in Figure 2 below. (In the DNS wire encoding, each label is preceded by a length.)¶

+-------+-------+-----+   +-----+--------------------------------+
|length |prefix |TLV1 |...|TLVn |Encoded Remainder of Domain Name|
+-------+-------+-----+   +-----+--------------------------------+

Alternatively, service requirements could split among a sequence of two or more labels in a DNS name to be queried, as shown in Figure 3.¶

+-------+------+----+   +-------+------+----+-----------------+
|length |prefix|TLV1|...|length |prefix|TLVn|Remainder of Name|
+-------+------+----+   +-------+------+----+-----------------+

The display presentation of a DNS name requesting a coarse QoS requirement for minimum delay for communication with example.com would be as shown in Figure 4¶

                 qs--   Prefix
                    1   TLV Type
                    1   TLV Length
                   08   TLV Value
          example.com   Remainder of domain name

qs--1108.example.com.   Complete domain name

4.2.1. R-LDH Registry

IANA is requested to create a registry on the Domain Name System (DNS) Parameters webpage as follows:¶

       Name: DNS Restricted LDH (R-LDH) Label Prefixes
       Registration Procedure: Expert review.
       Reference: [this document]

       Prefix    Description             Reference
       ------   ---------------------   -----------
        qs--    QoS Requirements        [this document]
        xn--    Internationalization    [RFC5890]

4.2.2. R-LDH Expert Guidance

In reviewing applications for the assignment of an R-LDH prefix, the Expert should keep in mind the following guidance:¶

• The use of labels with the requested prefix must meet the following criteria:¶

  • be documented in an Internet Draft,¶
  • not significantly duplicate the use of any other R-LDH prefix, and¶
  • not require any changes to DNS protocol messages or DNS mechanisms such as the handling of CNAME or DNAME RRs or wildcards.¶
• Assignment of more than one R-LDH for a purpose is prohibited. If it is necessary to distinguish sub-uses under an R-LDH prefix, this should be done by encoding within the R-LDH label after the prefix or by a further label or labels before and/or after the R-LDH label, such as a label beginning with underscore ("_").¶
• Prefixes where the first or second character is any of the digits "0", "1", and "5"or the letters "O", "I", "L", and "S" should not be assigned, due to the possibilities of confusion, unless there are strong reasons to use these characters.¶