<?xml version='1.0' encoding='utf8'?>
<rfc version="3" category="std" ipr="trust200902" submissionType="IETF" consensus="true" docName="draft-yang-rtgwg-ecn-threshold-policy-00" tocInclude="true" symRefs="true" sortRefs="true">
  <front>
    <title abbrev="ECN Threshold Policies">A YANG Data Model for ECN Threshold Policies</title>
    <author fullname="Jin Yang" initials="J." surname="Yang">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <code>100053</code>
          <country>China</country>
        </postal>
        <email>yangjinwl@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Weiqiang Cheng" initials="W." surname="Cheng">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <code>100053</code>
          <country>China</country>
        </postal>
        <email>chengweiqiang@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Tingting Han" initials="T." surname="Han">
      <organization>China Mobile</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <code>100053</code>
          <country>China</country>
        </postal>
        <email>hantingting@chinamobile.com</email>
      </address>
    </author>
    <author fullname="Junjie Wang" initials="J." surname="Wang">
      <organization>Centec</organization>
      <address>
        <postal>
          <city>Suzhou</city>
          <code>215000</code>
          <country>China</country>
        </postal>
        <email>wangjj@centec.com</email>
      </address>
    </author>
    <author fullname="Zongwei Meng" initials="Z." surname="Meng">
      <organization>Centec</organization>
      <address>
        <postal>
          <city>Suzhou</city>
          <code>215000</code>
          <country>China</country>
        </postal>
        <email>mengzw@centec.com</email>
      </address>
    </author>
    <author fullname="Ying Feng" initials="Y." surname="Feng">
      <organization>Centec</organization>
      <address>
        <postal>
          <city>Suzhou</city>
          <code>215000</code>
          <country>China</country>
        </postal>
        <email>fengy@centec.com</email>
      </address>
    </author>
    <date year="2026" month="October" day="30"/>
    <area>Routing</area>
    <workgroup>Individual Submission</workgroup>
    <abstract>
      <t>This document defines administrative limits and operational state for local ECN threshold adaptation on queues using a single byte-based Random Early Detection (RED) profile. It augments the QoS queue template model with policy bounds and the interface model with confirmed per-queue state.</t>
      <t>The policy constrains both RED thresholds, preserves the configured ramp width, and specifies quantization, input validity, transition, and fallback behavior. It does not select a learning algorithm, modify ECN codepoints, reserve physical buffer capacity, or guarantee congestion-control stability or lossless delivery.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>A locally adjusted RED threshold can differ from the configured base value. A controller or management client needs to know which queue instance is affected, the administrative bounds, whether the effective pair has been confirmed, and why adaptation is suspended. These meanings must be consistent if management software operates across implementations.</t>
      <t><xref target="I-D.ietf-rtgwg-qos-model"/> already models RED/WRED and other queue algorithms. <xref target="OC-QOS"/> is another substantial QoS management model. <xref target="I-D.yang-dynamic-ecn-threshold"/> describes coupling ECN thresholds with dynamic buffer allocation; its expiration does not erase that related work. The candidate addition here is the policy and state contract around a local controller. It is not a new claim to the idea of adapting ECN thresholds.</t>
      <t>This proposal targets review with the QoS model work. Integration into that model may be preferable to a separate module. The current augment is explicitly based on QoS model revision -16 and its 2026-09-26 module revisions; these are work in progress. The dependency must stabilize and the additional requirement must be accepted before publication. No support from those editors or from a working group is assumed.</t>
    </section>
    <section anchor="requirements">
      <name>Requirements Language</name>
      <t>The key words <bcp14>MUST</bcp14>, <bcp14>MUST NOT</bcp14>, <bcp14>REQUIRED</bcp14>, <bcp14>SHOULD</bcp14>, <bcp14>SHOULD NOT</bcp14>, <bcp14>RECOMMENDED</bcp14>, <bcp14>MAY</bcp14>, and <bcp14>OPTIONAL</bcp14> in this document are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="scope">
      <name>Applicability and Queue Binding</name>
      <t>The profile applies only to one RED configuration with ECN enabled, a byte-denominated minimum k_b, and maximum m_b with 0&lt;=k_b&lt;m_b. Its width D=m_b-k_b is positive and fixed until administrative base configuration changes. WRED color profiles, delay-based AQM, L4S coupled queues, and deterministic step marking are outside this version. Unsupported instances <bcp14>MUST</bcp14> report unavailable and <bcp14>MUST NOT</bcp14> silently ignore the policy.</t>
      <t>Configuration augments /qa:queues/qa:queue/qa:queue of <xref target="I-D.ietf-rtgwg-qos-model"/>. A template may instantiate several queues; it is not the identity of a physical queue. Operational state is keyed by interface and device-reported queue-id. queue-template records the applied binding. The server <bcp14>MUST</bcp14> validate each queue instance independently and <bcp14>MUST NOT</bcp14> merge effective values from different instances.</t>
      <t>The server <bcp14>MUST</bcp14> expose an accounting-quantum q&gt;0. Validated base thresholds, policy bounds, buffer margin and maximum step <bcp14>MUST</bcp14> be exact multiples of q. Configuration that cannot be represented on an instantiated queue is rejected at activation for that instance rather than silently rounded. A configuration transaction whose invalidity can be determined beforehand <bcp14>MUST</bcp14> be rejected. Policy support and all required local update capabilities must be established before reporting active.</t>
      <t>Byte quantities are bounded by 2^53-1 so model comparisons can use exact XPath integers. Intermediate arithmetic <bcp14>MUST</bcp14> use checked integer calculations. Input proposals and the validated budget are floored to multiples of q before use. In particular, S=maximum-step must be at least q. A value expressed in packets or a vendor percentage <bcp14>MUST NOT</bcp14> be accepted as bytes without an explicit supported conversion outside this profile.</t>
    </section>
    <section anchor="budget">
      <name>Validated Buffer Limit and Meaning of the Margin</name>
      <t>B is a current conservative egress-accounting limit established by the device for the specific queue. The budget/source string <bcp14>MUST</bcp14> identify the accounting mechanism and the mapping of shared pools, admission limits and queue occupancy to B. The server <bcp14>MUST</bcp14> omit budget if it cannot establish that meaning. Unknown B is not encoded as zero.</t>
      <t>An ingress PFC XOFF threshold is not automatically an egress queue limit. It <bcp14>MUST NOT</bcp14> be substituted for B without a validated conversion into the same egress-accounted bytes. Local occupancy, queue length, and current free shared memory also have different meanings; their numeric similarity does not establish the required bound.</t>
      <t>H=buffer-margin is an administrative arithmetic margin between the RED upper threshold and B. It neither reserves memory nor proves that the remaining capacity will absorb in-flight traffic. RED may use an average occupancy; packet admission, transport feedback delay, shared-pool changes and scheduling still affect drops or PFC. The pair bound below is a parameter bound, not an assurance that ECN feedback precedes every overflow or pause.</t>
    </section>
    <section anchor="selection">
      <name>Policy Evaluation</name>
      <t>Let K_min=minimum-onset, M_max=maximum-threshold, H=buffer-margin, S=maximum-step, and D=m_b-k_b. After quantization, the highest permissible minimum is U=min(M_max-D, B-H-D). The envelope is feasible only if M_max&gt;=D, B&gt;=H+D, and K_min&lt;=U. Implementations <bcp14>MUST</bcp14> check these conditions before unsigned subtraction. The base pair itself need not lie inside the adaptive envelope.</t>
      <artwork type="ascii-art">U = min(M_max - D, B - H - D)

