draft-ietf-mboned-cbacc-02.txt   draft-ietf-mboned-cbacc-03.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Intended status: Standards Track February 01, 2021 Intended status: Standards Track July 10, 2021
Expires: August 5, 2021 Expires: January 11, 2022
Circuit Breaker Assisted Congestion Control Circuit Breaker Assisted Congestion Control
draft-ietf-mboned-cbacc-02 draft-ietf-mboned-cbacc-03
Abstract Abstract
This document specifies Circuit Breaker Assisted Congestion Control This document specifies Circuit Breaker Assisted Congestion Control
(CBACC). CBACC enables fast-trip Circuit Breakers by publishing rate (CBACC). CBACC enables fast-trip Circuit Breakers by publishing rate
metadata about multicast channels from senders to intermediate metadata about multicast channels from senders to intermediate
network nodes or receivers. The circuit breaker behavior is defined network nodes or receivers. The circuit breaker behavior is defined
as a supplement to receiver driven congestion control systems, to as a supplement to receiver driven congestion control systems, to
preserve network health if misbehaving or malicious receiver preserve network health if misbehaving or malicious receiver
applications subscribe to a volume of traffic that exceeds capacity applications subscribe to a volume of traffic that exceeds capacity
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 5, 2021. This Internet-Draft will expire on January 11, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 19 skipping to change at page 2, line 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background and Terminology . . . . . . . . . . . . . . . 4 1.1. Background and Terminology . . . . . . . . . . . . . . . 4
1.2. Venues for Contribution and Discussion . . . . . . . . . 4 1.2. Venues for Contribution and Discussion . . . . . . . . . 4
1.3. Non-obvious doc choices . . . . . . . . . . . . . . . . . 4 1.3. Non-obvious doc choices . . . . . . . . . . . . . . . . . 4
2. Circuit Breaker Behavior . . . . . . . . . . . . . . . . . . 5 2. Circuit Breaker Behavior . . . . . . . . . . . . . . . . . . 5
2.1. Functional Components . . . . . . . . . . . . . . . . . . 5 2.1. Functional Components . . . . . . . . . . . . . . . . . . 5
2.1.1. Bitrate Advertisement . . . . . . . . . . . . . . . . 5 2.1.1. Bitrate Advertisement . . . . . . . . . . . . . . . . 5
2.1.2. Circuit Breaker Node . . . . . . . . . . . . . . . . 5 2.1.2. Circuit Breaker Node . . . . . . . . . . . . . . . . 5
2.1.3. Communication Method . . . . . . . . . . . . . . . . 6 2.1.3. Communication Method . . . . . . . . . . . . . . . . 6
2.1.4. Measurement Function . . . . . . . . . . . . . . . . 6 2.1.4. Measurement Function . . . . . . . . . . . . . . . . 7
2.1.5. Trigger Function . . . . . . . . . . . . . . . . . . 7 2.1.5. Trigger Function . . . . . . . . . . . . . . . . . . 7
2.1.6. Reaction . . . . . . . . . . . . . . . . . . . . . . 8 2.1.6. Reaction . . . . . . . . . . . . . . . . . . . . . . 9
2.1.7. Feedback Control Mechanism . . . . . . . . . . . . . 9 2.1.7. Feedback Control Mechanism . . . . . . . . . . . . . 9
2.2. States . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.2. States . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1. Interface State . . . . . . . . . . . . . . . . . . . 10 2.2.1. Interface State . . . . . . . . . . . . . . . . . . . 10
2.2.2. Flow State . . . . . . . . . . . . . . . . . . . . . 10 2.2.2. Flow State . . . . . . . . . . . . . . . . . . . . . 10
2.3. Implementation Design Considerations . . . . . . . . . . 11 2.3. Implementation Design Considerations . . . . . . . . . . 11
2.3.1. Oversubscription Thresholds . . . . . . . . . . . . . 11 2.3.1. Oversubscription Thresholds . . . . . . . . . . . . . 11
2.3.2. Fairness Functions . . . . . . . . . . . . . . . . . 11 2.3.2. Fairness Functions . . . . . . . . . . . . . . . . . 11
3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 11
3.2. Module . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Module . . . . . . . . . . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4.1. YANG Module Names Registry . . . . . . . . . . . . . . . 13 4.1. YANG Module Names Registry . . . . . . . . . . . . . . . 14
4.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 14 4.2. The XML Registry . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5.1. Metadata Security . . . . . . . . . . . . . . . . . . . . 14 5.1. Metadata Security . . . . . . . . . . . . . . . . . . . . 14
5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 14 5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 15
5.2.1. State Overload . . . . . . . . . . . . . . . . . . . 14 5.2.1. State Overload . . . . . . . . . . . . . . . . . . . 15
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Overjoining . . . . . . . . . . . . . . . . . . . . 17 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. Overjoining . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document defines Circuit Breaker Assisted Congestion Control This document defines Circuit Breaker Assisted Congestion Control
(CBACC). CBACC defines a Network Transport Circuit Breaker (CB), as (CBACC). CBACC defines a Network Transport Circuit Breaker (CB), as
described by [RFC8084]. described by [RFC8084].
The CB behavior defined in this document uses bit-rate metadata about The CB behavior defined in this document uses bit-rate metadata about
multicast data streams coupled with policy, capacity, and load multicast data streams coupled with policy, capacity, and load
information at a network location to prune multicast channels so that information at a network location to prune multicast channels so that
the network's aggregate capacity at that location is not exceeded by the network's aggregate capacity at that location is not exceeded by
the subscribed channels. the subscribed channels.
To communicate the required metadata, this document defines a YANG To communicate the required metadata, this document defines a YANG
[RFC7950] module that augments the DORMS [RFC7950] module that augments the DORMS
[I-D.draft-ietf-mboned-dorms-00] YANG module. DORMS provides a [I-D.draft-ietf-mboned-dorms] YANG module. DORMS provides a
mechanism for senders to publish metadata about the multicast streams mechanism for senders to publish metadata about the multicast streams
they're sending through a RESTCONF service, so that receivers or they're sending through a RESTCONF service, so that receivers or
forwarding nodes can discover and consume the metadata with a set of forwarding nodes can discover and consume the metadata with a set of
standard methods. The CBACC metadata MAY be communicated to standard methods. The CBACC metadata MAY be communicated to
receivers or forwarding nodes by some other method, but the receivers or forwarding nodes by some other method, but the
definition of any alternative methods is out of scope for this definition of any alternative methods is out of scope for this
document. document.
The CB behavior defined in this document matches the description The CB behavior defined in this document matches the description
provided in Section 3.2.3 of [RFC8084] of a unidirectional CB over a provided in Section 3.2.3 of [RFC8084] of a unidirectional CB over a
skipping to change at page 5, line 5 skipping to change at page 4, line 49
the link. Likewise the egress meter and "CB node". the link. Likewise the egress meter and "CB node".
o TBD: might need more and better examples explaining the point in o TBD: might need more and better examples explaining the point in
Section 2.1.5.1? Some reason to believe it's not sufficiently Section 2.1.5.1? Some reason to believe it's not sufficiently
clear... clear...
o Another TBD: consider Dino's suggestion from 2020-04-09 to include o Another TBD: consider Dino's suggestion from 2020-04-09 to include
an operational considerations section that addresses some possible an operational considerations section that addresses some possible
optimizations for CB placement and configuration. optimizations for CB placement and configuration.
o TBD: add a section walking through the requirements in
https://datatracker.ietf.org/doc/html/rfc8084#section-4 [1] and
explaining how this matches.
o I'm unclear on whether https://datatracker.ietf.org/doc/html/
rfc8407#section-3.8.2 [2] applies here, such that providing an
augmentation inside the DORMS namespace causes an update to the
DORMS document.
2. Circuit Breaker Behavior 2. Circuit Breaker Behavior
2.1. Functional Components 2.1. Functional Components
This section maps the functional components described in Section 3.1 This section maps the functional components described in Section 3.1
of [RFC8084] to the operational components of the CBACC CB defined by of [RFC8084] to the operational components of the CBACC CB defined by
this document. this document.
2.1.1. Bitrate Advertisement 2.1.1. Bitrate Advertisement
The metadata provides an advertised maximum data bit-rate, namely the The metadata provides an advertised maximum data bit-rate, namely the
"max-bits-per-second" field in the YANG model in Section 3. This is "max-speed" field in the YANG model in Section 3. This is a self-
a self-report by the sender about the maximum amount of traffic a report by the sender about the maximum amount of traffic a sender
sender will send within the interval given by the "data-rate-window" will send within any time interval given by the "data-rate-window"
field, which is the measurement interval. field, which is the measurement interval for the CB. This value
refers to the total IP Payload data for all packets in the same
(S,G), and its units are in kilobits per second.
The sender MUST NOT send more data for a data stream than the amount The sender MUST NOT send more data for a data stream than the amount
of data declared according to its advertised data rate within any of data declared according to its advertised data rate within any
measurement window, and it's RECOMMENDED for the sender to provide measurement window, and it's RECOMMENDED for the sender to provide
some margin to account for forwarding bursts. If a CB node observes some margin to account for the possibility of burst forwarding after
a higher data rate within any measurement window, it MAY circuit- traffic encounters a non-empty queue, e.g. as sometimes observed with
break that flow immediately. ACK compression (see [ZSC91] for a description of the phenomenon).
If a CB node observes a higher data rate transmitted within any
measurement window, it MAY circuit-break that flow immediately.
In the terminology of [RFC8084], this qualifies as an ingress meter. In the terminology of [RFC8084], the bitrate advertisement qualifies
as an ingress meter.
2.1.2. Circuit Breaker Node 2.1.2. Circuit Breaker Node
A circuit breaker node (CB node) is a location in a network where the A circuit breaker node (CB node) is a location in a network where the
costraints of the network and the observations about active traffic costraints of the network and the observations about active traffic
are compared to the bitrate advertisement in order to make the are compared to the bitrate advertisement in order to make the
decision loop about when and whether to perform the circuit breaking decision loop about when and whether to perform the circuit breaking
behavior. In the terminology of [RFC8084], the CB node qualifies as behavior. In the terminology of [RFC8084], the CB node qualifies as
an egress meter. an egress meter.
skipping to change at page 6, line 10 skipping to change at page 6, line 19
with CBACC metadata. with CBACC metadata.
4. The observed received data rates of subscribed multicast channels 4. The observed received data rates of subscribed multicast channels
without CBACC metadata. without CBACC metadata.
5. The observed received data rates of competing non-multicast 5. The observed received data rates of competing non-multicast
traffic. traffic.
6. The loss rate for subscribed multicast channels, when available. 6. The loss rate for subscribed multicast channels, when available.
The loss rate is only sometimes observable at a CB node; for The loss rate is only sometimes observable at a CB node; for
example, when using AMBI [I-D.draft-ietf-mboned-ambi-00], or when example, when using AMBI [I-D.draft-ietf-mboned-ambi], or when
the data stream carries a protocol that is known to the CB node the data stream carries a protocol that is known to the CB node
by some out of band means, and whose traffic can be monitored for by some out of band means, and whose traffic can be monitored for
loss. When available, the loss rates may be used. loss. When available, the loss rates may be used.
Note that any on-path router can behave as a CB node, even though Note that any on-path router can behave as a CB node, even though
there may be other CB nodes downstream or upstream covering the same there may be other CB nodes downstream or upstream covering the same
data streams. When viewing CB nodes as egress meters in the context data streams. When viewing CB nodes as egress meters in the context
of [RFC8084], it's important to recall there's not a single egress of [RFC8084], it's important to recall there's not a single egress
meter in the network, but rather an egress meter per CB node, meter in the network, but rather an egress meter per CB node,
representing potentially multiple overlaid circuit breakers that may representing potentially multiple overlaid circuit breakers that may
skipping to change at page 6, line 44 skipping to change at page 7, line 4
CBACC generally operates at a CB node, where metrics such as those CBACC generally operates at a CB node, where metrics such as those
described in Section 2.1.2 are available through system calls, or by described in Section 2.1.2 are available through system calls, or by
communication with various locally deployable system monitoring communication with various locally deployable system monitoring
applications. However, the CBACC processing can equivalently occur applications. However, the CBACC processing can equivalently occur
on a separate device that can monitor statistics gathered at a CB on a separate device that can monitor statistics gathered at a CB
node, as long as the necessary control functions to trigger the CB node, as long as the necessary control functions to trigger the CB
can be invoked. can be invoked.
The communication path defined in this document for the CB node to The communication path defined in this document for the CB node to
obtain the bitrate advertisement in Section 2.1.1 is the use of DORMS obtain the bitrate advertisement in Section 2.1.1 is the use of DORMS
[I-D.draft-ietf-mboned-dorms-00]. Other methods MAY be used as well
or instead, but are out of scope for this document. [I-D.draft-ietf-mboned-dorms]. Other methods MAY be used as well or
instead, but are out of scope for this document.
2.1.4. Measurement Function 2.1.4. Measurement Function
The measurement function maintains a few values for each interface, The measurement function maintains a few values for each interface,
computed from the metrics described in Section 2.1.2 and computed from the metrics described in Section 2.1.2 and
Section 2.1.1: Section 2.1.1:
1. The aggregate advertised maximum bit-rate capacity consumed by 1. The aggregate advertised maximum bit-rate capacity consumed by
CBACC data streams. This is the sum of the max-bit-rate values CBACC data streams. This is the sum of the max-speed values in
in the CBACC metadata for all data streams subscribed through an the CBACC metadata for all data streams subscribed through an
interface interface
2. An oversubscription threshold for each interface. The 2. An oversubscription threshold for each interface. The
oversubscription threshold will be determined differently for CB oversubscription threshold will be determined differently for CB
nodes in different contexts. In some network devices, it might nodes in different contexts. In some network devices, it might
be as simple as an administratively configured absolute value or be as simple as an administratively configured absolute value or
proportion of an interface's capacity. For other situations, proportion of an interface's capacity. For other situations,
like a CB node operating in a context with loss visibility, it like a CB node operating in a context with loss visibility, it
could be a dynamically changing value that grows when data could be a dynamically changing value that grows when data
streams are successfully subscribed and receiving data without streams are successfully subscribed and receiving data without
loss, and shrinks as loss is observed across subscribed data loss, and shrinks as loss is observed across subscribed data
streams. The oversubscription threshold calculation could also streams. The oversubscription threshold calculation could also
incorporate other information like out-of-band path capacity incorporate other information like out-of-band path capacity
measurements with [PathChirp], if available. measurements with bandwidth detection techniques such as
[PathChirp] or [CapProbe].
This document covers some non-normative examples of valid This document covers some non-normative examples of valid
oversubscription threshold functions in Section 2.3.1. In oversubscription threshold functions in Section 2.3.1. In
general, the oversubscription threshold is the primary parameter general, the oversubscription threshold is the primary parameter
that different CBs in different contexts can tune to provide the that different CBs in different contexts can tune to provide the
safety guarantees necessary for their context. safety guarantees necessary for their context.
2.1.5. Trigger Function 2.1.5. Trigger Function
The trigger function fires when the aggregate advertised maximum bit- The trigger function fires when the aggregate advertised maximum bit-
skipping to change at page 8, line 7 skipping to change at page 8, line 16
CB node. CB node.
Flows from a single sender MUST be ordered according to their Flows from a single sender MUST be ordered according to their
priority field from the CBACC metadata when compared with each other. priority field from the CBACC metadata when compared with each other.
This takes precedence over the fairness function ordering, since This takes precedence over the fairness function ordering, since
certain flows from the same sender may need strict priority over certain flows from the same sender may need strict priority over
others. others.
For example, consider a sender using File Delivery over For example, consider a sender using File Delivery over
Unidirectional Transport (FLUTE, defined in [RFC6726]) that sends Unidirectional Transport (FLUTE, defined in [RFC6726]) that sends
File Delivery Table Instances (see section 3.2 of [RFC6726]) in one File Delivery Table (FDT) Instances (see section 3.2 of [RFC6726]) in
(S,G) and data for the various referenced files in other (S,G)s. In one (S,G) and data for the various referenced files in other (S,G)s.
this case the data for the files will not be consumable without the In this case the data for the files will not be consumable without
(S,G) containing the FDT. Other transport protocols may similarly the (S,G) containing the FDT. Other transport protocols may
send control information (often with a lower bitrate) on one channel, similarly send control information (often with a lower bitrate) on
and data information on another. In these cases, the sender may need one channel, and data information on another. In these cases, the
to ensure that data channels are only available when the control sender may need to ensure that data channels are only available when
channels are also available. the control channels are also available.
When comparing flows between senders, (S,G)s from the same sender When comparing flows between senders, (S,G)s from the same sender
with different priorities should be treated as aggregated (S,G)s with with different priorities should be treated as aggregated (S,G)s with
regard to their declared bitrate consumption, to ensure that if any regard to their declared bitrate consumption, to ensure that if any
flows from the same sender need to be pruned by the circuit-breaker, flows from the same sender need to be pruned by the circuit-breaker,
the least preferred priority flows from that sender are pruned first. the least preferred priority flows from that sender are pruned first.
Between-sender flows and flows from the same sender with the same Between-sender flows and flows from the same sender with the same
priority are ordered according to the fairness function. TBD: need priority are ordered according to the fairness function. TBD: need
to work thru detsils, this does not work as written. Sample fairness to work thru detsils, this does not work as written. Sample fairness
skipping to change at page 11, line 37 skipping to change at page 12, line 7
is given in Section 2.3 of [RFC5166]. is given in Section 2.3 of [RFC5166].
3. YANG Module 3. YANG Module
3.1. Tree Diagram 3.1. Tree Diagram
The tree diagram below follows the notation defined in [RFC8340]. The tree diagram below follows the notation defined in [RFC8340].
module: ietf-cbacc module: ietf-cbacc
augment /dorms:metadata/dorms:sender/dorms:group: augment /dorms:dorms/dorms:metadata/dorms:sender/dorms:group:
+--rw cbacc! +--rw cbacc!
+--rw max-bits-per-second uint32 +--rw max-speed uint32
+--rw max-mss? uint16 +--rw max-packet-size? uint16
+--rw data-rate-window? uint32 +--rw data-rate-window? uint32
+--rw priority? uint16 +--rw priority? uint16
3.2. Module 3.2. Module
<CODE BEGINS> file ietf-cbacc@2021-02-01.yang <CODE BEGINS> file ietf-cbacc@2021-07-11.yang
module ietf-cbacc { module ietf-cbacc {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-cbacc"; namespace "urn:ietf:params:xml:ns:yang:ietf-cbacc";
prefix "ambi"; prefix "cbacc";
import ietf-dorms { import ietf-dorms {
prefix "dorms"; prefix "dorms";
reference "I-D.jholland-mboned-dorms"; reference "I-D.jholland-mboned-dorms";
} }
organization "IETF"; organization "IETF";
contact contact
"Author: Jake Holland "Author: Jake Holland
<mailto:jholland@akamai.com> <mailto:jholland@akamai.com>
"; ";
description description
"Copyright (c) 2019 IETF Trust and the persons identified as "Copyright (c) 2019 IETF Trust and the persons identified as
authors of the code. All rights reserved. authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(https://trustee.ietf.org/license-info). (https://trustee.ietf.org/license-info).
This version of this YANG module is part of This version of this YANG module is part of
draft-jholland-mboned-cbacc. See the internet draft for full draft-jholland-mboned-cbacc. See the internet draft for full
legal notices. legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as 'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here. they appear in all capitals, as shown here.
This module contains the definition for bandwidth consumption This module contains the definition for bandwidth consumption
metadata for SSM channels, as an extension to DORMS metadata for SSM channels, as an extension to DORMS
(draft-jholland-mboned-dorms)."; (draft-ietf-mboned-dorms).";
revision 2021-01-15 { revision 2021-07-08 {
description "Initial revision as an extension."; description "Draft version, post-early-review.";
reference reference
""; "draft-ietf-mboned-cbacc";
} }
augment augment
"/dorms:metadata/dorms:sender/dorms:group" { "/dorms:dorms/dorms:metadata/dorms:sender/dorms:group" {
description "Definition of the manifest stream providing description "Definition of the manifest stream providing
integrity info for the data stream"; integrity info for the data stream";
container cbacc { container cbacc {
presence "cbacc-enabled flow"; presence "CBACC-enabled flow";
description description
"Information to enable fast-trip circuit breakers"; "Information to enable fast-trip circuit breakers";
leaf max-bits-per-second { leaf max-speed {
type uint32; type uint32;
mandatory true; units "kilobits/second";
description "Maximum bitrate for this stream, in Kilobits mandatory true;
of IP packet data (including headers) of native description "Maximum bitrate for this stream, in Kilobits
multicast traffic per second"; of IP packet data (including headers) of native
} multicast traffic per second";
leaf max-mss { }
type uint16; leaf max-packet-size {
default 1400; type uint16;
description "Maximum payload size, in bytes"; default 1400;
} description "Maximum IP payload size, in octets.";
leaf data-rate-window { }
type uint32; leaf data-rate-window {
default 2000; type uint32;
description units "milliseconds";
"Time window over which data rate is guaranteed, default 2000;
in milliseconds."; description
/* TBD: range limits? */ "Time window over which data rate is guaranteed,
} in milliseconds.";
leaf priority { /* TBD: range limits? */
type uint16; }
default 256; leaf priority {
description type uint16;
"The relative preference level for keeping this flow default 256;
compared to other flows from this sender (higher description
value is more preferred to keep)"; "The relative preference level for keeping this flow
} compared to other flows from this sender (higher
value is more preferred to keep)";
} }
} }
}
} }
<CODE ENDS> <CODE ENDS>
4. IANA Considerations 4. IANA Considerations
4.1. YANG Module Names Registry 4.1. YANG Module Names Registry
This document adds one YANG module to the "YANG Module Names" This document adds one YANG module to the "YANG Module Names"
registry maintained at <https://www.iana.org/assignments/yang- registry maintained at <https://www.iana.org/assignments/yang-
skipping to change at page 14, line 22 skipping to change at page 14, line 41
This document adds the following registration to the "ns" subregistry This document adds the following registration to the "ns" subregistry
of the "IETF XML Registry" defined in [RFC3688], referencing this of the "IETF XML Registry" defined in [RFC3688], referencing this
document. document.
URI: urn:ietf:params:xml:ns:yang:ietf-cbacc URI: urn:ietf:params:xml:ns:yang:ietf-cbacc
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
5. Security Considerations 5. Security Considerations
TBD: Yang Doctor review from Reshad said this should "mention the
YANG data nodes". I think this means "do what
https://tools.ietf.org/html/rfc8407#section-3.7 says"?
5.1. Metadata Security 5.1. Metadata Security
Be sure to authenticate the metadata. See DORMS security Be sure to authenticate the metadata. See DORMS security
considerations, and don't accept unauthenticated metadata if using an considerations, and don't accept unauthenticated metadata if using an
alternative means. alternative means.
5.2. Denial of Service 5.2. Denial of Service
5.2.1. State Overload 5.2.1. State Overload
skipping to change at page 15, line 4 skipping to change at page 15, line 29
The same techniques described in Section 3.1 of [RFC4609] can be used The same techniques described in Section 3.1 of [RFC4609] can be used
to help mitigate this attack, for much the same reasons. It is to help mitigate this attack, for much the same reasons. It is
RECOMMENDED that network operators implement measures to mitigate RECOMMENDED that network operators implement measures to mitigate
such attacks. such attacks.
6. Acknowledgements 6. Acknowledgements
Many thanks to Devin Anderson, Ben Kaduk, Cheng Jin, Scott Brown, Many thanks to Devin Anderson, Ben Kaduk, Cheng Jin, Scott Brown,
Miroslav Ponec, Bob Briscoe, Lenny Giuliani, Christian Worm Miroslav Ponec, Bob Briscoe, Lenny Giuliani, Christian Worm
Mortensen, and Dino Farinacci for their thoughtful comments and Mortensen, Dino Farinacci, and Reshad Rahman for their thoughtful
contributions. comments and contributions.
7. References 7. References
7.1. Normative References 7.1. Normative References
[I-D.draft-ietf-mboned-ambi-00] [I-D.draft-ietf-mboned-ambi]
Holland, J. and K. Rose, "Asymmetric Manifest Based Holland, J. and K. Rose, "Asymmetric Manifest Based
Integrity", draft-ietf-mboned-ambi-00 (work in progress), Integrity", draft-ietf-mboned-ambi-01 (work in progress),
March 2020. October 2020.
[I-D.draft-ietf-mboned-dorms-00] [I-D.draft-ietf-mboned-dorms]
Holland, J., "Discovery Of Restconf Metadata for Source- Holland, J., "Discovery Of Restconf Metadata for Source-
specific multicast", draft-ietf-mboned-dorms-00 (work in specific multicast", draft-ietf-mboned-dorms-01 (work in
progress), March 2020. progress), October 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016, RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>. <https://www.rfc-editor.org/info/rfc7950>.
skipping to change at page 15, line 48 skipping to change at page 16, line 27
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>. <https://www.rfc-editor.org/info/rfc8340>.
7.2. Informative References 7.2. Informative References
[CapProbe]
Kapoor, R., Chen, L., Lao, L., Gerla, M., and M. Sanadidi,
"CapProbe: A Simple and Accurate Capacity Estimation
Technique", September 2004.
[FLID-DL] Byers, J., Horn, G., Luby, M., Mitzenmacher, M., Shaver, [FLID-DL] Byers, J., Horn, G., Luby, M., Mitzenmacher, M., Shaver,
W., and IEEE, "FLID-DL: congestion control for layered W., and IEEE, "FLID-DL: congestion control for layered
multicast", DOI 10.1109/JSAC.2002.803998, n.d., multicast", DOI 10.1109/JSAC.2002.803998, n.d.,
<https://ieeexplore.ieee.org/document/1038584>. <https://ieeexplore.ieee.org/document/1038584>.
[PathChirp] [PathChirp]
Ribeiro, V., Riedi, R., Baraniuk, R., Navratil, J., Ribeiro, V., Riedi, R., Baraniuk, R., Navratil, J.,
Cottrell, L., Department of Electrical and Computer Cottrell, L., Department of Electrical and Computer
Engineering Rice University, and SLAC/SCS-Network Engineering Rice University, and SLAC/SCS-Network
Monitoring, Stanford University, "pathChirp: Efficient Monitoring, Stanford University, "pathChirp: Efficient
skipping to change at page 17, line 26 skipping to change at page 18, line 9
multicast congestion control algorithm", 1999. multicast congestion control algorithm", 1999.
[RLM] McCanne, S., Jacobson, V., Vetterli, M., University of [RLM] McCanne, S., Jacobson, V., Vetterli, M., University of
California, Berkeley, and Lawrence Berkeley National California, Berkeley, and Lawrence Berkeley National
Laboratory, "Receiver-driven Layered Multicast", 1995. Laboratory, "Receiver-driven Layered Multicast", 1995.
[SMCC] Kwon, G., Byers, J., and Computer Science Department, [SMCC] Kwon, G., Byers, J., and Computer Science Department,
Boston University, "Smooth Multirate Multicast Congestion Boston University, "Smooth Multirate Multicast Congestion
Control", 2002. Control", 2002.
[ZSC91] Zhang, L., Shenker, S., and D. Clark, "Observations and
Dynamics of a Congestion Control Algorithm: The Effects of
Two-Way Traffic", Proc. ACM SIGCOMM, ACM Computer
Communications Review (CCR), Vol 21, No 4, pp.133-147. ,
1991.
7.3. URIs
[1] https://datatracker.ietf.org/doc/html/rfc8084#section-4
[2] https://datatracker.ietf.org/doc/html/rfc8407#section-3.8.2
Appendix A. Overjoining Appendix A. Overjoining
[RFC8085] describes several remedies for unicast congestion control [RFC8085] describes several remedies for unicast congestion control
under UDP, even though UDP does not itself provide congestion under UDP, even though UDP does not itself provide congestion
control. In general, any network node under congestion could in control. In general, any network node under congestion could in
theory collect evidence that a unicast flow's sending rate is not theory collect evidence that a unicast flow's sending rate is not
responding to congestion, and would then be justified in circuit- responding to congestion, and would then be justified in circuit-
breaking it. breaking it.
With multicast IP, the situation is different, especially in the With multicast IP, the situation is different, especially in the
 End of changes. 43 change blocks. 
125 lines changed or deleted 165 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/