Throughput Advice Object for SCONE
draft-brw-scone-throughput-advice-blob-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Mohamed Boucadair , Dan Wing , Tirumaleswar Reddy.K , Sridharan Rajagopalan , Luis M. Contreras | ||
| Last updated | 2024-12-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-brw-scone-throughput-advice-blob-01
scone M. Boucadair
Internet-Draft Orange
Intended status: Standards Track D. Wing
Expires: 6 June 2025 Cloud Software Group
T. Reddy
Nokia
S. Rajagopalan
Cloud Software Group
L. Contreras
Telefonica
3 December 2024
Throughput Advice Object for SCONE
draft-brw-scone-throughput-advice-blob-01
Abstract
Traffic exchanged over a network may be subject to rate-limit
policies for various operational reasons. This document specifies a
generic object (called, Throughput Advice) that can be used by
mechanisms for hosts to dynamically discover these network rate-limit
policies. This information is then passed to applications that might
adjust their behaviors accordingly.
The design of the throughput advice object is independent of the
discovery channel (protocol, API, etc.).
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/boucadair/draft-xxx-ac-rate-policy-discovery.
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/.
Boucadair, et al. Expires 6 June 2025 [Page 1]
Internet-Draft SCONE Blob December 2024
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. What's Out? . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Conventions and Definitions . . . . . . . . . . . . . . . . . 5
4. Sample Deployment Cases . . . . . . . . . . . . . . . . . . . 5
5. Throughput Advice Object . . . . . . . . . . . . . . . . . . 6
5.1. Throughput Parameters . . . . . . . . . . . . . . . . . . 6
5.2. Overall Object Structure . . . . . . . . . . . . . . . . 7
5.3. Throughput Advice Instance Attributes . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Sample Uses of the Advice . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. Rate-Limit Policy Objects Registry Group . . . . . . . . 14
9.2. Optional Parameter Flags Registry . . . . . . . . . . . . 14
9.3. Flow Flags Registry . . . . . . . . . . . . . . . . . . . 15
9.4. Traffic Category Registry . . . . . . . . . . . . . . . . 16
9.5. Rate Parameters Registry . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Overview of Network Rate-Limit Policies . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
Boucadair, et al. Expires 6 June 2025 [Page 2]
Internet-Draft SCONE Blob December 2024
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.
Hosts
O O O
\|/
.------. .--------------------. .------.
| +------+ | +---NA----+ |
| UE#1 | | | +---NA----+ CE#2 |
'------' +---NA----+ | '------'
| Network |
.------. .---NA----+ |
| | | | | .------.
| CE#1 +------' | +---NA----+ CE#3 |
'------' | | '------'
/|\ '--------------------' /|\
O O O O O O
Hosts Hosts
Figure 1: Sample Network Attachments
Boucadair, et al. Expires 6 June 2025 [Page 3]
Internet-Draft SCONE Blob December 2024
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.
Boucadair, et al. Expires 6 June 2025 [Page 4]
Internet-Draft SCONE Blob December 2024
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:
Boucadair, et al. Expires 6 June 2025 [Page 5]
Internet-Draft SCONE Blob December 2024
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
5.1. Throughput Parameters
The throughput advice parameters leverage existing technologies for
configuring policies in provider networks. Appendix A provides a
brief overview of how inbound policies are enforced in ingress
network nodes. The reader may refer to [RFC2697], [RFC2698], and
[RFC4115] for examples of how various combinations of Committed
Information Rate (CIR), Committed Burst Size (CBS), Excess
Information Rate (EIR), Excess Burst Size (EBS), Peak Information
Boucadair, et al. Expires 6 June 2025 [Page 6]
Internet-Draft SCONE Blob December 2024
Rate (PIR), and Peak Burst Size (PBS) are used for policing.
Typically:
* A Single-Rate, Three-Color Marker [RFC2697] uses CIR, CBS, and
EBS.
* A Dual-Rate, Three-Color Marker [RFC2698] uses CIR, CBS, PIR, and
PBS. Note that when implemented with [RFC4115], it allows for a
better handling of in-profile traffic (refer to Section 1 of
[RFC4115] for more details).
An implementation example of these variants (and others) can be found
at [VPP].
5.2. Overall Object Structure
A throughput advice object may include multiple throughput advices
(referred to as "throughput advice instances"), each covering a
specific match criteria. Each of these instances adheres to the
structure defined in Section 5.3.
Throughput advice objects are bound to the network interface over
which the advice was received.
The throughput advice object is described in CDDL [RFC8610] format
shown in Figure 2. This format is meant to ease mapping with
encoding specifics of a given discovery channel that supplies the
throughput advice.
; 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
Boucadair, et al. Expires 6 June 2025 [Page 7]
Internet-Draft SCONE Blob December 2024
; 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
}
Boucadair, et al. Expires 6 June 2025 [Page 8]
Internet-Draft SCONE Blob December 2024
group-b = {
cir: uint, ; Mbps
cbs: uint .gt 0, ; bytes
? pir: uint, ; Mbps
? pbs: uint .gt 0, ; bytes
}
Figure 2: Throughput Advice Object Format in CDDL
5.3. Throughput Advice Instance Attributes
This section defines the set of attributes that are included in a
throughput advice instance:
Optional Parameter Flags (OPF): These flags indicate the presence of
some optional parameters. The following flags are defined:
E: When set to "1", this flag indicates the presence of excess
information.
When set to "0", this flag indicates that excess information is
not present.
P: When set to "1", this flag indicates the presence of peak
information.
When set to "0", this flag indicates that peak information is
not present.
U: Unassigned values. See Section 9.2.
Flow flags (FF): These flags are used to express some generic
properties of the flow. The following flags are defined:
S (Scope): Indicates the granularity of enforcing policies.
This parameter specifies whether the policy is a per-
subscriber, per-host, or per-flow policy.
D (Direction): Indicates the direction on which to apply the
enclosed policy.
When set to "00b", this flag indicates that this policy is for
network-to-host direction.
When set to "01b", this flag indicates that this policy is for
host-to-network direction.
Boucadair, et al. Expires 6 June 2025 [Page 9]
Internet-Draft SCONE Blob December 2024
When set to "10b", this flag indicates that this policy is for
both network-to-host and host-to-network directions.
R (Reliability): Indicates the reliability type of traffic on
which to apply the enclosed policy.
When set to "00b", this flag indicates that this policy is for
both reliable and unreliable traffic.
When set to "01b", this flag indicates that this policy is for
unreliable traffic.
When set to "10b", this flag indicates that this policy is for
reliable traffic.
No meaning is associated with setting the field to "11b". Such
value MUST be silently ignored by the receiver.
U: Unassigned flags. See Section 9.3.
TC (Traffic Category): Specifies a traffic category to which this
policy applies.
The following values are supported:
* "0": All traffic. This is the default value.
* 1-63: Unassigned values. See Section 9.4.
Committed Information Rate (CIR) (Mbps): An average rate that
specifies the maximum number of bits that a network can send (or
receive) during one second over a network attachment.
The CIR value MUST be greater than or equal to 0.
If set to 0 (or a very low value), this indicates to the host that
alternate paths (if any) should be preferred over this one.
This parameter is mandatory.
Committed Burst Size (CBS) (bytes): Specifies the maximum burst size
that can be transmitted at CIR.
MUST be greater than zero.
This parameter is mandatory.
Excess Information Rate (EIR) (Mbps): MUST be present if the E flag
Boucadair, et al. Expires 6 June 2025 [Page 10]
Internet-Draft SCONE Blob December 2024
is set to '1'.
An average rate that specifies the maximum number of bits that a
network can send (or receive) during one second over a network
attachment for a traffic that is out of profile.
The EIR value MUST be greater than or equal to 0, if present.
This parameter is optional.
Excess Burst Size (EBS) (bytes): MUST be present if EIR is also
present.
Indicates the maximum excess burst size that is allowed while not
complying with the CIR.
MUST be greater than zero, if present.
This parameter is optional.
Peak Information Rate (PIR) (Mbps): MUST be present if P flag is set
to '1'.
Indicates the allowed throughput when there is a peak in traffic.
That is, traffic that exceeds the CIR and the CBS is metered to
the PIR.
The PIR MUST be equal to or greater than the CIR, if present.
This parameter is optional.
Peak Burst Size (PBS) (bytes): MUST be present if PIR is also
present.
Specifies the maximum burst size that can be transmitted at PIR.
MUST be greater than zero, if present.
This parameter is optional.
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.
Boucadair, et al. Expires 6 June 2025 [Page 11]
Internet-Draft SCONE Blob December 2024
{
"throughput-advice": [
{
"direction": 0,
"scope": 0,
"tc": 0,
"cir": 50,
"cbs": 10000
}
]
}
Figure 3: A JSON Example
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 4: A JSON Example with Default Values Trimmed
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
}
]
}
Figure 5: A JSON Example with Both Traffic Directions
Boucadair, et al. Expires 6 June 2025 [Page 12]
Internet-Draft SCONE Blob December 2024
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
}
]
}
Figure 6: A JSON Example with Single Bidir Rate-Limit Policy
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.
Boucadair, et al. Expires 6 June 2025 [Page 13]
Internet-Draft SCONE Blob December 2024
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
9.1. Rate-Limit Policy Objects Registry Group
This document requests IANA to create a new registry group entitled
"SCONE Rate-Limit Policy Objects".
9.2. Optional Parameter Flags Registry
This document requests IANA to create a new registry entitled
"Optional Parameter Flags" under the "SCONE Rate-Limit Policy
Objects" registry group (Section 9.1).
The initial values of this registry is provided in Table 1.
Boucadair, et al. Expires 6 June 2025 [Page 14]
Internet-Draft SCONE Blob December 2024
+==============+=======+======================+===============+
| Bit Position | Label | Description | Reference |
+==============+=======+======================+===============+
| 1 | E | Indicates presence | This-Document |
| | | of excess rate/burst | |
+--------------+-------+----------------------+---------------+
| 2 | P | Indicates presence | This-Document |
| | | of peak rate/burst | |
+--------------+-------+----------------------+---------------+
| 3 | | Unassigned | |
+--------------+-------+----------------------+---------------+
| 4 | | Unassigned | |
+--------------+-------+----------------------+---------------+
Table 1: Optional Parameter Flags
The allocation policy of this new registry is "IETF Review"
(Section 4.8 of [RFC8126]).
9.3. Flow Flags Registry
This document requests IANA to create a new registry entitled "Flow
flags" under the "SCONE Rate-Limit Policy Objects" registry group
(Section 9.1).
The initial values of this registry is provided in Table 2.
+==============+=======+=============+===============+
| Bit Position | Label | Description | Reference |
+==============+=======+=============+===============+
| 1 | S | Scope | This-Document |
+--------------+-------+-------------+---------------+
| 2-3 | D | Direction | This-Document |
+--------------+-------+-------------+---------------+
| 4-5 | R | Reliability | This-Document |
+--------------+-------+-------------+---------------+
| 6-8 | | Unassigned | |
+--------------+-------+-------------+---------------+
Table 2: Flow flags
The allocation policy of this new registry is "IETF Review"
(Section 4.8 of [RFC8126]).
Boucadair, et al. Expires 6 June 2025 [Page 15]
Internet-Draft SCONE Blob December 2024
9.4. Traffic Category Registry
This document requests IANA to create a new registry entitled
"Traffic Category Types" under the "SCONE Rate-Limit Policy Objects"
registry group (Section 9.1).
The initial values of this registry is provided in Table 3.
+=======+=============+===============+
| Value | Description | Reference |
+=======+=============+===============+
| 0 | All traffic | This-Document |
+-------+-------------+---------------+
| 1-63 | Unassigned | |
+-------+-------------+---------------+
Table 3: Traffic Category Values
The allocation policy of this new registry is "IETF Review"
(Section 4.8 of [RFC8126]).
9.5. Rate Parameters Registry
This document requests IANA to create a new registry entitled "Rate
Parameters" under the "SCONE Rate-Limit Policy Objects" registry
group (Section 9.1).
The initial values of this registry is provided in Table 4.
Boucadair, et al. Expires 6 June 2025 [Page 16]
Internet-Draft SCONE Blob December 2024
+===========+=======================+===========+===============+
| Parameter | Description | Mandatory | Reference |
| | | (Y/N) | |
+===========+=======================+===========+===============+
| cir | Committed Information | Y | This-Document |
| | Rate (CIR) | | |
+-----------+-----------------------+-----------+---------------+
| cbs | Committed Burst Size | Y | This-Document |
| | (CBS) | | |
+-----------+-----------------------+-----------+---------------+
| eir | Excess Information | N | This-Document |
| | Rate (EIR) | | |
+-----------+-----------------------+-----------+---------------+
| ebs | Excess Burst Size | N | This-Document |
| | (EBS) | | |
+-----------+-----------------------+-----------+---------------+
| pir | Peak Information Rate | N | This-Document |
| | (PIR) | | |
+-----------+-----------------------+-----------+---------------+
| pbs | Peak Burst Size (PBS) | N | This-Document |
+-----------+-----------------------+-----------+---------------+
Table 4: Initial Rate Parameters Values Values
The allocation policy of this new registry is "IETF Review"
(Section 4.8 of [RFC8126]).
10. References
10.1. 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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[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>.
Boucadair, et al. Expires 6 June 2025 [Page 17]
Internet-Draft SCONE Blob December 2024
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
10.2. Informative References
[I-D.ietf-opsawg-ntw-attachment-circuit]
Boucadair, M., Roberts, R., de Dios, O. G., Barguil, S.,
and B. Wu, "A Network YANG Data Model for Attachment
Circuits", Work in Progress, Internet-Draft, draft-ietf-
opsawg-ntw-attachment-circuit-14, 7 November 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
ntw-attachment-circuit-14>.
[I-D.ietf-teas-5g-ns-ip-mpls]
Szarkowicz, K. G., Roberts, R., Lucek, J., Boucadair, M.,
and L. M. Contreras, "A Realization of Network Slices for
5G Networks Using Current IP/MPLS Technologies", Work in
Progress, Internet-Draft, draft-ietf-teas-5g-ns-ip-mpls-
13, 11 October 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-teas-5g-
ns-ip-mpls-13>.
[I-D.ietf-tsvwg-nqb]
White, G., Fossati, T., and R. Geib, "A Non-Queue-Building
Per-Hop Behavior (NQB PHB) for Differentiated Services",
Work in Progress, Internet-Draft, draft-ietf-tsvwg-nqb-27,
8 November 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-tsvwg-nqb-27>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<https://www.rfc-editor.org/rfc/rfc2475>.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, DOI 10.17487/RFC2697, September 1999,
<https://www.rfc-editor.org/rfc/rfc2697>.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, DOI 10.17487/RFC2698, September 1999,
<https://www.rfc-editor.org/rfc/rfc2698>.
Boucadair, et al. Expires 6 June 2025 [Page 18]
Internet-Draft SCONE Blob December 2024
[RFC4115] Aboul-Magd, O. and S. Rabie, "A Differentiated Service
Two-Rate, Three-Color Marker with Efficient Handling of
in-Profile Traffic", RFC 4115, DOI 10.17487/RFC4115, July
2005, <https://www.rfc-editor.org/rfc/rfc4115>.
[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., "IETF
Recommendations Regarding Active Queue Management",
BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015,
<https://www.rfc-editor.org/rfc/rfc7567>.
[RFC7661] Fairhurst, G., Sathiaseelan, A., and R. Secchi, "Updating
TCP to Support Rate-Limited Traffic", RFC 7661,
DOI 10.17487/RFC7661, October 2015,
<https://www.rfc-editor.org/rfc/rfc7661>.
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG
Data Model for Layer 2 Virtual Private Network (L2VPN)
Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October
2018, <https://www.rfc-editor.org/rfc/rfc8466>.
[RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
and Congestion Control", RFC 9002, DOI 10.17487/RFC9002,
May 2021, <https://www.rfc-editor.org/rfc/rfc9002>.
[RFC9066] Reddy.K, T., Boucadair, M., Ed., and J. Shallow,
"Distributed Denial-of-Service Open Threat Signaling
(DOTS) Signal Channel Call Home", RFC 9066,
DOI 10.17487/RFC9066, December 2021,
<https://www.rfc-editor.org/rfc/rfc9066>.
[VPP] Vector Packet Processor (VPP), "Policing", <https://s3-
docs.fd.io/vpp/23.06/developer/corefeatures/policer.html>.
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
Boucadair, et al. Expires 6 June 2025 [Page 19]
Internet-Draft SCONE Blob December 2024
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
Mohamed Boucadair
Orange
Email: mohamed.boucadair@orange.com
Dan Wing
Cloud Software Group Holdings, Inc.
United States of America
Email: danwing@gmail.com
Tirumaleswar Reddy
Nokia
India
Email: kondtir@gmail.com
Boucadair, et al. Expires 6 June 2025 [Page 20]
Internet-Draft SCONE Blob December 2024
Sridharan Rajagopalan
Cloud Software Group Holdings, Inc.
United States of America
Email: sridharan.girish@gmail.com
Luis M. Contreras
Telefonica
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
Boucadair, et al. Expires 6 June 2025 [Page 21]