Merge branch 'main' into scope

draft-brw-scone-rate-policy-discovery.md

@@ -308,7 +308,7 @@ Some deployment use cases for NRLP are provided below:
 
 * A user may configure policies on the CPE such as securing some resources to a specific internal host used for gaming or video streaming. The CPE can use the NRLP option to share these rate-limit policies to connected hosts to adjust their forwarding behavior.
 
-Operational considerations are discussed in {{sec-ops}}, while deployment incentives are described in {{sec-inc}}.
+Deployment incentives are described in {{sec-inc}}.
 
 # Conventions and Definitions
 
@@ -688,65 +688,6 @@ are to be returned for distinct traffic categories.
 ~~~~~
 {: #pvd-ex title="NRLP Example with PvD"}
 
-# Operational Considerations {#sec-ops}
-
-## NRLP Is Complementary Not Replacement Solution
-
-Sharing NRLP signals are not intended to replace usual actions to soften bottlenck issues (e.g., adequate network dimensioning and upgrades). However, given that such actions may not be always immediately possible or economically justified, NRLP signals can be considered as complementary mitigations to soften these issues by introducing some collaboration between a host and
-its networks to adjust their behaviors.
-
-## Provisionning Policies
-
-NRLP senders should be configured with instructions about the type of network rate-limit policies to be shared with requesting hosts. These types can be provided using mechanisms such as {{?I-D.ietf-opsawg-ntw-attachment-circuit}}.
-
-## Redundant vs. Useful Signal
-
-In contexts where the bitrate policies are known during the establishment of the underlying bearer (e.g., GBR PDU Sessions), sending NRLP signals over the AC may be redundant and should thus be disabled.
-
-In contexts where the (average) bitrate policies provided during the establishment of a bearer cannot be refreshed to echo network-specific conditions (e.g., overload) using bearer-specific mechanisms, sending NRLP signals over the AC would allow control the load at the source.
-
-When both bearer-specific policies and NRLP signals are communicated to a host, the NRLP signals takes precedence.
-
-## Fairness
-
-Rate-limit policies enforced at the network are assumed to be consistent with the local jurisdictions. For example:
-
-* {{BEREC}} states that ISPs are prohibited from blocking or slowing down of Internet traffic, except for legal reasons, network security, or congestion, provided that equivalent categories of traffic are treated equally.
-* {{FCC}} states that net neutrality policies "prohibits internet service providers from blocking, throttling, or engaging in paid prioritization of lawful content". The FCC allows some exceptions, like for security and emergencies.
-
-These regulatory frameworks align with the goals of this document.
-
-## Architectural Considerations Matter
-
-Approaches based on middleboxes are generally not recommended due to their inherent limitations, in terms of performance, scalability, redundancy, etc. Specifically, if the management and operation of such middleboxes remain unclear, that motivate operational issues and responsibilities.
-Furthermore, it is important to note that any middlebox could not necessarily cover an entire service end-to-end, thus **producing only partial observations which could not be sufficiently good at the time of generating appropriate signals**.
-
-The NRLP solution does not require such middleboxes but the consideration about partial observability applies. That concern can be softened by cascaded NLRP design. However, network integration of such appraoch is to be further elaborated.
-
-## Service Considerations: Application Diversity & Realistic Assessment
-
-Signals could be generated for multiple services and/or applications. For instance, services providing short video content might require signals different to those based on long videos. This implies the need of defining a generic method suitable for any kind of service and application, avoiding the multiplicity of solutions and the dominance of some applications over others.
-
-It should be also noted that more experimentation is needed in order to fully understand the implications of the signals in the overall performance of the network. On one hand, the co-existence of multiple flows, some of them using the signals for improving the experience, some others not. For this, more experimentation and datasets are required, so then can be clear that no flows are negatively impacted at all.
-
-On the other hand, if the experience of the flows improves and depending on the nature of the signals themselves, this might motivate a more intense usage of the network, then requiring to accommodate larger number of flows, and in consequence, reducing the available resources per application. This kind of paradox can be **assessed with more experimental results under realistic conditions (i.e., multiple users and multiple services in the network)**.
-
-## Operational Guidance for Signal Enforcement
-
-Signals are conceived as indications from the network towards applications. It is not clear the way of enforcing the application to follow the indication, especially in a context where different applications from a user, or multiple users, simultaneously access the network. This can motivate a wastage of resources for generating signals with the risk of not being effective. Furthermore, it might lead to a continuous loop of signal generation because the initial signals being ignored. It is then necessary to define mechanisms to avoid permanent signal generation when ignored.
-
-Finally, signals could not be required at every moment, but only in situations that can benefit the service. Such situations could be due, for instance, to given levels of congestion, or based on previous information shared by the application (e.g., SLO thresholds) so that signals can be triggered according to service conditions. **Elaborating more operational guidance on intended signal enforcment policy is key**.
-
-## Signal Estimation
-
-The validity of the estimation produced by a network might be questioned by the application. Trust is required in a way that applications can safely follow guidance from a network. Furthermore, whatever estimation should be timely produced, avoiding the generation of aged estimations that could not correspond to the actual service circumstances. Finally, some common guidance is necessary to define a standard way of generating signals, for instance, per-flow or per group of flows.
-
-An open point is how to deal with adaptive applications, in the sense that signals could not be of value because the self-adaptation nature of these applications.
-
-## Signal "Interference"
-
-The network is built on multiple layers. In some cases, different solutions targeting similar objectives (e.g., congestion control or bottleneck mitigation) can be in place. It is then necessary to **assess the simultaneous coexistence of these solutions to avoid contradictory effects or "interferences"**.
-
 # Deployment Incentives {#sec-inc}
 
 ## Networks

draft-brw-scone-throughput-advice-blob.md

@@ -50,11 +50,7 @@ informative:
 
 --- abstract
 
-Traffic exchanged over a network may be subject to rate-limit policies.
-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).
-
+Traffic exchanged over a network may be subject to rate-limit policies for various operational reasons.
 This document specifies a generic object that can be used by mechanims for hosts
 to dynamically discover network rate-limit policies. This information is then
 passed to applications that might adjust their behaviors accordingly. The design of the object is independent of
@@ -108,7 +104,9 @@ the PE-side of a network attachment is specified in {{?I-D.ietf-opsawg-ntw-attac
 The required set of parameters to provision a network attachment is a function of the 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.
 
 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. Rate-limits are usually
+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}}).
 
 {{sec-blob}} 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.
@@ -291,10 +289,7 @@ TC (Traffic Category):
 : The following values are supported:
 
   + "0": All traffic. This is the default value.
-  + "1": Streaming
-  + "2": Real-time
-  + "3": Bulk traffic
-  + 4-63: Unassigned values. See {{sec-iana-tc}}.
+  + 1-63: Unassigned values. See {{sec-iana-tc}}.
 
 Committed Information Rate (CIR) (Mbps):
 : Specifies the maximum number of bits that a network can receive or
@@ -475,10 +470,7 @@ The initial values of this registry is provided in {{iana-tc}}.
 
 |Value|     Description|     Reference|
 |0| All traffic|This-Document|
-|1| Streaming|This-Document|
-|2| Real-time|This-Document|
-|3| Bulk traffic| |
-|4-63| Unassigned| |
+|1-63| Unassigned| |
 {: #iana-tc title="Traffic Category Values"}
 
 The allocation policy of this new registry is "IETF Review" ({{Section 4.8 of !RFC8126}}).