]> Orange

mohamed.boucadair@orange.com

Cloud Software Group Holdings, Inc.

United States of America danwing@gmail.com

Nokia

India kondtir@gmail.com

Cloud Software Group Holdings, Inc.

United States of America sridharan.girish@gmail.com

Telefonica

Spain luismiguel.contrerasmurillo@telefonica.com

wit scone collaborative networking adaptive application 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 mechanims 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 Source for this draft and an issue tracker can be found at .

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. 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, does not show the interconnection with other networks or multi-homed CEs.

Sample Network Attachments

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 . As discussed, e.g., in , 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" ). defines a set 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 a 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 . Sample uses of the advice by applications are listed in . 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 mechanims, allow for future extensions, and ensure consistent use of the advice, a new IANA registry is created in .

What's Out? This document does not make any assumption about:

• The type of the 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 is OS-specific and, thus, out of scope of this document.

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 when, and only when, they appear in all capitals, as shown here. This document makes use fo the following term:

Rate-limit:

Used as a generic term to refer to a policy to restrict the maximum bitrate of a flow.

It can be used with or without any traffic classification.

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

Sample Deployment Cases Some deployment use cases for throughput advice discovery are provided below:

Adaptive Application Behavior:

Discovery of intentional policy applied on network attachements 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 .

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. Controling the load at the source will allow to partition the resources between connected hosts.

Throughput Advice Object

Throughput Parameters The throughput advice parameters leverage existing technologies for configuring policies in provider networks. provides a brief overview of how inbound policies are enforced in ingress network nodes. The reader may refer to , , and 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 Rate (PIR), and Peak Burst Size (PBS) are used for policing. Typically:

• A Single-Rate, Three-Color Marker uses CIR, CBS, and EBS.
• A Dual-Rate, Three-Color Marker uses CIR, CBS, PIR, and PBS. Note that when implemented with , it allows for a better handling of in-profile traffic (refer to for more details).

An implementation example of these variants (and others) can be found at .

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 . Throughput advice objects are bound to the network interface over which the advice was received. The throughput advice object is described in CDDL format shown in . This format is meant to ease mapping with encoding specifics of a given discovery channel that supplies the throughput advice.

Throughput Advice Object Format in CDDL opf, ? flow-flags => ff, ? traffic-category => category, throughput => rate-limit } ; Controls the presence of optional parameters such as ; excess and peak rates. ; Settting 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 various rates (committed, excess, and peak). ; Only CIR/CBS are mandatory to include. rate-limit = { cir: uint, ; Mbps cbs: uint .gt 0, ; bytes ? eir: uint, ; Mbps ? ebs: uint .gt 0, ; bytes ? pir: uint, ; Mbps ? pbs: uint .gt 0, ; bytes } ]]>

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 Rate (EIR).

When set to "0", this flag indicates that EIR is not present.

P:

When set to "1", this flag indicates the presence of Peak Information Rate (PIR).

When set to "0", this flag indicates that PIR is not present.

U:

Unassigned bits. See .

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-host, per-subscriber, 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.

When set to "10b", this flag indicates that this policy is for both network-to-host and host-to-network directions.

R (Reliablity):

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 .

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 .

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 is set to '1'.

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

Examples For the sake of illustration, 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.

A JSON Example

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

A JSON Example with Default Values Trimmed

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

A JSON Example with Both Traffic Directions

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

A JSON Example with Single Bidir Rate-Limit Policy

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 .
• The throughput advice can feed mechanisms such as or to control the maximum burst size.

Security Considerations As discussed in , 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.

IANA Considerations

Rate-Limit Policy Objects Registry Group This document requests IANA to create a new registry group entitled "SCONE Rate-Limit Policy Objects".

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 (). The initial values of this registry is provided in . Optional Parameter Flags

Bit Position	Label	Description	Reference
1	E	Indicates presence of excess rate/burst	This-Document
2	P	Indicates presence of peak rate/burst	This-Document
3		Unassigned
4		Unassigned

The allocation policy of this new registry is "IETF Review" ().

Flow Flags Registry This document requests IANA to create a new registry entitled "Flow flags" under the "SCONE Rate-Limit Policy Objects" registry group (). The initial values of this registry is provided in . Flow flags

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

The allocation policy of this new registry is "IETF Review" ().

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 (). The initial values of this registry is provided in . Traffic Category Values

Value	Description	Reference
0	All traffic	This-Document
1-63	Unassigned

The allocation policy of this new registry is "IETF Review" ().

Rate Parameters Registry This document requests IANA to create a new registry entitled "Rate Parameters" under the "SCONE Rate-Limit Policy Objects" registry group (). The initial values of this registry is provided in . Initial Rate Parameters Values Values

Parameter	Description	Mandatory (Y/N)	Reference
cir	Committed Information Rate (CIR)	Y	This-Document
cbs	Committed Burst Size (CBS)	Y	This-Document
eir	Excess Information Rate (EIR)	N	This-Document
ebs	Excess Burst Size (EBS)	N	This-Document
pir	Peak Information Rate (PIR)	N	This-Document
pbs	Peak Burst Size (PBS)	N	This-Document

