RFC 9274

A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol

📅 published July 2022, from ietf

RFC 9274: A Cost Mode Registry for the Application-Layer Traffic Optimization (ALTO) Protocol 🦋

okay bestie, this one is from the IETF (the Internet Engineering Task Force, the crew that writes the rules for how the internet talks to itself 💅). It's a Standards Track doc, so it's official-official, and it came out in July 2022 (ISSN 2070-1721) 📅. The authors are M. Boucadair from Orange and Q. Wu from Huawei 🫶. It updates RFC 7285, which is the main ALTO protocol spec, so this doc is basically a glow-up patch for it ✨. It doesn't obsolete anything.

Abstract ✨

okay so this doc creates a brand new IANA registry 🗂️ for tracking the cost modes that ALTO supports. It also relaxes a constraint that the ALTO spec put on which cost mode values are allowed, so it's giving flexibility 💖.

This document updates RFC 7285.

Status of This Memo

This is an Internet Standards Track document.

It's a product of the IETF, and it represents the consensus of the IETF community 🤝. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 📚.

For the current status of this document, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc9274 🔗.

Copyright (c) 2022 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. Please actually read these, because they spell out your rights and restrictions for 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 they come without warranty as described in the Revised BSD License ⚠️.

Table of Contents 🧚

1.  Introduction
2.  Terminology
3.  Updates to RFC 7285
  3.1.  Updates to Section 6.1.2 of RFC 7285
  3.2.  Updates to Section 10.5 of RFC 7285
4.  Backward Compatibility Considerations
5.  IANA Considerations
6.  Security Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 💅

okay so the cost mode attribute tells you how costs should be interpreted when they're communicated, as described in "Application-Layer Traffic Optimization (ALTO) Protocol" [RFC7285]. The base spec only has a provision for two modes 👯:

  • numerical: the returned costs can have numerical operations performed on them (like normalization). See Section 6.1.2.1 of [RFC7285] 🔢.
  • ordinal: the cost values in a cost map are a ranking (relative to all the other values in that cost map), not actual costs. See Section 6.1.2.2 of [RFC7285] 🏅.

Some deployments need more cost modes (for example, [ALTO-PV]) 🌈. So to make room for those use cases, this doc relaxes the constraint the base ALTO spec put on allowed cost modes (Section 3), and it creates a new ALTO registry to track new cost modes (Section 5) 🗂️.

The mechanisms defined in [RFC7285] are used to advertise support for new cost modes for specific cost metrics. Check out Section 4 for more details 👀.

2. Terminology 📖

okay the key words in this document (the BCP 14 ones) are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". They're only interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they show up in all capitals, exactly like that 🔠. Lowercase versions are just regular words, bestie 💕.

This document makes use of the terms defined in [RFC7285] ✨.

3. Updates to RFC 7285 🛠️

this is where the actual glow-up happens, so pay attention 👑. Each subsection quotes the old text, then the new text that replaces it.

3.1. Updates to Section 6.1.2 of RFC 7285

This document updates Section 6.1.2 of [RFC7285] as follows:

OLD:

   The cost mode attribute indicates how costs should be interpreted.
   Specifically, the cost mode attribute indicates whether returned
   costs should be interpreted as numerical values or ordinal
   rankings.

   It is important to communicate such information to ALTO clients,
   as certain operations may not be valid on certain costs returned
   by an ALTO server.  For example, it is possible for an ALTO server
   to return a set of IP addresses with costs indicating a ranking of
   the IP addresses.  Arithmetic operations that would make sense for
   numerical values, do not make sense for ordinal rankings.  ALTO
   clients may handle such costs differently.

   Cost modes are indicated in protocol messages as strings.