For a normal adjustment with fresh proposal k_p:
  proposal  = q * floor(k_p / q)
  stepped   = min(max(proposal, k_previous - S), k_previous + S)
  effective = min(max(stepped, K_min), U)
  pair      = (effective, effective + D)
</artwork>
      <t>Normal controller adjustments <bcp14>MUST</bcp14> be serialized and occur no more often than once per update-interval, measured on a monotonic clock. k_previous is the last confirmed minimum in that control sequence. Arrivals of multiple proposals do not create extra adjustment opportunities. The server <bcp14>MUST</bcp14> revalidate input freshness, budget, policy and binding immediately before committing a pair. A proposal computed under an obsolete binding or policy <bcp14>MUST</bcp14> be discarded.</t>
      <t>The normal step limit does not delay enforcing a changed administrative bound or reduced B. A downward clamp required by a smaller U <bcp14>MUST</bcp14> be effective no later than the corresponding reduced budget becomes applicable while the instance is active. A raised lower bound can likewise require an upward clamp. Initial activation, recovery and administrative fallback are explicitly exempt from the normal controller step limit. When enforcement cannot be coordinated locally with budget changes, the instance <bcp14>MUST</bcp14> leave active and report pending or unavailable as appropriate; it cannot claim that a management polling loop provides this ordering.</t>
      <t>A device <bcp14>MUST</bcp14> apply the two thresholds as one coherent forwarding update, or use an implementation procedure that preserves the declared pair invariant throughout active operation. A device lacking such capability <bcp14>MUST NOT</bcp14> report active. The model specifies the required externally observable result and does not mandate a particular register or programming transaction.</t>
    </section>
    <section anchor="state">
      <name>State, Confirmation, and Fallback</name>
      <t>Freshness concerns the observations supporting the controller proposal and budget validation, not merely a running control thread. At input-timeout, new controller adjustments <bcp14>MUST</bcp14> stop. A budget that has become unknown is unavailable. For a known budget, infeasibility takes precedence over stale-input fallback. A requested pair is never reported as effective before confirmation.</t>
      <table anchor="states">
        <name>Operational States</name>
        <thead>
          <tr>
            <th>State</th>
            <th>Meaning and required behavior</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>active</td>
            <td>Fresh inputs, feasible envelope, valid binding, and confirmed current pair satisfying every bound.</td>
          </tr>
          <tr>
            <td>pending</td>
            <td>An activation, clamp or fallback has been requested but is not confirmed. Stop accepting obsolete controller work.</td>
          </tr>
          <tr>
            <td>fallback</td>
            <td>The envelope is feasible but observations are stale; the base pair is confirmed in forwarding.</td>
          </tr>
          <tr>
            <td>infeasible</td>
            <td>The envelope cannot contain a pair under the known budget; the base pair is confirmed in forwarding.</td>
          </tr>
          <tr>
            <td>unavailable</td>
            <td>Unsupported mapping, unknown budget, invalid base/accounting, lost forwarding visibility or programming failure.</td>
          </tr>
        </tbody>
      </table>
      <t>On stale input or infeasibility, the server <bcp14>MUST</bcp14> request restoration of the validated base pair and enter pending until it is confirmed. After confirmation it reports fallback or infeasible according to the current cause. If restoration fails, the status is unavailable. Base restoration is the defined administrative behavior; it is not a claim that the base pair satisfies the new B-H. A collector can calculate whether the reported effective maximum lies within the current budget and margin.</t>
      <t>The effective container is present only when the current forwarding pair is known, including during a pending update if the old pair is still known to be current. If partial programming or loss of visibility makes that uncertain, the container <bcp14>MUST</bcp14> be absent. A historical last-confirmed pair <bcp14>MUST NOT</bcp14> be represented as current effective state. The parameters and budget containers are similarly omitted when their values cannot be validated. Active, fallback and infeasible require all three containers.</t>
      <t>When fresh input and a feasible envelope return, the device validates and requests a bounded pair, enters pending, and reports active only after confirmation. Disabling or deleting the policy also requires orderly return to ordinary base QoS behavior. The server <bcp14>MUST</bcp14> stop local controller writes before handing ownership back; if return fails it retains an unavailable row with diagnostic reason rather than hiding the failure. Once the base configuration is confirmed and policy ownership has ended, the policy-state row can be removed.</t>
      <t>Each operational row is a coherent snapshot identified by epoch-id and state-sequence. The sequence increases whenever any exposed state field changes; before wrap a fresh epoch is created. Queue recreation, mapping change, or loss of sequence history also starts a fresh epoch. Repeated snapshots of the same identity <bcp14>MUST</bcp14> have identical fields. Atomically reading one row does not imply a simultaneous snapshot across all queues.</t>
    </section>
    <section anchor="ownership">
      <name>Configuration Ownership and ECN Behavior</name>
      <t>The local controller algorithm is implementation-defined; this document has no external propose-threshold action. The enforcement function is the sole writer of the effective threshold pair while it owns the queue. Administrative changes through NETCONF, RESTCONF, CLI, or other APIs <bcp14>MUST</bcp14> invalidate in-flight proposals and be revalidated as complete configurations. An alias <bcp14>MUST NOT</bcp14> bypass policy enforcement.</t>
      <t>The base RED template remains ordinary configuration in the relevant NMDA datastores <xref target="RFC8342"/>. Dynamic proposals do not overwrite it. The parameters subtree is a snapshot of the values currently used by the local enforcement function and may differ from intended configuration during transition. This difference <bcp14>MUST</bcp14> be made visible through pending/unavailable state rather than reported as an already applied change.</t>
      <t>The device <bcp14>MUST</bcp14> preserve existing CE and follow standard Not-ECT handling in <xref target="RFC3168"/>. The policy does not disable AQM or define an exception based on PFC. A zero minimum is not an all-mark command: the width, averaging and RED probability behavior still matter. Preserving D preserves the ramp width, not a proof of closed-loop behavior. Qualified PFC telemetry may be an input to a separately evaluated controller; it is not evidence that marking is unnecessary.</t>
    </section>
    <section anchor="evaluation">
      <name>Implementation and Evaluation Requirements</name>
      <t>A conforming implementation <bcp14>MUST</bcp14> document how it binds templates to queue IDs, derives B, accounts bytes, confirms a pair, coordinates budget reductions, and detects stale observations. It <bcp14>MUST</bcp14> expose unsupported or failed instances. Such documentation is necessary to interpret the interface; a syntactically valid YANG implementation alone does not establish the timing guarantee.</t>
      <t>Evaluation should follow <xref target="RFC7567"/> and <xref target="RFC7928"/> and include incast, burst load, mixed ECT and Not-ECT traffic, PFC, shared-pool contention, input loss, downward budget jumps, failure between pair writes, policy deletion, and two queues sharing a template. Actual transport response and hardware timing need measurement. The specification claims no universal convergence, optimality, losslessness or throughput improvement.</t>
    </section>
    <section anchor="yang-tree">
      <name>YANG Tree Diagram</name>
      <t>The tree is generated from the module using the notation in <xref target="RFC8340"/>.</t>
      <sourcecode type="yangtree">module: ietf-ecn-threshold-policy

  augment /qa:queues/qa:queue/qa:queue:
    +--rw ecn-threshold-policy!
       +--rw minimum-onset        byte-value
       +--rw maximum-threshold    byte-value
       +--rw buffer-margin        byte-value
       +--rw maximum-step         uint64
       +--rw update-interval?     uint32
       +--rw input-timeout?       uint32
  augment /if:interfaces/if:interface:
    +--ro ecn-threshold-state
       +--ro queue* [queue-id]
          +--ro queue-id          string
          +--ro queue-template    -&gt; /qa:queues/queue/name
          +--ro epoch-id          yang:uuid
          +--ro state-sequence    uint64
          +--ro status            enumeration
          +--ro reason            string
          +--ro parameters!
          |  +--ro minimum-onset         byte-value
          |  +--ro maximum-threshold     byte-value
          |  +--ro buffer-margin         byte-value
          |  +--ro maximum-step          uint64
          |  +--ro update-interval?      uint32
          |  +--ro input-timeout?        uint32
          |  +--ro accounting-quantum    uint64
          |  +--ro base-minimum          byte-value
          |  +--ro base-maximum          byte-value
          +--ro budget!
          |  +--ro limit     byte-value
          |  +--ro source    string
          +--ro effective!
             +--ro minimum    byte-value
             +--ro maximum    byte-value