The allocation policy of this new registry is "IETF Review" ().

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Informative References Vector Packet Processor (VPP) Orange Juniper Telefonica Nokia Huawei Technologies This document specifies a network model for attachment circuits. The model can be used for the provisioning of attachment circuits prior or during service provisioning (e.g., VPN, Network Slice Service). A companion service model is specified in the YANG Data Models for Bearers and 'Attachment Circuits'-as-a-Service (ACaaS) (I-D.ietf- opsawg-teas-attachment-circuit). The module augments the base network ('ietf-network') and the Service Attachment Point (SAP) models with the detailed information for the provisioning of attachment circuits in Provider Edges (PEs). This memo presents recommendations to the Internet community concerning measures to improve and preserve Internet performance. It presents a strong recommendation for testing, standardization, and widespread deployment of active queue management (AQM) in network devices to improve the performance of today's Internet. It also urges a concerted effort of research, measurement, and ultimate deployment of AQM mechanisms to protect the Internet from flows that are not sufficiently responsive to congestion notification. Based on 15 years of experience and new research, this document replaces the recommendations of RFC 2309. This document defines a YANG data model that can be used to configure a Layer 2 provider-provisioned VPN service. It is up to a management system to take this as an input and generate specific configuration models to configure the different network elements to deliver the service. How this configuration of network elements is done is out of scope for this document. The YANG data model defined in this document includes support for point-to-point Virtual Private Wire Services (VPWSs) and multipoint Virtual Private LAN Services (VPLSs) that use Pseudowires signaled using the Label Distribution Protocol (LDP) and the Border Gateway Protocol (BGP) as described in RFCs 4761 and 6624. The YANG data model defined in this document conforms to the Network Management Datastore Architecture defined in RFC 8342. This document specifies the Denial-of-Service Open Threat Signaling (DOTS) signal channel Call Home, which enables a Call Home DOTS server to initiate a secure connection to a Call Home DOTS client and to receive attack traffic information from the Call Home DOTS client. The Call Home DOTS server in turn uses the attack traffic information to identify compromised devices launching outgoing DDoS attacks and take appropriate mitigation action(s). The DOTS signal channel Call Home is not specific to home networks; the solution targets any deployment in which it is required to block DDoS attack traffic closer to the source(s) of a DDoS attack. This document defines a Single Rate Three Color Marker (srTCM), which can be used as component in a Diffserv traffic conditioner. This memo provides information for the Internet community. This document defines a Two Rate Three Color Marker (trTCM), which can be used as a component in a Diffserv traffic conditioner. This memo provides information for the Internet community. This document describes a two-rate, three-color marker that has been in use for data services including Frame Relay services. This marker can be used for metering per-flow traffic in the emerging IP and L2 VPN services. The marker defined here is different from previously defined markers in the handling of the in-profile traffic. Furthermore, this marker doesn't impose peak-rate shaping requirements on customer edge (CE) devices. This memo provides information for the Internet community. CableLabs Linaro Deutsche Telekom This document specifies characteristics of a Non-Queue-Building Per- Hop Behavior (NQB PHB). The NQB PHB provides a shallow-buffered, best-effort service as a complement to a Default deep-buffered best- effort service for Internet services. The purpose of this NQB PHB is to provide a separate queue that enables smooth (i.e. non-bursty), low-data-rate, application-limited traffic microflows, which would ordinarily share a queue with bursty and capacity-seeking traffic, to avoid the latency, latency variation and loss caused by such traffic. This PHB is implemented without prioritization and can be implemented without rate policing, making it suitable for environments where the use of these features is restricted. The NQB PHB has been developed primarily for use by access network segments, where queuing delays and queuing loss caused by Queue-Building protocols are manifested, but its use is not limited to such segments. In particular, applications to cable broadband links, Wi-Fi links, and mobile network radio and core segments are discussed. This document recommends a specific Differentiated Services Code Point (DSCP) to identify Non-Queue-Building microflows, and updates the RFC8325 guidance on mapping Diffserv to IEEE 802.11 for this codepoint. [NOTE (to be removed by RFC-Editor): This document references an ISE submission draft (I-D.briscoe-docsis-q-protection) that is approved for publication as an RFC. This draft should be held for publication until the queue protection RFC can be referenced.] This document provides a mechanism to address issues that arise when TCP is used for traffic that exhibits periods where the sending rate is limited by the application rather than the congestion window. It provides an experimental update to TCP that allows a TCP sender to restart quickly following a rate-limited interval. This method is expected to benefit applications that send rate-limited traffic using TCP while also providing an appropriate response if congestion is experienced. This document also evaluates the Experimental specification of TCP Congestion Window Validation (CWV) defined in RFC 2861 and concludes that RFC 2861 sought to address important issues but failed to deliver a widely used solution. This document therefore reclassifies the status of RFC 2861 from Experimental to Historic. This document obsoletes RFC 2861. This document describes loss detection and congestion control mechanisms for QUIC. Juniper Networks Juniper Networks Juniper Networks Orange Telefonica Slicing is a feature that was introduced by the 3rd Generation Partnership Project (3GPP) in mobile networks. Realization of 5G slicing implies requirements for all mobile domains, including the Radio Access Network (RAN), Core Network (CN), and Transport Network (TN). This document describes a Network Slice realization model for IP/MPLS networks with a focus on the Transport Network fulfilling 5G slicing connectivity service objectives. The realization model reuses many building blocks currently commonly used in service provider networks. This document defines an architecture for implementing scalable service differentiation in the Internet. This memo provides information for the Internet community.

Overview of Network Rate-Limit Policies As discussed, for example in , 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 . It meters at an ingress intreface 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 , and its improved version in . 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 , compared to , 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 TBC.