NEW:

   The cost mode attribute indicates how costs should be interpreted.
   Two cost modes (numerical values and ordinal rankings) are
   defined, but additional cost modes can be defined in the future.

   It is important to communicate such information to ALTO clients,
   as certain operations may not be valid on certain costs returned
   by an ALTO server.  For example, it is possible for an ALTO server
   to return a set of IP addresses with costs indicating a ranking of
   the IP addresses.  Arithmetic operations that would make sense for
   numerical values, do not make sense for ordinal rankings.  ALTO
   clients may handle such costs differently.

   Cost modes are indicated in protocol messages as strings.

   For any future documents that defines a new cost mode, indicating
   whether that new cost mode applies to all or a subset of cost
   metrics is strongly recommended.  This recommendation is meant to
   prevent nondeterministic behaviors that may result in presenting a
   cost mode with a specific metric, while such an association does
   not make sense or can't be unambiguously interpreted by ALTO
   implementations.

   If the definition of a cost mode does not indicate whether that
   cost mode applies to a subset of cost metrics, ALTO
   implementations MUST be prepared to accept that cost mode for any
   cost metric.

the big new bit is that future cost mode docs should say whether their new mode applies to all cost metrics or just a subset 🎯. Doing that helps stop nondeterministic behaviour, where a cost mode gets paired with a metric that doesn't make sense 🙃. And if a cost mode definition doesn't say, ALTO implementations MUST be ready to accept that cost mode for any cost metric 💜.

3.2. Updates to Section 10.5 of RFC 7285

This document updates Section 10.5 of [RFC7285] as follows:

OLD:

   A cost mode is encoded as a string.  The string MUST have a value
   of either "numerical" or "ordinal".

NEW:

   A cost mode is encoded as a string.  The string MUST be no more
   than 32 characters, and it MUST NOT contain characters other than
   US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A,
   and U+0061-U+007A), the hyphen-minus ('-', U+002D), the colon
   (':', U+003A), or the low line ('_', U+005F).  Cost modes reserved
   for Private Use are prefixed with "priv:" (Section 5).  Otherwise,
   the cost mode MUST have a value that is listed in the registry
   created in Section 5 of [RFC9274].

okay so the old rule was super strict: the string just had to be numerical or ordinal 🙅‍♀️. The new rule is way more chill but still has rules 💅. A cost mode string can be up to 32 characters, and it can only use US-ASCII letters and digits, plus the hyphen-minus (-), the colon (:), and the low line (_) ✏️. Cost modes reserved for Private Use get the priv: prefix 🔒. Anything else has to be listed in the registry created in Section 5 of [RFC9274] 📋.

part 1 done bestie!! 🌈 Next up in part 2: Section 4 (Backward Compatibility Considerations), Section 5 (IANA Considerations), Section 6 (Security Considerations), the References, and the Acknowledgements and Authors' Addresses 🧚💖

7.2. Informative References 📚✨

okay so the informative refs are the "nice to know" pile, and there are two of them 🫶

[ALTO] is the IANA page for the Application-Layer Traffic Optimization (ALTO) Protocol, and you can find it at https://www.iana.org/assignments/alto-protocol/ 🦋

[ALTO-PV] is "An ALTO Extension: Path Vector" by K. Gao, Y. Lee, S. Randriamasy, Y. R. Yang, and J. J. Zhang. It's a Work in Progress Internet-Draft, draft-ietf-alto-path-vector-25, dated 20 March 2022, and the link is https://datatracker.ietf.org/doc/html/draft-ietf-alto-path-vector-25 💜

Acknowledgements 🎀

bestie, the people who helped make this happen deserve a shoutout 😭🫶

Huge thanks to Benjamin Kaduk, who spotted the issue while reviewing [ALTO-PV]. Icon behaviour 👑

Thanks also to Adrian Farrel, Dhruv Dhody, Luis Miguel Contreras Murillo, Sabine Randriamasy, and Qiao Xiang for the review and comments 💅

Special thanks to Kai Gao for shepherding the document 🌸

Thanks to Martin Duke for the AD review 🧚

Thanks to Roni Even for the gen-art review, Jaime Jimenez for the artart review, and Stephen Farrell for the secdir review 🍓

And last but DEFINITELY not least, thanks to Robert Wilton, Lars Eggert, Francesca Palombini, Roman Danyliw, Paul Wouters, and Murray Kucherawy for the IESG review. ilysm 🌈💖

Authors' Addresses 🦋

Here's where you can find the two people who wrote this, lowkey the real MVPs 💅

Mohamed Boucadair
Orange
35000 Rennes
France
Email: mohamed.boucadair@orange.com


Qin Wu
Huawei
Yuhua District
101 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: bill.wu@huawei.com
📦 where this page comes from