Throughput Advice Object for SCONE

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

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 6 June 2025.¶

Copyright Notice

Copyright (c) 2024 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

Connectivity services are provided by networks to customers via dedicated terminating points, such as customer edges (CEs) or User Equipment (UE). To facilitate data transfer via the provider network, it is assumed that appropriate setup is provisioned over the links that connect customer terminating points and a provider network (usually via a Provider Edge (PE)), successfully allowing data exchange over these links. The required setup is referred to in this document as network attachments, while the underlying link is referred to as "bearers".¶

The bearer can be a physical or logical link that connects a customer device to a provider network. A bearer can be a wireless or wired link. The same or multiple bearer technologies can be used to establish the bearer (e.g., WLAN or cellular) to graft customer terminating points to a network.¶

Figure 1 shows an example of a network that connects CEs and hosts (UE, for example). These CEs are servicing other (internal) hosts. The identification of these hosts is hidden from the network. The policies enforced at the network for a network attachment are per-subscriber, not per-host. Typically, if a CE is provided with a /56 IPv6 prefix, policies are enforced in the network on that /56 not the individual /64s that will be used by internal hosts. A customer terminating point may be serviced with one (e.g., UE#1, CE#1, and CE#3) or multiple network attachments (e.g., CE#2). For the sake of simplicity, Figure 1 does not show the interconnection with other networks or multi-homed CEs.¶

Customer terminating points are provided with a set of information (e.g., IP address/prefix) to successfully be able to send and receive traffic over a network attachment. The required set of parameters to provision a network attachment is a function of the connectivity service offering. For example, a very limited set of parameters is required for mass-market service offering while a more elaborated set is required for Enterprise services. A comprehensive list of provisioning parameters that are available on the PE-side of a network attachment is specified in [I-D.ietf-opsawg-ntw-attachment-circuit].¶

As discussed, e.g., in Section 4.2 of [RFC7567], packet dropping by network devices occurs mainly to protect the network (e.g., congestion-unresponsive flows) and also to ensure fairness over a shared link. These policies may be intentional policies (e.g., enforced as part of the activation of the network attachment and typically agreed upon service subscription) or be reactive policies (e.g., enforced temporarily to manage an overload or during a DDoS attack mitigation). Rate-limits are usually configured in (ingress) nodes. These rate-limits can be shared with customers when subscribing to a connectivity service (e.g., "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery" [RFC8466]).¶

Section 5 defines a set of parameters that can be used by networks to share the rate-limit policies applied on a network attachment: Throughput Advice. The set of parameters are independent of the address family.¶

This document does not assume nor preclude any specific signaling protocol to share the throughput advices. These parameters are independent of the channel that is used by hosts to discover such policies.¶

Whether host-to-network, network-to-host, or both policies are included in throughput advice is deployment specific. All these combinations are supported in this document.¶

Also, one or more throughput advice instances may be returned for a given traffic direction. Examples of such instances are discussed in Section 6.¶

Sample uses of the advice by applications are listed in Section 7.¶

As one can infer from the name, a throughput advice is advisory in nature. The advice is provided solely as a hint.¶

In order to ease mapping with specific signaling mechanisms, allow for future extensions, and ensure consistent use of the advice, a new IANA registry is created in Section 9.¶

2. What's Out?

This document does not make any assumption about:¶

• The type of network (fixed, cellular, etc.) that terminates a network attachment.¶

• The services or applications that are delivered over a network attachment. Whether one or multiple services are bound to the same network attachment is deployment specific.¶

• How the throughput advice is computed/set.¶

• The protocol machinery for validating, refreshing, detecting stale, and flushing out received advices.¶

• How applications running over a host can learn the bitrates associated with a network attachment. Typically, this can be achieved by invoking a dedicated API. However, the exact details of the API(s) is OS-specific and, thus, out of scope of this document.¶

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

This document makes use of the following term:¶

Rate-limit:

Used as a generic term to refer to a policy to restrict the maximum bitrate over a network attachment.¶

It can be used with or without any traffic classification.¶

A rate-limit can involve limiting the rate and/or burst size.¶

4. Sample Deployment Cases

Some deployment use cases for throughput advice discovery are provided below:¶

Adaptive Application Behavior:

Discovery of intentional policy applied on network attachments when such information is not made available during the service activation or when network upgrades are performed. Adaptive applications will use the information to adjust their behavior.¶

Concretely, applications are supposed to have access to all throughput advice instances and would, thus, adjust their behavior as a function of the parameters indicated in a throughput policy.¶

Likewise, a host with multiple network attachments may use the discovered throughput advice instances over each network attachment to decide how to distribute its flows over these network attachments (prefer a network attachment to place an application session, migrate connection, etc.). That's said, this document does not make any recommendation about how a receiving host uses the discovered policy.¶

Network Assisted Offload:

A network may advertize a throughput advice when it is overloaded, including when it is under attack. The rate-limit policy is basically a reactive policy that is meant to adjust the behavior of connected hosts to better control the load during these exceptional events (issue with RAN resources, for example).¶

The mechanism can also be used to enrich the tools that are already available to better handle attack traffic close to the source [RFC9066].¶

Better Local Services:

A user may configure policies on the CE such as securing some resources to a specific internal host used, e.g., for gaming or video streaming. The CE can use the throughput advice to share these rate-limit policies to connected hosts to adjust their forwarding behavior. Controlling the load at the source will allow to partition the resources between connected hosts.¶

5. Throughput Advice Object

; Provides information about the rate-limit policy that is
; enforced for a network attachment.
; One or more throughput instances can be present in an advice.

throughput-advice =  [+ throughput-instance]

throughput-instance =  {
  ? optional-parameter-flags => opf,
  ? flow-flags => ff,
  ? traffic-category => category,
  throughput => rate-limit
}

; Controls the presence of optional parameters such as
; excess and peak rates.
; Setting these parameters to false means that excess and
; peak parameters are not supplied in the policy.
; These control bits may not be required for protocols with
; built-in mechanisms to parse objects even with
; optional/variable fields.

opf =  {
  ? excess: bool .default false,
  ? peak: bool .default false
}

; Indicates scope, traffic direction, and reliability type.
; Default value for scope is per subscriber policy.
; Default value for direction is network-to-host direction.
; Default value for reliability is false (i.e., the policy is
; applicable to both reliable and unreliable traffic).
; If any of these parameters is not present, this is equivalent
; to enclosing the parameter with its default value.

ff =  {
  ? scope: &scope-values .default subscriber,
  ? direction: &direction-values .default n2h,
  ? reliability: &reliability-values .default any
}

scope-values = (subscriber: 0, host: 1, flow: 2)
direction-values = (n2h: 0, h2n: 1, bidir: 2)
reliability-values = (any: 0, reliable: 1, unreliable: 2)

; Indicates traffic category to which the policy is bound.
; If the value is set to 0, this means that the policy is
; enforced for all traffic.

category =  {
  ? tc: uint .default 0
}

; Indicates the rate and burst limits.
; Only CIR/CBS are mandatory to include.
; A rate-limit may also include an excess or peak limits.

rate-limit = (
  group-a/ group-b
)

group-a = {
  cir: uint,          ; Mbps
  cbs: uint .gt 0,    ; bytes
  ? eir: uint,        ; Mbps
  ? ebs: uint .gt 0,  ; bytes
}

group-b = {
  cir: uint,          ; Mbps
  cbs: uint .gt 0,    ; bytes
  ? pir: uint,        ; Mbps
  ? pbs: uint .gt 0,  ; bytes
}

6. Examples

For the sake of illustration, Figure 3 exemplifies the content of a throughput advice using JSON notations. The advice includes one rate-limit instance that covers network-to-host traffic direction and is applicable to all traffic destined to any host of a subscriber.¶

{
    "throughput-advice": [
        {
            "direction": 0,
            "scope": 0,
            "tc": 0,
            "cir": 50,
            "cbs": 10000
        }
    ]
}

The advice conveyed in Figure 4 is similar to the advice in Figure 3. The only difference is that default values are trimmed in Figure 4.¶

{
    "throughput-advice": [
        {
            "cir": 50,
            "cbs": 10000
        }
    ]
}

Figure 5 shows the example of an advice that encloses two instances, each for one traffic direction.¶

{
    "throughput-advice": [
        {
            "direction": 0,
            "cir": 50,
            "cbs": 10000
        },
        {
            "direction": 1,
            "cir": 30,
            "cbs": 8000
        }
    ]
}

If both directions are covered by the same rate-limit policy, then the advice can be supplied as shown in Figure 6¶

{
    "throughput-advice": [
        {
            "direction": 2,
            "cir": 50,
            "cbs": 10000
        }
    ]
}

7. Sample Uses of the Advice

It is out of scope of this document to make recommendations about how the advice is consumed by applications/OS/Hosts. A non-exhaustive list is provided hereafter for illustration purposes:¶

• Applications can send/receive data at a rate beyond the CIR up to the PIR when the network is not congested. If network feedback (e.g., packet loss or delay) indicates congestion, the application can scale back to the CIR. Otherwise, it can use the PIR for temporary throughput boosts.¶

• Applications can send/receive short-term bursts of data that exceed the committed burst size CBS up to the PBS if there is no congestion. This is useful for scenarios where short, high-throughput bursts are needed.¶

• Applications can ensure that their sending rate never exceeds the PIR and that their short-term bursts of traffic never exceeds PBS.¶

• Applications can send/receive data at different rates for reliable and unreliable traffic (reliable could map to Queue-Building (QB) and unreliable could map to Non-Queue-Building (NQB)) by mapping reliability flag. One of the ways for application to make reliability markings visible is by following, e.g., the considerations in Section 4 of [I-D.ietf-tsvwg-nqb].¶

• The throughput advice can feed mechanisms such as Section 4.4.2 of [RFC7661] or Section 7.8 of [RFC9002] to control the maximum burst size.¶

8. Security Considerations

As discussed in Section 4, sharing a throughput advice helps networks mitigate overloads, particularly during periods of high traffic volume.¶

An attacker who has the ability to change the throughput advice objects exchanged over a network attachment may:¶

Decrease the bitrate value:

This may lower the perceived QoS if the host aggressively lowers its transmission rate.¶

Increase the bitrate value:

The network attachment will be overloaded, but still the rate-limit at the network will discard excess traffic.¶

Delete or remove the advice:

This is equivalent to deployments where the advice is not shared.¶

9. IANA Considerations

10. References

Appendix A. Overview of Network Rate-Limit Policies

As discussed, for example in [I-D.ietf-teas-5g-ns-ip-mpls], a provider network's inbound policy can be implemented using one of following options:¶

• 1r2c (single-rate two-color) rate limiter¶

  This is the most basic rate limiter, described in Section 2.3 of [RFC2475]. It meters at an ingress interface a traffic stream and marks its packets as in-profile (below CIR being enforced) or out-of-profile (above CIR being enforced). In-profile packets are accepted and forwarded. Out-of profile packets are either dropped right at the ingress node (hard rate limiting), or remarked (with different MPLS TC or DSCP TN markings) to signify 'this packet should be dropped in the first place, if there is a congestion' (soft rate limiting), depending on the business policy of the provider network. In the second case, while packets above CIR are forwarded at an ingress node, they are subject to being dropped during any congestion event at any place in the provider network.¶

• 2r3c (two-rate three-color) rate limiter¶

  This was initially defined in [RFC2698], and its improved version in [RFC4115]. The traffic is assigned to one of the these three categories:¶

  • Green, for traffic under CIR¶

  • Yellow, for traffic between CIR and PIR¶

  • Red, for traffic above PIR¶

  An inbound 2r3c meter implemented with [RFC4115], compared to [RFC2698], is more 'customer friendly' as it doesn't impose outbound peak-rate shaping requirements on customer edge (CE) devices or hosts. 2r3c meters in general give greater flexibility for provider network edge enforcement regarding accepting the traffic (green), de-prioritizing and potentially dropping the traffic on transit during congestion (yellow), or hard dropping the traffic (red).¶

Acknowledgments

Thanks to Eduard Vasilenko for the comments.¶

Authors' Addresses