</sourcecode>
    </section>
    <section anchor="yang-module">
      <name>YANG Module</name>
      <t>The module uses YANG 1.1 <xref target="RFC7950"/>, NMDA <xref target="RFC8342"/>, the interface model <xref target="RFC8343"/>, and common types <xref target="RFC9911"/>. Review follows <xref target="RFC9907"/>. RFC XXXX in the module is an RFC Editor placeholder.</t>
      <sourcecode type="yang" name="ietf-ecn-threshold-policy@2026-10-30.yang">module ietf-ecn-threshold-policy {
  yang-version 1.1;
  namespace
    "urn:ietf:params:xml:ns:yang:ietf-ecn-threshold-policy";
  prefix etp;

  import ietf-yang-types {
    prefix yang;
    reference
      "RFC 9911: Common YANG Data Types";
  }
  import ietf-interfaces {
    prefix if;
    reference
      "RFC 8343: A YANG Data Model for Interface Management";
  }
  import ietf-qos-action {
    prefix qa;
    reference
      "I-D.ietf-rtgwg-qos-model: QoS model, revision -16";
  }
  import ietf-qos-types {
    prefix qt;
    reference
      "I-D.ietf-rtgwg-qos-model: QoS types, revision -16";
  }

  organization
    "Individual Submission";
  contact
    "Author: Jin Yang &lt;mailto:yangjinwl@chinamobile.com&gt;
     Author: Weiqiang Cheng &lt;mailto:chengweiqiang@chinamobile.com&gt;
     Author: Tingting Han &lt;mailto:hantingting@chinamobile.com&gt;
     Author: Junjie Wang &lt;mailto:wangjj@centec.com&gt;
     Author: Zongwei Meng &lt;mailto:mengzw@centec.com&gt;
     Author: Ying Feng &lt;mailto:fengy@centec.com&gt;";
  description
    "Administrative limits and confirmed per-queue state for local
     ECN threshold adaptation on a single byte-based RED profile.

     Copyright (c) 2026 IETF Trust and the persons identified as
     authors of the code. All rights reserved.
     Redistribution and use in source and binary forms, with or
     without modification, is permitted pursuant to, and subject
     to the license terms contained in, the Revised BSD License
     set forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).
     This version of this YANG module is part of RFC XXXX
     (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
     for full legal notices.";

  revision 2026-10-30 {
    description
      "Initial revision.";
    reference
      "RFC XXXX: A YANG Data Model for ECN Threshold Policies";
  }

  typedef byte-value {
    type uint64 {
      range "0..9007199254740991";
    }
    units "bytes";
    description
      "Accounted bytes in the exact XPath integer range.";
  }

  grouping policy-values {
    description
      "Administrative bounds, also copied into applied state.";
    leaf minimum-onset {
      type byte-value;
      mandatory true;
      description
        "Lower bound on the effective RED minimum.";
    }
    leaf maximum-threshold {
      type byte-value;
      mandatory true;
      description
        "Upper bound on the effective RED maximum.";
    }
    leaf buffer-margin {
      type byte-value;
      mandatory true;
      description
        "Arithmetic margin below the validated egress limit; not a
         physical reservation or losslessness guarantee.";
    }
    leaf maximum-step {
      type uint64 {
        range "1..9007199254740991";
      }
      units "bytes";
      mandatory true;
      description
        "Maximum normal controller step in accounted bytes.";
    }
    leaf update-interval {
      type uint32 {
        range "1..max";
      }
      units "milliseconds";
      default "10";
      description
        "Minimum monotonic time between normal controller
         updates.";
    }
    leaf input-timeout {
      type uint32 {
        range "1..max";
      }
      units "milliseconds";
      default "1000";
      description
        "Maximum permitted age of supporting observations.";
    }
  }

  augment "/qa:queues/qa:queue/qa:queue" {
    description
      "Policy on a reusable RED queue template.";
    container ecn-threshold-policy {
      must
        "../qa:algorithmic-drop/qa:red/qa:ecn-enabled = 'true'";
      must
        '../qa:algorithmic-drop/qa:red/qa:min-threshold-val and '
      + '../qa:algorithmic-drop/qa:red/qa:max-threshold-val';
      must
        '../qa:algorithmic-drop/qa:red/qa:max-threshold-val &gt; '
      + '../qa:algorithmic-drop/qa:red/qa:min-threshold-val';
      must '../qa:algorithmic-drop/qa:red/qa:max-threshold-val '
         + '&lt;= 9007199254740991';
      must
        "derived-from-or-self(../qa:algorithmic-drop/qa:red/"
      + "qa:min-threshold-unit, 'qt:red-threshold-bytes') and "
      + "derived-from-or-self(../qa:algorithmic-drop/qa:red/"
      + "qa:max-threshold-unit, 'qt:red-threshold-bytes')";
      must 'minimum-onset &lt; maximum-threshold';
      must 'input-timeout &gt;= update-interval';
      presence
        "Requests policy enforcement for instances of this
         template.";
      description
        "Policy for single-profile RED with ECN enabled.";
      uses policy-values;
    }
  }

  augment "/if:interfaces/if:interface" {
    description
      "Confirmed policy state of instantiated egress queues.";
    container ecn-threshold-state {
      config false;
      description
        "One coherent row for each governed queue instance.";
      list queue {
        must "status = 'unavailable' or status = 'pending' or "
           + "(parameters and effective and budget)";
        must
          "status != 'active' or (budget and "
        + "parameters/minimum-onset &lt;= effective/minimum and "
        + "effective/maximum &lt;= parameters/maximum-threshold and "
        + "parameters/buffer-margin &lt;= budget/limit and "
        + "effective/maximum &lt;= budget/limit - "
        + "parameters/buffer-margin)";
        must
          "status != 'fallback' and status != 'infeasible' or "
        + "(effective/minimum = parameters/base-minimum and "
        + "effective/maximum = parameters/base-maximum)";
        must 'not(parameters and effective) or '
           + 'effective/maximum - effective/minimum = '
           + 'parameters/base-maximum - parameters/base-minimum';
        key "queue-id";
        description
          "State is coherent per row. Pending or unavailable is
           used
           while the requested state has not been confirmed.";
        leaf queue-id {
          type string {
            length "1..128";
          }
          description
            "Stable queue identifier within this interface and
             epoch.";
        }
        leaf queue-template {
          type leafref {
            path "/qa:queues/qa:queue/qa:name";
            require-instance false;
          }
          mandatory true;
          description
            "Template binding reflected in this state; may outlive
             its deletion briefly.";
        }
        leaf epoch-id {
          type yang:uuid;
          mandatory true;
          description
            "New identity on queue reuse, mapping change or loss
             of state-sequence history.";
        }
        leaf state-sequence {
          type uint64 {
            range "1..max";
          }
          mandatory true;
          description
            "Increases on any exposed state change; no wrap within
             an epoch.";
        }
        leaf status {
          type enumeration {
            enum active {
              description
                "Confirmed pair meets current bounds.";
            }
            enum fallback {
              description
                "Base pair confirmed after stale controller
                 input.";
            }
            enum infeasible {
              description
                "No bounded pair is feasible; base pair
                 confirmed.";
            }
            enum pending {
              description
                "A requested pair or fallback awaits
                 confirmation.";
            }
            enum unavailable {
              description
                "Capability, input validation or application
                 failed.";
            }
          }
          mandatory true;
          description
            "Current enforcement state; not a delivery
             guarantee.";
        }
        leaf reason {
          type string {
            length "1..256";
          }
          mandatory true;
          description
            "Diagnostic detail; clients use status for machine
             decisions.";
        }
        container parameters {
          must 'base-maximum &gt; base-minimum';
          must 'minimum-onset &lt; maximum-threshold';
          must 'input-timeout &gt;= update-interval';
          must
            'base-minimum mod accounting-quantum = 0 and '
          + 'base-maximum mod accounting-quantum = 0 and '
          + 'minimum-onset mod accounting-quantum = 0 and '
          + 'maximum-threshold mod accounting-quantum = 0 and '
          + 'buffer-margin mod accounting-quantum = 0 and '
          + 'maximum-step mod accounting-quantum = 0';
          presence
            "Validated base and policy values for this snapshot.";
          description
            "Values used locally; may lag intended
             configuration.";
          uses policy-values;
          leaf accounting-quantum {
            type uint64 {
              range "1..9007199254740991";
            }
            units "bytes";
            mandatory true;
            description
              "Hardware granularity; configuration values must be
               exact multiples.";
          }
          leaf base-minimum {
            type byte-value;
            mandatory true;
            description
              "Validated static RED minimum.";
          }
          leaf base-maximum {
            type byte-value;
            mandatory true;
            description
              "Validated static RED maximum.";
          }
        }
        container budget {
          must 'not(../parameters) or '
             + 'limit mod ../parameters/accounting-quantum = 0';
          presence
            "A current validated egress limit is available.";
          description
            "Omitted when a conservative bound cannot be
             validated.";
          leaf limit {
            type byte-value;
            mandatory true;
            description
              "Conservative accounted-byte ceiling B, rounded
               down.";
          }
          leaf source {
            type string {
              length "1..256";
            }
            mandatory true;
            description
              "Accounting mechanism and mapping to this egress
               queue.";
          }
        }
        container effective {
          must 'maximum &gt; minimum';
          must
            'not(../parameters) or '
          + '(minimum mod ../parameters/accounting-quantum = 0 and '
          + 'maximum mod ../parameters/accounting-quantum = 0)';
          presence "Current forwarding threshold pair is known.";
          description
            "Current confirmed values, omitted if partial failure
             or lost
             contact makes the current pair uncertain.";
          leaf minimum {
            type byte-value;
            mandatory true;
            description
              "Confirmed RED minimum in the forwarding plane.";
          }
          leaf maximum {
            type byte-value;
            mandatory true;
            description
              "Confirmed RED maximum in the forwarding plane.";
          }
        }
      }
    }
  }
}
</sourcecode>
    </section>
    <section anchor="examples">
      <name>Examples and Conformance Cases</name>
      <t>Let q=100, base=(1000,2000), D=1000, B=10000, H=2000, M_max=9000, K_min=1000, S=1000. Then U=7000. From previous minimum 4000 with proposal 8500, one normal update yields (5000,6000), not an immediate jump to (7000,8000). The latter is the uppermost permitted pair after subsequent allowed updates.</t>
      <t>If the previous pair is (7000,8000) and B contracts to 6500, U becomes 3500. A coordinated clamp produces (3500,4500), overriding S. If the hardware cannot coordinate that change, it cannot continue to report active.</t>
      <t>If B=2500 with H=2000 and D=1000, the envelope is infeasible even for K_min=0. After successful restoration the row is infeasible with effective=(1000,2000); the effective maximum exceeds B-H=500. That report is honest fallback state, not active compliance. A restoration failure instead reports unavailable.</t>
      <t>A backend that can confirm neither the old nor new pair after a partial failure omits effective. An active record missing the budget or parameters is invalid. Two instances using the same template must report their own B, effective pair and state. The JSON example below shows one such operational snapshot with byte-valued uint64 leaves encoded as strings under <xref target="RFC7951"/>.</t>
      <sourcecode type="json">{
  "ietf-qos-action:queues": {
    "queue": [
      {
        "name": "fabric-red",
        "queue": {
          "algorithmic-drop": {
            "red": {
              "min-threshold-val": "1000",
              "max-threshold-val": "2000",
              "min-threshold-unit":
                "ietf-qos-types:red-threshold-bytes",
              "max-threshold-unit":
                "ietf-qos-types:red-threshold-bytes",
              "max-probability-val": "10",
              "ecn-enabled": true
            }
          },
          "ietf-ecn-threshold-policy:ecn-threshold-policy": {
            "minimum-onset": "1000",
            "maximum-threshold": "9000",
            "buffer-margin": "2000",
            "maximum-step": "1000",
            "update-interval": 10,
            "input-timeout": 1000
          }
        }
      }
    ]
  },
  "ietf-interfaces:interfaces": {
    "interface": [
      {
        "name": "Ethernet1/1",
        "type": "iana-if-type:ethernetCsmacd",
        "oper-status": "up",
        "ietf-ecn-threshold-policy:ecn-threshold-state": {
          "queue": [
            {
              "queue-id": "q3",
              "queue-template": "fabric-red",
              "epoch-id": "36b5e4fa-5d23-4a82-adc3-18a8aef08e93",
              "state-sequence": "7",
              "status": "active",
              "reason": "fresh input and confirmed pair",
              "parameters": {
                "minimum-onset": "1000",
                "maximum-threshold": "9000",
                "buffer-margin": "2000",
                "maximum-step": "1000",
                "update-interval": 10,
                "input-timeout": 1000,
                "accounting-quantum": "100",
                "base-minimum": "1000",
                "base-maximum": "2000"
              },
              "budget": {
                "limit": "10000",
                "source":
                  "validated shared-pool egress admission bound"
              },
              "effective": {
                "minimum": "5000",
                "maximum": "6000"
              }
            }
          ]
        },
        "admin-status": "up",
        "if-index": 1,
        "statistics": {
          "discontinuity-time": "2026-10-30T00:00:00Z"
        }
      }
    ]
  }
}
</sourcecode>
    </section>
    <section anchor="security">
      <name>Security Considerations</name>
      <t>The module is designed for NETCONF <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/> over their secure transports; NETCONF over SSH is specified by <xref target="RFC6242"/>. NACM <xref target="RFC8341"/> or equivalent access controls <bcp14>MUST</bcp14> restrict writes and reads to authorized management roles.</t>
      <t>The writable ecn-threshold-policy container changes permitted queue thresholds, buffer margin, step and timing limits. Unauthorized or poorly chosen values can degrade throughput, increase marking or drops, and disrupt shared workloads. Write access deserves the same protection as base QoS configuration. A reusable template can affect many queues, so authorization and validation <bcp14>MUST</bcp14> consider all affected instances.</t>
      <t>Readable queue mappings, budgets, effective thresholds and state changes reveal shared-resource behavior. Access and subscription rates <bcp14>SHOULD</bcp14> be limited. This module defines no notifications, actions or remote controller interface. A compromised local controller can still generate poor proposals within the bounds; bounds do not make a malicious control algorithm safe. False but internally consistent state remains possible, and operational confirmation depends on the device implementation.</t>
    </section>
    <section anchor="iana">
      <name>IANA Considerations</name>
      <t>IANA is requested to register the following namespace in the IETF XML Registry <xref target="RFC3688"/>, and the following module in the YANG Module Names registry <xref target="RFC7950"/>. These are requested registrations, not assigned values.</t>
      <table anchor="yang-registration">
        <name>Requested Registration</name>
        <thead>
          <tr>
            <th>Field</th>
            <th>Value</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td>URI</td>
            <td>urn:ietf:params:xml:ns:yang:ietf-ecn-threshold-policy</td>
          </tr>
          <tr>
            <td>Registrant Contact</td>
            <td>IESG</td>
          </tr>
          <tr>
            <td>XML</td>
            <td>N/A; XML namespace</td>
          </tr>
          <tr>
            <td>Name</td>
            <td>ietf-ecn-threshold-policy</td>
          </tr>
          <tr>
            <td>Prefix</td>
            <td>etp</td>
          </tr>
          <tr>
            <td>Maintained by IANA</td>
            <td>N</td>
          </tr>
          <tr>
            <td>Reference</td>
            <td>RFC XXXX</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="I-D.ietf-rtgwg-qos-model" target="https://datatracker.ietf.org/doc/html/draft-ietf-rtgwg-qos-model-16">
        <front>
          <title>A YANG Data Model for Quality of Service (QoS) in IP Networks</title>
          <author initials="A." surname="Choudhary"/>
          <author initials="M." surname="Jethanandani"/>
          <author initials="E." surname="Aries"/>
          <author initials="I." surname="Chen" fullname="I. Chen"/>
          <date year="2026" month="September" day="25"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-qos-model-16"/>
      </reference>
      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner"/>
          <date year="1997" month="March"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="2119"/>
        <seriesInfo name="DOI" value="10.17487/RFC2119"/>
      </reference>
      <reference anchor="RFC3168" target="https://www.rfc-editor.org/info/rfc3168">
        <front>
          <title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
          <author initials="K." surname="Ramakrishnan"/>
          <author initials="S." surname="Floyd"/>
          <author initials="D." surname="Black"/>
          <date year="2001" month="September"/>
        </front>
        <seriesInfo name="RFC" value="3168"/>
        <seriesInfo name="DOI" value="10.17487/RFC3168"/>
      </reference>
      <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950">
        <front>
          <title>The YANG 1.1 Data Modeling Language</title>
          <author initials="M." surname="Bjorklund" role="editor"/>
          <date year="2016" month="August"/>
        </front>
        <seriesInfo name="RFC" value="7950"/>
        <seriesInfo name="DOI" value="10.17487/RFC7950"/>
      </reference>
      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba"/>
          <date year="2017" month="May"/>
        </front>
        <seriesInfo name="BCP" value="14"/>
        <seriesInfo name="RFC" value="8174"/>
        <seriesInfo name="DOI" value="10.17487/RFC8174"/>
      </reference>
      <reference anchor="RFC8342" target="https://www.rfc-editor.org/info/rfc8342">
        <front>
          <title>Network Management Datastore Architecture (NMDA)</title>
          <author initials="M." surname="Bjorklund"/>
          <author initials="J." surname="Schoenwaelder"/>
          <author initials="P." surname="Shafer"/>
          <author initials="K." surname="Watsen"/>
          <author initials="R." surname="Wilton"/>
          <date year="2018" month="March"/>
        </front>
        <seriesInfo name="RFC" value="8342"/>
        <seriesInfo name="DOI" value="10.17487/RFC8342"/>
      </reference>
      <reference anchor="RFC8343" target="https://www.rfc-editor.org/info/rfc8343">
        <front>
          <title>A YANG Data Model for Interface Management</title>
          <author initials="M." surname="Bjorklund"/>
          <date year="2018" month="March"/>
        </front>
        <seriesInfo name="RFC" value="8343"/>
        <seriesInfo name="DOI" value="10.17487/RFC8343"/>
      </reference>
      <reference anchor="RFC9911" target="https://www.rfc-editor.org/info/rfc9911">
        <front>
          <title>Common YANG Data Types</title>
          <author initials="J." surname="Schoenwaelder" role="editor"/>
          <date year="2025" month="December"/>
        </front>
        <seriesInfo name="RFC" value="9911"/>
        <seriesInfo name="DOI" value="10.17487/RFC9911"/>
      </reference>
    </references>
    <references>
      <name>Informative References</name>
      <reference anchor="I-D.yang-dynamic-ecn-threshold" target="https://datatracker.ietf.org/doc/html/draft-yang-dynamic-ecn-threshold-00">
        <front>
          <title>Coupling ECN Marking Thresholds with Dynamic Buffer Allocation</title>
          <author initials="J." surname="Yang"/>
          <author initials="W." surname="Cheng"/>
          <author initials="Y." surname="Tian"/>
          <author initials="J." surname="Wang"/>
          <author initials="G." surname="Zhang"/>
          <date year="2026" month="March" day="2"/>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-yang-dynamic-ecn-threshold-00"/>
      </reference>
      <reference anchor="OC-QOS" target="https://github.com/openconfig/public/tree/master/release/models/qos">
        <front>
          <title>OpenConfig QoS Models</title>
          <author>
            <organization>OpenConfig</organization>
          </author>
          <date/>
        </front>
      </reference>
      <reference anchor="RFC3688" target="https://www.rfc-editor.org/info/rfc3688">
        <front>
          <title>The IETF XML Registry</title>
          <author initials="M." surname="Mealling"/>
          <date year="2004" month="January"/>
        </front>
        <seriesInfo name="BCP" value="81"/>
        <seriesInfo name="RFC" value="3688"/>
        <seriesInfo name="DOI" value="10.17487/RFC3688"/>
      </reference>
      <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241">
        <front>
          <title>Network Configuration Protocol (NETCONF)</title>
          <author initials="R." surname="Enns" role="editor"/>
          <author initials="M." surname="Bjorklund" role="editor"/>
          <author initials="J." surname="Schoenwaelder" role="editor"/>
          <author initials="A." surname="Bierman" role="editor"/>
          <date year="2011" month="June"/>
        </front>
        <seriesInfo name="RFC" value="6241"/>
        <seriesInfo name="DOI" value="10.17487/RFC6241"/>
      </reference>
      <reference anchor="RFC6242" target="https://www.rfc-editor.org/info/rfc6242">
        <front>
          <title>Using the NETCONF Protocol over Secure Shell (SSH)</title>
          <author initials="M." surname="Wasserman"/>
          <date year="2011" month="June"/>
        </front>
        <seriesInfo name="RFC" value="6242"/>
        <seriesInfo name="DOI" value="10.17487/RFC6242"/>
      </reference>
      <reference anchor="RFC7567" target="https://www.rfc-editor.org/info/rfc7567">
        <front>
          <title>IETF Recommendations Regarding Active Queue Management</title>
          <author initials="F." surname="Baker" role="editor"/>
          <author initials="G." surname="Fairhurst" role="editor"/>
          <date year="2015" month="July"/>
        </front>
        <seriesInfo name="BCP" value="197"/>
        <seriesInfo name="RFC" value="7567"/>
        <seriesInfo name="DOI" value="10.17487/RFC7567"/>
      </reference>
      <reference anchor="RFC7928" target="https://www.rfc-editor.org/info/rfc7928">
        <front>
          <title>Characterization Guidelines for Active Queue Management (AQM)</title>
          <author initials="N." surname="Kuhn" role="editor"/>
          <author initials="P." surname="Natarajan" role="editor"/>
          <author initials="N." surname="Khademi" role="editor"/>
          <author initials="D." surname="Ros"/>
          <date year="2016" month="July"/>
        </front>
        <seriesInfo name="RFC" value="7928"/>
        <seriesInfo name="DOI" value="10.17487/RFC7928"/>
      </reference>
      <reference anchor="RFC7951" target="https://www.rfc-editor.org/info/rfc7951">
        <front>
          <title>JSON Encoding of Data Modeled with YANG</title>
          <author initials="L." surname="Lhotka"/>
          <date year="2016" month="August"/>
        </front>
        <seriesInfo name="RFC" value="7951"/>
        <seriesInfo name="DOI" value="10.17487/RFC7951"/>
      </reference>
      <reference anchor="RFC8040" target="https://www.rfc-editor.org/info/rfc8040">
        <front>
          <title>RESTCONF Protocol</title>
          <author initials="A." surname="Bierman"/>
          <author initials="M." surname="Bjorklund"/>
          <author initials="K." surname="Watsen"/>
          <date year="2017" month="January"/>
        </front>
        <seriesInfo name="RFC" value="8040"/>
        <seriesInfo name="DOI" value="10.17487/RFC8040"/>
      </reference>
      <reference anchor="RFC8340" target="https://www.rfc-editor.org/info/rfc8340">
        <front>
          <title>YANG Tree Diagrams</title>
          <author initials="M." surname="Bjorklund"/>
          <author initials="L." surname="Berger" role="editor"/>
          <date year="2018" month="March"/>
        </front>
        <seriesInfo name="BCP" value="215"/>
        <seriesInfo name="RFC" value="8340"/>
        <seriesInfo name="DOI" value="10.17487/RFC8340"/>
      </reference>
      <reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8341">
        <front>
          <title>Network Configuration Access Control Model</title>
          <author initials="A." surname="Bierman"/>
          <author initials="M." surname="Bjorklund"/>
          <date year="2018" month="March"/>
        </front>
        <seriesInfo name="STD" value="91"/>
        <seriesInfo name="RFC" value="8341"/>
        <seriesInfo name="DOI" value="10.17487/RFC8341"/>
      </reference>
      <reference anchor="RFC9907" target="https://www.rfc-editor.org/info/rfc9907">
        <front>
          <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title>
          <author>
            <organization>RFC Editor</organization>
          </author>
          <date year="2026" month="March"/>
        </front>
        <seriesInfo name="RFC" value="9907"/>
      </reference>
    </references>
  </back>
</rfc>
