SCONE Solution Analysis
draft-brw-scone-analysis-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 | Dan Wing , Tirumaleswar Reddy.K , Sridharan Rajagopalan , Luis M. Contreras | ||
| Last updated | 2025-04-27 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| 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-analysis-01
scone D. Wing
Internet-Draft Cloud Software Group
Intended status: Informational T. Reddy
Expires: 30 October 2025 Nokia
S. Rajagopalan
Cloud Software Group
L. Contreras
Telefonica
28 April 2025
SCONE Solution Analysis
draft-brw-scone-analysis-01
Abstract
This document provides an analysis of various SCONE solutions to
share the throughput advice.
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 30 October 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wing, et al. Expires 30 October 2025 [Page 1]
Internet-Draft Solution Analysis April 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Criteria Classification . . . . . . . . . . . . . . . . . . . 3
3. Detailed Analysis . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. MASQUE (to be completed by the authors of MASQUE) . . . . 9
3.2.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Discussion . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. Main Expected Gains . . . . . . . . . . . . . . . . . 9
3.2.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. NRLP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . 9
3.3.2. Discussion . . . . . . . . . . . . . . . . . . . . . 9
3.3.3. Main Expected Gains . . . . . . . . . . . . . . . . . 13
3.3.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4. TRONE (to be completed by the authors of TRONE) . . . . . 13
3.4.1. Key Idea . . . . . . . . . . . . . . . . . . . . . . 13
3.4.2. Discussion . . . . . . . . . . . . . . . . . . . . . 13
3.4.3. Main Expected Gains . . . . . . . . . . . . . . . . . 13
3.4.4. Costs . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Normative References . . . . . . . . . . . . . . . . . . 14
6.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
The document provides an analysis of proposed SCONE solutions to
share the throughput advice. The currently analyzed solutions
(listed in alphabetic order) are as follows:
MASQUE: "MASQUE extension for signaling throughput advice"
[I-D.ihlar-scone-masque-mediabitrate]
See Section 3.2.
Wing, et al. Expires 30 October 2025 [Page 2]
Internet-Draft Solution Analysis April 2025
NRLP: "Discovery of Network Rate-Limit Policies (NRLPs)"
[I-D.brw-scone-rate-policy-discovery]
See Section 3.3.
TRONE: "Transparent Rate Optimization for Network Endpoints (TRONE)
Protocol" [I-D.thoji-scone-trone-protocol]
See Section 3.4.
2. Criteria Classification
The following categories are used to classify the various criteria:
Security/Privacy (Sec): Indicates whether this impacts security/
privacy. Some of the criteria that are classified as security-
related may also have implications on the efficiency of sharing an
advice (e.g., as that is likely to be ignored).
Some security/privacy criteria are as follows:
* Zero-trust security: Only authorized network elements must
provide the throughput advice.
* Privacy: Indicates whether a solution does not reveal any
details about the app or server identity.
* Mobility: Indicates whether a solution supports guards against
a malicious app that keeps changing the 5-tuple to evade rate-
limit enforcement by the network.
Deployability (Dep): Captures criteria that are important for
unlocking the deployment of a solution at both network and host
sides.
A deployability hurdle would be typically the misalignment of
incentives between those receiving the benefit vs. those bearing
the cost of providing the benefit (Section 3.3 of
[I-D.narten-radir-problem-statement]). For example, the sender of
the advice should see (immediate) benefits.
Some other deployability criteria are as follows:
* Fate sharing: reflects whether the mechanism used to advertise
the throughput advice shares the fate of the rest of the
network configuration on the host.
Wing, et al. Expires 30 October 2025 [Page 3]
Internet-Draft Solution Analysis April 2025
* Atomic configuration: Indicates whether the throughput advice
can be learned using very few packets and whether changes to
the policy require sharing the entire policy or just the
relevant part.
Performance (Per): May impact the performance of the network device
that enables the solution and/or the performance of the flow.
Service Interference (Int): Captures implications on other services
(e.g., side effects).
For example, tweaking MTU may have an implication on all the flows
that share the same network attachment, not only those that
consumes an advice. Likewise, requiring address sharing has a
plenty of issues that are discussed in [RFC6269]. Also, relying
upon an explicit proxy would penalize the proxy which could serve
both good and 'bad' clients (e.g., launching Layer 7 DDoS
attacks).
Functional (Fun): Characterizes the functional capabilities offered
by activating a solution.
Some examples of functional criteria are as follows:
* Updatability: indicates whether a solution allows to update
hosts with policy changes at any time.
* Path coupled signaling/Path decoupled signaling: Indicates
whether solution allows for the entity to share the advice be
on-path or off-path. This criterion is also meant to assess
the deployment flexibility offered by a solution.
* Support cascaded environments: Rate-limits may be enabled at
several levels. For example, rate-limits may be enforced on
the CPE in the home network for the endpoints attached to it
and in the provider network to rate-limit the traffic from the
subscriber. This criterion indicates whether such setups are
supported.
A criterion may belong to one or more categories.
+==================================+=====+=====+=====+=====+=====+
| Criteria | Sec | Dep | Per | Int | Fun |
+==================================+=====+=====+=====+=====+=====+
| Protocol ossification | | | | | X |
+----------------------------------+-----+-----+-----+-----+-----+
| Zero-trust security | X | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
Wing, et al. Expires 30 October 2025 [Page 4]
Internet-Draft Solution Analysis April 2025
| Privacy | X | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Guard against random advice | X | | | | |
| injection by an on-path attacker | | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Mobility (guard against changing | X | | | | X |
| 5-tuple) | | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Require guards against app abuse | X | | | | X |
+----------------------------------+-----+-----+-----+-----+-----+
| Fate sharing | | X | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Atomic configuration | | X | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Updatability | | | | | X |
+----------------------------------+-----+-----+-----+-----+-----+
| Integration with network | | X | | | |
| management tools | | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Applicable to QUIC | | | | | X |
+----------------------------------+-----+-----+-----+-----+-----+
| Applicable to any application | | | | | X |
+----------------------------------+-----+-----+-----+-----+-----+
| Require an OS API | | X | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Requires PvD | | X | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Support cascaded environments | | | | | X |
+----------------------------------+-----+-----+-----+-----+-----+
| Path coupled signaling | | X | | | X |
+----------------------------------+-----+-----+-----+-----+-----+
| Path decoupled signaling | | X | | | X |
+----------------------------------+-----+-----+-----+-----+-----+
| Traffic direction (h2n, n2h, | | | | | X |
| both) | | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Per-host policies | | | | | X |
+----------------------------------+-----+-----+-----+-----+-----+
| Per-subscriber policies | | | | | X |
+----------------------------------+-----+-----+-----+-----+-----+
| Extendable | | | | | X |
+----------------------------------+-----+-----+-----+-----+-----+
| Require data plane upgrade/ | | X | | | |
| change | | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Require transport payload | | X | | | |
| inspection (network) | | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
Wing, et al. Expires 30 October 2025 [Page 5]
Internet-Draft Solution Analysis April 2025
| Require transport payload | | X | | | |
| inspection (host) | | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Require flow inspection and | X | | | | |
| tracking (network) | | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Require steering policies on the | | X | | | |
| host | | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Depend on the server to consume | | X | | | |
| the signal | | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Impact the connection setup | | | | | X |
| delay | | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Require the identity of the | X | | | | X |
| target server | | | | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Require MTU tweaking | | X | | X | |
+----------------------------------+-----+-----+-----+-----+-----+
| Incur multi-layer encryption | | X | X | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Incur nested congestion control | | X | X | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Incur multiple round-trips | | X | X | | |
+----------------------------------+-----+-----+-----+-----+-----+
| Forwarding peformance impact | | X | X | X | |
+----------------------------------+-----+-----+-----+-----+-----+
| IP address sharing issues | | X | | X | |
+----------------------------------+-----+-----+-----+-----+-----+
| Penalizing the proxy | | X | | X | |
+----------------------------------+-----+-----+-----+-----+-----+
Table 1: Criteria Classification
3. Detailed Analysis
3.1. Summary
+==================================+========+========+=======+======+
| Criteria | MASQUE | NRLP | TRONE | Else |
+==================================+========+========+=======+======+
| Protocol | TBC | N | TBC | TBC |
| ossification | | | | |
+----------------------------------+--------+--------+-------+------+
| Zero-trust security | TBC | Y | TBC | TBC |
+----------------------------------+--------+--------+-------+------+
| Privacy | TBC | Y | TBC | TBC |
Wing, et al. Expires 30 October 2025 [Page 6]
Internet-Draft Solution Analysis April 2025
+----------------------------------+--------+--------+-------+------+
| Guard against random | TBC | Y | TBC | TBC |
| advice injection by | | | | |
| an on-path attacker | | | | |
+----------------------------------+--------+--------+-------+------+
| Mobility (guard | TBC | Y | TBC | TBC |
| against changing | | | | |
| 5-tuple) | | | | |
+----------------------------------+--------+--------+-------+------+
| Require guards | TBC | Y | TBC | TBC |
| against app abuse | | | | |
+----------------------------------+--------+--------+-------+------+
| Fate sharing | TBC | Y | TBC | TBC |
+----------------------------------+--------+--------+-------+------+
| Atomic configuration | TBC | Y | TBC | TBC |
+----------------------------------+--------+--------+-------+------+
| Updatability | TBC | Y | TBC | TBC |
+----------------------------------+--------+--------+-------+------+
| Integration with | TBC | Y | TBC | TBC |
| network management | | | | |
| tools | | | | |
+----------------------------------+--------+--------+-------+------+
| Applicable to QUIC | TBC | Y | TBC | TBC |
+----------------------------------+--------+--------+-------+------+
| Applicable to any | TBC | Y | TBC | TBC |
| application | | | | |
+----------------------------------+--------+--------+-------+------+
| Require an OS API | TBC | Y/N(p) | TBC | TBC |
+----------------------------------+--------+--------+-------+------+
| Requires PvD | TBC | Y(p)/N | TBC | TBC |
+----------------------------------+--------+--------+-------+------+
| Support cascaded | TBC | Y | TBC | TBC |
| environments | | | | |
+----------------------------------+--------+--------+-------+------+
| Path coupled | TBC | Y | TBC | TBC |
| signaling | | | | |
+----------------------------------+--------+--------+-------+------+
| Path decoupled | TBC | Y | TBC | TBC |
| signaling | | | | |
+----------------------------------+--------+--------+-------+------+
| Traffic direction | TBC | Y | TBC | TBC |
| (h2n, n2h, both) | | | | |
+----------------------------------+--------+--------+-------+------+
| Per-host policies | TBC | Y | TBC | TBC |
+----------------------------------+--------+--------+-------+------+
| Per-subscriber | TBC | Y | TBC | TBC |
| policies | | | | |
+----------------------------------+--------+--------+-------+------+
Wing, et al. Expires 30 October 2025 [Page 7]
Internet-Draft Solution Analysis April 2025
| Extendable | TBC | Y | TBC | TBC |
+----------------------------------+--------+--------+-------+------+
| Require data plane | TBC | N | TBC | TBC |
| upgrade/change | | | | |
+----------------------------------+--------+--------+-------+------+
| Require transport | TBC | N | TBC | TBC |
| payload inspection | | | | |
| (network) | | | | |
+----------------------------------+--------+--------+-------+------+
| Require transport | TBC | N | TBC | TBC |
| payload inspection | | | | |
| (host) | | | | |
+----------------------------------+--------+--------+-------+------+
| Require flow | TBC | N | TBC | TBC |
| inspection and | | | | |
| tracking (network) | | | | |
+----------------------------------+--------+--------+-------+------+
| Require steering | TBC | N | TBC | TBC |
| policies on the host | | | | |
+----------------------------------+--------+--------+-------+------+
| Depend on the server | TBC | N | TBC | TBC |
| to consume the | | | | |
| signal | | | | |
+----------------------------------+--------+--------+-------+------+
| Impact the | TBC | N | TBC | TBC |
| connection setup | | | | |
| delay | | | | |
+----------------------------------+--------+--------+-------+------+
| Require the identity | TBC | N | TBC | TBC |
| of the target server | | | | |
+----------------------------------+--------+--------+-------+------+
| Require MTU tweaking | TBC | N | TBC | TBC |
+----------------------------------+--------+--------+-------+------+
| Incur multi-layer | TBC | N | TBC | TBC |
| encryption | | | | |
+----------------------------------+--------+--------+-------+------+
| Incur nested | TBC | N | TBC | TBC |
| congestion control | | | | |
+----------------------------------+--------+--------+-------+------+
| Incur multiple | TBC | N | TBC | TBC |
| round-trips | | | | |
+----------------------------------+--------+--------+-------+------+
| Forwarding | TBC | N | TBC | TBC |
| peformance impact | | | | |
+----------------------------------+--------+--------+-------+------+
| IP address sharing | TBC | N | TBC | TBC |
| issues | | | | |
+----------------------------------+--------+--------+-------+------+
Wing, et al. Expires 30 October 2025 [Page 8]
Internet-Draft Solution Analysis April 2025
| Penalizing the proxy | TBC | N | TBC | TBC |
+----------------------------------+--------+--------+-------+------+
Table 2: Analysis Summary
Notes: (p) indicates the assessment when PvD is used as NRLP
mechanism.
3.2. MASQUE (to be completed by the authors of MASQUE)
3.2.1. Key Idea
3.2.2. Discussion
3.2.3. Main Expected Gains
3.2.4. Costs
3.3. NRLP
3.3.1. Key Idea
NRLP leverages existing discovery mechanisms (DHCP, RA, PvD) for
networks to advertise throughout advices. The same generic blob is
used independent of the signaling mechanism. NRLP operates within
the existing network/host trust model.
Also, NRLP does not introduce additional dependency that would hinder
having the benefits of enabling the NRLP feature.
3.3.2. Discussion
Only network elements that are entitled to send DHCP/RA/PvD
configuration are allowed to share the throughput advices. As such,
NRLP has built-in:
* zero-trust model
* Guard against random advice injection
Taking into account that NRLP advices are bound to a traffic
category, NLRP relies upon the OS to enforce the received policies
for applications falling under a traffic category (or all traffic).
In doing so, NRLP adheres to the following:
* Mobility (guard against changing 5-tuple)
Wing, et al. Expires 30 October 2025 [Page 9]
Internet-Draft Solution Analysis April 2025
* Require guards against app abuse: The OS can allocate network
resources more fairly among different processes, with NRLP
signals, ensuring that no single process monopolizes the network.
NRLP meets the following criteria:
* Fate sharing: RA/DHCP are needed anyway so that connectivity is
provided over a network attachment. NRLP ensures that throughput
advices shares the fare of the other network configuration on the
host.
* Atomic configuration: Only one packet (e.g., RA) is required to
share the advice. Also, only a specific portion of the
configuration can be provided.
* Updatability/Proactive signaling: It is possible to change the
policy at any time and notify hosts (e.g., by sending a new RA).
Given that NRLP advices are shared during the establishment of a
network attachment and then as part of the maintenance of the
attachment, NRLP is therefore:
* Applicable to any transport protocol: This allows specifically to
ensure a feature parity for applications that fallback to another
transport protocol (e.g., QUIC to TCP).
* Applicable to QUIC
* Applicable to any application
To that aim:
* RA/DHCP NRLP requires an OS API to expose the signal to
applications, and ensure application fairness.
* If PvD is used, an app only needs to learn the PvD ID from the OS
(which is not specific to NRLP) and the PvD additional information
can be retrieved by the app itself (without any dependency on the
OS).
NRLP leverages existing mechanisms for the provisioning of network
attachments, including supply of the various policies
([I-D.ietf-opsawg-ntw-attachment-circuit]). Also, NRLP leverages AAA
mechanisms (e.g., [RFC9445]). Therefore, NRLP eases:
* Integration with network management tools
One of NRLP flavors:
Wing, et al. Expires 30 October 2025 [Page 10]
Internet-Draft Solution Analysis April 2025
* Requires PvD discovery. This is not required for DHCP/RA.
NRLP does not restrict the deployment options as providers can deploy
distributed or centralized DHCP servers, use relays, enable NRLP RA
in access routers, etc. Similar to other network configuration
purposes, NRLP has the following capabilities:
* Support cascaded environments. The throughput advice can even be
correlated with local conditions or policies as shown, e.g., in
Figure 1.
* Path coupled signaling
* Path decoupled signaling
.------. .--------------------.
| Host +---+ .---. | |
| #1 | | | | | |
'------' +-----+ C | | |
nrlp#2 | P +--------+ Network |
.------. .-----+ E | nrlp#1 | |
| Host | | | | | |
| #2 +---' '---' | |
'------' nrlp#3 | |
'--------------------'
Figure 1: Example of Cascaded NRLPs
The same generic blob is used in NRLP independent of the signaling
mechanism. The blob is designed with the following key
characteristics:
* Traffic direction (h2n, n2h, both): policies for one or both
directions can be supplied.
* Per-host policies: An explicit indication in inserted in the
advice to tag per-host policies.
* Per-subscriber policies: An explicit indication in inserted in the
advice to tag per-subscriber policies. This covers deployment
scenarios such as tethering or CPE-based service offerings.
* Provide provisions for extensions: NLRP includes provisions for
future attributes that are tracked in IANA registries.
Given that NRLP leverages existing control plane mechanisms, NRLP
does not:
Wing, et al. Expires 30 October 2025 [Page 11]
Internet-Draft Solution Analysis April 2025
* Suffer from protocol ossification issues
* Require data plane upgrade/change
* Require transport payload inspection (network)
* Require transport payload inspection (host)
* Require flow inspection and tracking (network)
Also, given that NRLP signals are exchanged before connection
establishment, NRLP does not:
* Depend on the server to consume the signal: NRLP advices are
immediately consumable by applications and do not require
involving a remote server.
* Require the identity of the target server to receive or consume
the advices.
Moreover, NRLP does require any encapsulation or proxy function at
the network. As such, NRLP does not:
* Require steering policies on the host to decide which flows are
eligible to the proxy service.
* Impact the connection setup delay: NRLP signals are available on
bootstrap of a host (and prior to any connection establishment).
* Require MTU tweaking
* Incur multi-layer encryption
* Incur nested congestion control
* Incur multiple round-trips: The signal is immediately available in
one packet (RA NRLP, typically).
* Overhead of unauthenticated re-encryption
* Forwarding performance impact
* IP address sharing issues: NRLP does not require changing the
source IP address used by a host.
* Penalize any network node (a proxy, typically) which could serve
both good and bad clients (e.g., launching Layer 7 DDoS attacks).
Wing, et al. Expires 30 October 2025 [Page 12]
Internet-Draft Solution Analysis April 2025
3.3.3. Main Expected Gains
* Lower deployment barrier to experiment in large scale (no hardware
or software change is needed in network components).
* Schedule network requests (independent of the transport protocol)
more efficiently, preventing network congestion, and improving
overall stability and network performance.
* Unlock new services in local networks and enhance the quality of
experience at the LAN by providing a simple tool to communicate
local policies to hosts.
* Provide a mechanism to assist networks managing the load at the
source and, thus, contribute to better handle network overloads
and optimize the use of resources under non nominal conditions.
3.3.4. Costs
* A simple configuration is required for IPv4: DHCP flavor can be
provided by configuration of custom options. Refer to
[NRLP-WIRE].
* A similar configuration approach can be followed for DHCPv6.
* A minor change to the network is required for NRLP RA: upgrade
configuration of PE nodes with new Neighbor Discovery option.
Note that all IPv6 hosts and networks are already required to
support Neighbor Discovery [RFC4861].
* An API needs to be exposed on the host to share the advice with
applications (e.g., scutil on MacOS). No additional API is needed
if PvD is used.
3.4. TRONE (to be completed by the authors of TRONE)
3.4.1. Key Idea
3.4.2. Discussion
3.4.3. Main Expected Gains
3.4.4. Costs
4. Security Considerations
Security-related criteria are analyzed for each proposed solution.
Wing, et al. Expires 30 October 2025 [Page 13]
Internet-Draft Solution Analysis April 2025
5. IANA Considerations
This document does not make any IANA request.
6. References
6.1. Normative References
[I-D.brw-scone-rate-policy-discovery]
Boucadair, M., Wing, D., Reddy.K, T., Rajagopalan, S.,
Mishra, G. S., Amend, M., and L. M. Contreras, "Discovery
of Network Rate-Limit Policies (NRLPs)", Work in Progress,
Internet-Draft, draft-brw-scone-rate-policy-discovery-02,
16 December 2024, <https://datatracker.ietf.org/doc/html/
draft-brw-scone-rate-policy-discovery-02>.
[I-D.ihlar-scone-masque-mediabitrate]
Ihlar, L. M. and M. Kühlewind, "MASQUE extension for
signaling throughput advice", Work in Progress, Internet-
Draft, draft-ihlar-scone-masque-mediabitrate-02, 3 March
2025, <https://datatracker.ietf.org/doc/html/draft-ihlar-
scone-masque-mediabitrate-02>.
[I-D.thoji-scone-trone-protocol]
Thomson, M., Huitema, C., Oku, K., Joras, M., and L. M.
Ihlar, "Transparent Rate Optimization for Network
Endpoints (TRONE) Protocol", Work in Progress, Internet-
Draft, draft-thoji-scone-trone-protocol-00, 3 March 2025,
<https://datatracker.ietf.org/doc/html/draft-thoji-scone-
trone-protocol-00>.
6.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-16, 23 January 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-
ntw-attachment-circuit-16>.
[I-D.narten-radir-problem-statement]
Narten, T., "On the Scalability of Internet Routing", Work
in Progress, Internet-Draft, draft-narten-radir-problem-
statement-05, 17 February 2010,
<https://datatracker.ietf.org/doc/html/draft-narten-radir-
problem-statement-05>.
Wing, et al. Expires 30 October 2025 [Page 14]
Internet-Draft Solution Analysis April 2025
[NRLP-WIRE]
"Examples of Wire Format Options",
<https://github.com/boucadair/draft-xxx-ac-rate-policy-
discovery/blob/main/example-nrlp-wire-format.md>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/rfc/rfc4861>.
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011,
<https://www.rfc-editor.org/rfc/rfc6269>.
[RFC9445] Boucadair, M., Reddy.K, T., and A. DeKok, "RADIUS
Extensions for DHCP-Configured Services", RFC 9445,
DOI 10.17487/RFC9445, August 2023,
<https://www.rfc-editor.org/rfc/rfc9445>.
Authors' Addresses
Dan Wing
Cloud Software Group Holdings, Inc.
United States of America
Email: danwing@gmail.com
Tirumaleswar Reddy
Nokia
India
Email: kondtir@gmail.com
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
Wing, et al. Expires 30 October 2025 [Page 15]