draft-ietf-mboned-cbacc-01.txt   draft-ietf-mboned-cbacc-02.txt 
Mboned J. Holland Mboned J. Holland
Internet-Draft Akamai Technologies, Inc. Internet-Draft Akamai Technologies, Inc.
Intended status: Standards Track October 30, 2020 Intended status: Standards Track February 01, 2021
Expires: May 3, 2021 Expires: August 5, 2021
Circuit Breaker Assisted Congestion Control Circuit Breaker Assisted Congestion Control
draft-ietf-mboned-cbacc-01 draft-ietf-mboned-cbacc-02
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 May 3, 2021. This Internet-Draft will expire on August 5, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 23 skipping to change at page 2, line 23
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 . . . . . . . . . . . . . . . . 6
2.1.5. Trigger Function . . . . . . . . . . . . . . . . . . 7 2.1.5. Trigger Function . . . . . . . . . . . . . . . . . . 7
2.1.6. Reaction . . . . . . . . . . . . . . . . . . . . . . 8 2.1.6. Reaction . . . . . . . . . . . . . . . . . . . . . . 8
2.1.7. Feedback Control Mechanism . . . . . . . . . . . . . 9 2.1.7. Feedback Control Mechanism . . . . . . . . . . . . . 9
2.2. States . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
4.1. YANG Module Names Registry . . . . . . . . . . . . . . . 13 4.1. YANG Module Names Registry . . . . . . . . . . . . . . . 13
skipping to change at page 8, line 23 skipping to change at page 8, line 23
to ensure that data channels are only available when the control to ensure that data channels are only available when the control
channels are also available. 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. The priority are ordered according to the fairness function. TBD: need
fairness function can be different for CBs in different contexts. to work thru detsils, this does not work as written. Sample fairness
function would reward senders for splitting a flow in 2 (more total
subscribers). Maybe should count offload instead? This has trouble
from favoring padding in your flow, but is (i think?) dominated by
subscriber count where that's known. The fairness function can be
different for CBs in different contexts.
A CBACC CB implementation SHOULD provide mechanisms for A CBACC CB implementation SHOULD provide mechanisms for
administrative controls to configure explicit biases, as this may be administrative controls to configure explicit biases, as this may be
necessary to support Service Level Agreements for specific events or necessary to support Service Level Agreements for specific events or
providers, or to block or de-prioritize channels with historically providers, or to block or de-prioritize channels with historically
known misbehavior. known misbehavior.
Subject to the above constraints, where possible the default fairness Subject to the above constraints, where possible the default fairness
behavior SHOULD favor streams with many receivers over streams with behavior SHOULD favor streams with many receivers over streams with
few receivers, and streams with a low bit-rate over streams with a few receivers, and streams with a low bit-rate over streams with a
skipping to change at page 11, line 34 skipping to change at page 11, line 36
An overview of some other approaches to appropriate fairness metrics An overview of some other approaches to appropriate fairness metrics
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/dorms:udp-stream:
augment /dorms:metadata/dorms:sender/dorms:group:
+--rw cbacc! +--rw cbacc!
+--rw max-bits-per-second uint32 +--rw max-bits-per-second uint32
+--rw max-mss? uint16 +--rw max-mss? 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@2020-10-31.yang <CODE BEGINS> file ietf-cbacc@2021-02-01.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 "ambi";
import ietf-dorms { import ietf-dorms {
prefix "dorms"; prefix "dorms";
reference "I-D.jholland-mboned-dorms"; reference "I-D.jholland-mboned-dorms";
} }
skipping to change at page 12, line 39 skipping to change at page 12, line 43
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-jholland-mboned-dorms).";
revision 2019-09-26 { revision 2021-01-15 {
description "Initial revision as an extension."; description "Initial revision as an extension.";
reference reference
""; "";
} }
augment augment
"/dorms:metadata/dorms:sender/dorms:group/dorms:udp-stream" { "/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-bits-per-second {
type uint32; type uint32;
mandatory true; mandatory true;
 End of changes. 10 change blocks. 
12 lines changed or deleted 18 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/