Internet DRAFT - draft-ravi-ippm-csig

draft-ravi-ippm-csig







Networking Working Group                                         A. Ravi
Internet-Draft                                              N. Dukkipati
Intended status: Experimental                                   N. Mehta
Expires: 5 August 2024                                        Google LLC
                                                                J. Kumar
                                                           Broadcom Inc.
                                                         2 February 2024


                      Congestion Signaling (CSIG)
                        draft-ravi-ippm-csig-01

Abstract

   This document presents Congestion Signaling (CSIG), an in-band
   network telemetry protocol that allows end-hosts to obtain visibility
   into fine-grained network signals for congestion control, traffic
   management, and network debuggability in the network.  CSIG provides
   a simple, low-overhead, and extensible packet header mechanism to
   obtain fixed-length summaries from bottleneck devices along a packet
   path.  This summarized information is collected over L2 CSIG-tags in
   a compare-and-replace manner across network devices along the path.
   Receivers can reflect this information back to senders via L4+ CSIG
   reflection headers.

   CSIG builds upon the successful aspects of prior work such as switch
   in-band network telemetry (INT) that incorporates multibit signals in
   live data packets.  At the same time, CSIG's end-to-end mechanism for
   carrying the signals via fixed size header is simple, practical and
   deployable akin to Explicit Congestion Notification (ECN).

   In addition to a detailed description of the end-to-end protocol,
   this document also motivates the use cases for CSIG and the rationale
   for design choices made in CSIG.  It describes a set of signals of
   interest to applications (minimum available bandwidth, maximum link
   utilization, and maximum hop delay), methods to compute these signals
   in network devices, and how these signals can be leveraged in
   applications.  Additionally, it describes how attributes about the
   bottleneck's location can be carried and made useful to applications.
   It also provides the framework to incorporate future signals.
   Finally, this document addresses incremental deployment, backward
   compatibility and nuances of CSIG's applicability in a range of
   scenarios.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.



Ravi, et al.              Expires 5 August 2024                 [Page 1]

Internet-Draft                    CSIG                     February 2024


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 5 August 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   6
   2.  Design Principles . . . . . . . . . . . . . . . . . . . . . .   8
   3.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   9
   4.  Congestion Signaling Protocol . . . . . . . . . . . . . . . .   9
     4.1.  CSIG-tag Header Format  . . . . . . . . . . . . . . . . .  10
       4.1.1.  Compact Format  . . . . . . . . . . . . . . . . . . .  11
       4.1.2.  Expanded Format . . . . . . . . . . . . . . . . . . .  11
       4.1.3.  CSIG-tag Data fields Description  . . . . . . . . . .  11
     4.2.  CSIG Reflection Header Format . . . . . . . . . . . . . .  14
       4.2.1.  Reflection in TCP . . . . . . . . . . . . . . . . . .  15
       4.2.2.  Reflection in non-TCP Transports  . . . . . . . . . .  15
     4.3.  CSIG Operation - Life of a packet . . . . . . . . . . . .  16
       4.3.1.  Forward Path  . . . . . . . . . . . . . . . . . . . .  16
       4.3.2.  Reverse Path  . . . . . . . . . . . . . . . . . . . .  17
       4.3.3.  Multiple signals  . . . . . . . . . . . . . . . . . .  17
     4.4.  Device Roles  . . . . . . . . . . . . . . . . . . . . . .  17
       4.4.1.  Sender host . . . . . . . . . . . . . . . . . . . . .  17
       4.4.2.  Transit device  . . . . . . . . . . . . . . . . . . .  18
       4.4.3.  Receiver host . . . . . . . . . . . . . . . . . . . .  18



Ravi, et al.              Expires 5 August 2024                 [Page 2]

Internet-Draft                    CSIG                     February 2024


       4.4.4.  Host roles for bidirectional flows  . . . . . . . . .  18
   5.  Signals in CSIG . . . . . . . . . . . . . . . . . . . . . . .  19
     5.1.  Minimum Available Bandwidth - min(ABW)  . . . . . . . . .  19
       5.1.1.  ABW Computation . . . . . . . . . . . . . . . . . . .  19
     5.2.  Maximum link utilization - max(U/C) or min(ABW/C) . . . .  20
       5.2.1.  ABW/C Computation . . . . . . . . . . . . . . . . . .  20
       5.2.2.  min(ABW) vs min(ABW/C) bottlenecks  . . . . . . . . .  21
     5.3.  Shared requirements for min(ABW) and min(ABW/C) . . . . .  21
       5.3.1.  Algorithm Requirements  . . . . . . . . . . . . . . .  21
       5.3.2.  Timescale and Accuracy Requirements . . . . . . . . .  21
       5.3.3.  Bucketing / Quantization Requirements . . . . . . . .  21
       5.3.4.  QoS requirements  . . . . . . . . . . . . . . . . . .  22
     5.4.  Maximum Per-hop Delay - max(PD) . . . . . . . . . . . . .  22
       5.4.1.  Per-hop Delay Computation . . . . . . . . . . . . . .  22
       5.4.2.  Requirements  . . . . . . . . . . . . . . . . . . . .  22
     5.5.  Locator Metadata Implementation . . . . . . . . . . . . .  23
       5.5.1.  Requirements  . . . . . . . . . . . . . . . . . . . .  24
       5.5.2.  Attributes  . . . . . . . . . . . . . . . . . . . . .  24
   6.  Incremental Deployment of CSIG. . . . . . . . . . . . . . . .  25
     6.1.  CSIG Stripping: A per egress-port primitive . . . . . . .  25
     6.2.  Levels of CSIG Support  . . . . . . . . . . . . . . . . .  26
       6.2.1.  Discard . . . . . . . . . . . . . . . . . . . . . . .  26
       6.2.2.  Pass-through  . . . . . . . . . . . . . . . . . . . .  26
       6.2.3.  Complete  . . . . . . . . . . . . . . . . . . . . . .  26
     6.3.  Interoperability in Brownfield Deployments  . . . . . . .  27
       6.3.1.  Requirements for interoperability . . . . . . . . . .  27
       6.3.2.  Forwarding  . . . . . . . . . . . . . . . . . . . . .  28
       6.3.3.  Negotiation . . . . . . . . . . . . . . . . . . . . .  28
     6.4.  Backward Compatibility via Software-assisted CSIG . . . .  30
     6.5.  Greenfield deployments  . . . . . . . . . . . . . . . . .  31
   7.  Design Rationale  . . . . . . . . . . . . . . . . . . . . . .  31
     7.1.  Choice of Layer 2 . . . . . . . . . . . . . . . . . . . .  31
     7.2.  Separation of headers for CSIG-tag and reflection . . . .  32
     7.3.  Fixed-size headers  . . . . . . . . . . . . . . . . . . .  32
     7.4.  Signal Design . . . . . . . . . . . . . . . . . . . . . .  33
   8.  Use Cases defined by Bottleneck Signals . . . . . . . . . . .  34
     8.1.  Congestion Control  . . . . . . . . . . . . . . . . . . .  34
       8.1.1.  Using maximum per-hop delay in E2E CC . . . . . . . .  34
       8.1.2.  Using maximum link utilization in E2E CC  . . . . . .  35
       8.1.3.  Using minimum available bandwidth in E2E CC . . . . .  36
     8.2.  Traffic Management  . . . . . . . . . . . . . . . . . . .  36
       8.2.1.  Load Balancing and Multipathing . . . . . . . . . . .  37
       8.2.2.  Traffic Engineering . . . . . . . . . . . . . . . . .  37
     8.3.  Application Performance Debugging . . . . . . . . . . . .  37
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  38
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  38
   11. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  38
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  39



Ravi, et al.              Expires 5 August 2024                 [Page 3]

Internet-Draft                    CSIG                     February 2024


   13. Normative References  . . . . . . . . . . . . . . . . . . . .  39
   Appendix A.  Example encodings of CSIG signals  . . . . . . . . .  42
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  43
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  43

1.  Introduction

   Many network control loops, including Congestion Control, Traffic
   Engineering and Network Operations, make decisions based on the
   congestion experienced by application flows.  The signals used to
   determine congestion are often implicitly derived from end-to-end
   signals, approximated over larger timescales than desired, or
   obtained out-of-band from the network.  This can lead to suboptimal
   performance for applications or inefficiency in network usage.  CSIG
   (Congestion Signaling) provides direct, real-time, inband signals
   that network control loops can incorporate for performance and
   efficiency.

   A number of congestion control algorithms (CCA) are deployed in
   datacenters, including Swift [SWIFT], BBR [BBR], DCTCP [RFC8257],
   DCQCN [DCQCN] and HPCC++ [I-D.miao-tsv-hpcc].  These CCA vary in the
   congestion signals they use and in how they increase/decrease flow
   rates in response to the signals.  Swift uses precise measurements of
   round-trip time (RTT) to modulate its congestion window.  BBR uses a
   combination of flow's delivery rate and RTT measurements.  DCTCP and
   DCQCN rely on Explicit Congestion Notification (ECN [RFC3168]) from
   switches that indicate if the queue build up is above a threshold.
   HPCC++ leverages per-hop queue depth and transmit bytes along the
   flow's path, obtained via inband telemetry probes, to update flow
   rates.

   Despite the advances in sophisticated signals on when to slow down
   transfers, there continue to be blind-spots for CCA when it comes to
   increasing flow rates, e.g., What is the appropriate starting rate
   for a flow?  How quickly should a flow ramp up in the absence of
   congestion?  Without explicit information from the network, end-to-
   end CCA have come to rely on heuristics that can either undershoot or
   overshoot the bottleneck bandwidth, which can lead to slower Flow
   Completion Times (FCT) or increased round-trip times or packet
   losses.  At the same time, applications' appetite for fast network
   performance is rising: AI/ML applications are pushing for fast
   network transfers and avoid idling expensive Tensor Processing Units
   (TPUs) and Graphics Processing Units (GPUs).  Similarly Storage
   disaggregation needs fast transfers to make a remote Storage device
   appear as a local device at host.






Ravi, et al.              Expires 5 August 2024                 [Page 4]

Internet-Draft                    CSIG                     February 2024


   In this document we introduce Congestion Signaling (CSIG) to
   explicitly notify the hosts of the bottleneck link metrics.  There
   are several important use cases for CSIG, including:

   *  Congestion Control Algorithms for making decisions on sending
      rate: CCA at senders can use CSIG for quickly and safely ramping
      up to the maximum feasible rate as determined by the bottleneck
      link, and react with precision to the bottleneck hop both in the
      presence and absence of congestion.  The motivation for quick
      ramp-up stems from making maximal use of datacenter bandwidth, and
      decreasing latency even for large transfers.  There are several
      ways in which CSIG can help complete transfers quickly, e.g.,
      transfers belonging to an ML collective communication can ramp up
      quickly to maximally use all network bandwidth and complete close
      to the ideal transfer completion time.

   *  Traffic Management systems including Traffic Engineering (TE),
      Load Balancing and Multipathing too benefit from CSIG.  TE systems
      infer congested flows through an offline multi-minute process via
      superimposition of network traffic stats, topology and routing
      information.  With CSIG, TE has more up to date information on the
      congested points and the application flows experiencing
      congestion.  Using such finer-grained information can lead to more
      efficient and timely provisioning for bursty traffic.  Similarly,
      CSIG-enabled multipathed transport flows can choose paths in real
      time with the most available bandwidth.

   *  Troubleshooting and Performance Optimization.  We also envision
      CSIG to assist with debugging the network-level performance of
      datacenter applications.  Large-scale applications, including ML
      training workloads, open thousands of connections at the transport
      layer.  When the network is slow for an application, it is almost
      impossible to identify the bottleneck hops without joining many
      data sources across switches and hosts.  Because CSIG conveys the
      path bottleneck characteristics, it is valuable in pinpointing
      choke points in the network.  Knowledge of these choke points can
      lead to better bandwidth provisioning, timely repair processes,
      and real-time control, such as better load balancing.

   CSIG provides simple, fixed-length summaries of bottleneck links
   along a path, such as maximum hop delay, minimum available bandwidth,
   and maximum link utilization.  Information is collected at L2 from
   network devices along a packet path.  Each data receiver then returns
   the collected information to the data sender via L4 transport options
   or payloads.  CSIG uses a simple compare-and-replace operation at
   network devices, which allows it to scale with network topology, link
   speeds, and packet rates.




Ravi, et al.              Expires 5 August 2024                 [Page 5]

Internet-Draft                    CSIG                     February 2024


   CSIG builds on the successful aspects of prior explicit feedback
   schemes, but is more capable.  CSIG carries rich multi-bit switch
   telemetry in live data packets, drawing from the advancements in in-
   band network telemetry, also generally known as INT.  At the same
   time, CSIG retains the fixed-size headers and reflection in L4
   transports akin to Explicit Congestion Notification (ECN).  The
   industry has three key variants of INT: the one first specified in
   P4.org [P4-INT], the IOAM (In Situ Operations, Administration, and
   Maintenance) standard [RFC9378] in IETF and the Inband Flow Analyzer
   (IFA) spec [I-D.kumar-ippm-ifa] that is used in HPCC deployment
   [HPCCPLUS].  While they differ in the header definitions and
   encapsulation mechanisms, they all commonly stack up multiple per-
   switch telemetry data per-hop in the path of a packet.  The packet
   size grows proportional to the metrics per switch and the number of
   forwarding devices along its path.  Depending on the use case and
   header definition, the per-packet overhead ranges from 20B to above
   100B.  The large and variable size header overhead incurs challenges
   in end-to-end MTU limit conformation and parsing of the packet header
   data in the forwarding or receiving devices.

   There exist several efforts to address the challenges incurred in INT
   variants, including: 1) carrying INT data in synthetically generated
   non-data packets also known as probe packets, and 2) carrying only
   the fixed-size INT instructions (e.g., specifying which data to
   collect per hop) in data packets, while hop devices generate separate
   report packets that deliver the requested per-hop data.  While these
   techniques reduced the per-data-packet overhead, they did not
   fundamentally reduce the total amount of bytes or PPS overhead on the
   network devices or the data collector.  TCP-INT [TCP-INT] was
   developed in parallel to carry fixed-size min/max/sum aggregate
   metric over the hops together with a hop locator in live data
   packets.  However, it is limited to TCP Options, hence not applicable
   to various modern transports for AI/HPC, and furthermore there is no
   flexible way to introduce a new metric.  CSIG's type-value format
   ensures a constant size overhead with future-proofness.  The
   guaranteed constant size is small enough to fit into the 4B or 8B
   tag, enabling the unique placement of CSIG in L2, which frees the
   operators from the concerns around tunneling and encryption in
   deploying CSIG.

   In the rest of the document, we describe the design of end-to-end
   CSIG at hosts and network devices.

1.1.  Terminology

   ABW:  Available Bandwidth

   AQM:  Active Queue Management



Ravi, et al.              Expires 5 August 2024                 [Page 6]

Internet-Draft                    CSIG                     February 2024


   CCA:  Congestion Control Algorithms

   Connection / Flow:  A 5-tuple transport connection, e.g.  TCP
      connection

   CSIG:  Congestion Signaling

   CSIG data fields:  Fields in the CSIG tag excluding the TPID.

   CSIG packets:  Packets that contain the CSIG-tag and optionally the
      CSIG reflection header

   CSIG-capable path:  Path is termed CSIG-capable if all transit
      devices along the path support the CSIG protocol and end hosts
      have at least pass-through support for CSIG packets

   CSIG-tagged packets:  Packets that contain the CSIG-tag in the packet
      header

   CSIG-domain:  Secure network deployment domain where all devices in
      the domain have complete CSIG support or pass-through CSIG support

   PD:  Per-hop delay

   E2E:  End-to-End

   IPSec:  Internet Protocol Security

   MTU:  Maximum Transmission Unit

   MSS:  Maximum Segment Size

   NIC:  Network Interface Card

   Packet Path:  The port-by-port network path taken by a given packet
      specified as a sequence of device interfaces

   PSP:  PSP Security Protocol

   TPID:  Tag Protocol ID

   TE:  Traffic Engineering

   Transit device:  Any switch, router or middlebox in the path of a
      CSIG packet

   WRR:  Weighted Round Robin




Ravi, et al.              Expires 5 August 2024                 [Page 7]

Internet-Draft                    CSIG                     February 2024


2.  Design Principles

   CSIG was conceived to address problems in congestion control, traffic
   management and network debuggability in production networks.  We
   describe below the design principles that shaped CSIG, with
   simplicity and ease of deployment being at the forefront.  Section 7
   discusses the rationale behind the specific design choices made in
   CSIG.

   *  Simple Signals driven by Use Cases: Simple device port or queue
      metrics that solve concrete use cases are at the heart of CSIG's
      design principles.  This simplicity is not only important to
      applications, but also keeps the area, power and cost of
      implementation low on network devices.  Signals in CSIG are
      designed to be implementable in ASICs at line rate.  Signals that
      track per-flow state at the switch, for example, are harder to
      implement and deploy, and are hence avoided in CSIG.  CSIG is also
      flexible enough to accommodate new signals and use cases beyond
      those described in this document.

   *  End-to-End Perspective: CSIG's design stems from an end-to-end
      perspective of requirements and trade-offs for both applications
      and the network.  This document covers the necessary end-to-end
      aspects and the resulting design choices that make CSIG both
      useful to applications and practical to deploy.

   *  Small and Fixed Packet Overhead: It is important that the packet
      size does not increase as it traverses the network, which means
      that the MTU does not need to be changed.  Any overhead that is
      introduced should be fixed and small, minimizing the cost of
      implementation in switch / NIC pipelines.  Low protocol overhead
      also means low bandwidth overhead for small packets, minimizing
      impact to packet-per-second (PPS) load and bandwidth efficiency.
      We make very few assumptions about which packets and devices CSIG
      is enabled on.  Device implementations must be able to process
      CSIG on packets at line rate with minimal CPU involvement.
      Keeping the overhead small and fixed allows for CSIG to be enabled
      on every single packet at line rate.  This is important because
      deployments may choose to enable CSIG on every packet rather than
      on a small sample of packets.











Ravi, et al.              Expires 5 August 2024                 [Page 8]

Internet-Draft                    CSIG                     February 2024


   *  Works easily under Tunneling and Encryption: Tunnels are broadly
      used in modern deployments e.g., Traffic-engineering systems and
      Cloud traffic frequently use tunnels.  CSIG is designed to easily
      support end-to-end signaling on devices even in the presence of
      complex tunneling deployments.  This is in contrast to other in-
      band telemetry schemes that put more pressure on the ASICs to
      relocate metadata across inner and outer headers to work in the
      presence of tunnels.  In addition, CSIG also works with encrypted
      packets, including PSP, IPSec and 802.1AE MAC Security.

   *  Incremental Deployability: CSIG allows incremental deployment,
      where the mechanism can be deployed gradually into domains where
      some devices may support the new protocol and others may not.
      This document addresses interoperability in heterogeneous
      networks, and addresses backward compatibility with legacy
      devices.  We envision CSIG to be broadly valuable across wired
      networks, although our target domain for initial usage is
      datacenter networks.  We make minimal assumptions about the
      network architecture around tunneling, number of hops (diameter),
      routing, topology etc.  Configuring CSIG for end-to-end
      consistency in a private network, or deployments over the Internet
      are not in scope for this document.

3.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].
   In this document, these words will appear with that interpretation
   only when in ALL CAPS.  Lower case uses of these words are not to be
   interpreted as carrying significance described in RFC 2119.

4.  Congestion Signaling Protocol

   CSIG protocol defines two components in the packet header to achieve
   end to end congestion signaling in a production network.

   *  CSIG-tag: An L2 protocol that end hosts and transit devices
      participate in.

   *  CSIG Reflection: A flexible L4+ protocol that only end hosts
      participate in.

   CSIG-tag is the core component of the CSIG specification.  It enables
   end hosts to request network signals of interest and for transit
   devices to provide these signals to end hosts over the specified
   packet header bits.




Ravi, et al.              Expires 5 August 2024                 [Page 9]

Internet-Draft                    CSIG                     February 2024


   However, to achieve end-to-end CSIG, CSIG-tag MAY be combined with
   the CSIG reflection protocol to expose the signals of interest to the
   relevant endpoints or consumers where the signals are needed.

   This section first describes the header formats for CSIG-tag and CSIG
   reflection.  Then it describes the life of a CSIG packet, outlining
   the different roles of network devices in the context of CSIG, and
   how these two packet header mechanisms work together to achieve end-
   to-end signaling.

4.1.  CSIG-tag Header Format

   CSIG tag is a fixed size tag at the layer 2 header.

   CSIG-tag placement in various packet encapsulations is shown below
   for completeness.  It is always the last tag in the layer 2 header.

   ARPA: dstmac / srcmac / csig-tag / ethertype / payload

   802.1q: dstmac / srcmac / vlan-tag / csig-tag / ethertype / payload

   802.1ad: dstmac / srcmac / vlan-tag / vlan-tag / csig-tag / ethertype
   / payload

   802.1ad tunnel: dstmac / srcmac / vlan-tag / vlan-tag / vlan-tag /
   vlan-tag / csig-tag / ethertype / payload

   802.1ae: dstmac / srcmac / security-tag / vlan-tag / csig-tag /
   ethertype / payload

   Consequently, the placement / offset of the CSIG tag is not affected
   by the headers and payload at layers 3 and above.  Layer 2.5 headers,
   such as MPLS, are also placed after the CSIG tag and do not impact
   its offset.

   CSIG-tag is defined in two variants - Compact and Expanded.  Each
   variant has a dedicated TPID codepoint to allow devices to infer
   which variant is in use.  Each variant supports a distinct set of
   requirements with respect to production deployment and identifies
   contrasting trade-off points in the solution space.  Deployment
   considerations are discussed in Section 6.

   Structurally, the compact CSIG-tag variant resembles a single VLAN
   tag and the expanded CSIG-tag variant resembles a double VLAN tag.
   This structural similarity is intentional and the reasons are
   elaborated in Section 6.4.





Ravi, et al.              Expires 5 August 2024                [Page 10]

Internet-Draft                    CSIG                     February 2024


4.1.1.  Compact Format

   CSIG-tag compact format is as shown, with 2B allocated for the CSIG
   Tag Protocol ID (TPID) and 2B allocated for the data fields.

      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             TPID              |  T  |R|    S    |      LM     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |0-15|  TPID  : IEEE allocated Tag Protocol ID for 4 Byte CSIG tag
      |16-18| T     : Signal Type (0:min(ABW), 1: min(ABW/C), 2:max(PD))
      |19|    R     : Reserved
      |20-24| S     : Signal Value: Bucketed (32 configurable buckets)
      |25-31| LM    : Locator Metadata of bottleneck device / port

                     Figure 1: CSIG-tag Compact version

4.1.2.  Expanded Format

   CSIG-tag expanded format is as shown, with 2B allocated for the Tag
   Protocol ID (TPID) and 6B allocated for the data fields

      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             TPID              |               LM              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   T   |                  S                    |       R       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |0-15|  TPID : IEEE allocated Tag Protocol ID for 8 Byte CSIG tag
      |16-31| LM   : Locator Metadata of bottleneck device / port
      |0-3|   T    : Signal Type (0:min(ABW), 1: min(ABW/C), 2:max(PD))
      |4-23|  S    : Signal Value: Uniformly quantized
      |24-31| R    : Reserved for future use

                    Figure 2: CSIG-tag Expanded version

4.1.3.  CSIG-tag Data fields Description

   This section describes the format and usage of data fields within the
   CSIG-tag







Ravi, et al.              Expires 5 August 2024                [Page 11]

Internet-Draft                    CSIG                     February 2024


4.1.3.1.  Signal Type

   The Signal Type field T is three (four) bits long in the compact
   (expanded) format and indicates the type of signal being carried in
   the CSIG-tag.  End hosts set the signal type T and request it on each
   packet of interest.  Up to 8 signal types are supported in the
   compact format, and up to 16 signal types are supported in the
   expanded format.  This draft concretely defines three signals:
   min(ABW), min(ABW/C) and max(PD), elaborated in Section 5 and
   Section 8.  The remaining codepoints are reserved for future signals,
   and may be defined and used in future versions of CSIG.

   A single packet can carry at most one Congestion Signal.  However,
   end hosts MAY obtain multiple signals for a single 5-tuple flow by
   requesting different signal types on alternating packets of a flow or
   in a round-robin fashion across packets.  Therefore, end hosts need
   not tie a single flow to a specific signal type, and MAY obtain all
   supported CSIG signals for a single flow.

4.1.3.2.  Signal Value

   The Signal Value field S is 5 bits (20 bits) long in the compact
   (expanded) format and captures the value of the signal specified by
   Signal Type T.  End hosts set the initial Signal Value S alongside
   the requested Signal Type T, and each transit device along the packet
   path in the network MAY modify S in accordance with the e2e signal
   being computed.  E.g., For signals that are min() aggregations, end
   hosts set the initial value of S to the maximum allowable value of
   the signal or its encoding thereof, and transit devices perform
   compare-and-replace to compute the min() across signals of individual
   devices on the packet path.

   In the compact format, the 5-bit Signal Value is bucketed with 32
   fully configurable buckets.  Each bucket is configured with (low,
   high) value range.  This configuration is specific to each Signal
   Type and MAY vary across Signal Types.  This allows the Signal Value
   representation to be tailored to the specific needs of each Signal
   Type.  For example, in typical use cases of available bandwidth, it
   is more useful to have higher granularity at lower values of the
   signal (i.e., when ABW is close to 0) than at higher values of the
   signal.  This is because lower values of ABW have greater impact on
   application control decisions e.g., knowing whether there was 0 Gbps
   vs 1 Gbps available on a path makes a larger difference than knowing
   if there was 399 Gbps vs 400 Gbps available.  Appendix A shows how
   the buckets could be defined in order to provide such a non-linear
   encoding of value-ranges to buckets.  Such configurable encodings
   allow capturing useful information about the signal with fewer bits
   and is a core feature of the compact CSIG format.



Ravi, et al.              Expires 5 August 2024                [Page 12]

Internet-Draft                    CSIG                     February 2024


   In the expanded format, Signal Value is uniformly quantized into a 20
   bit value.  The unit of quantization is configurable on a per Signal
   Type basis, depending on the minimum and maximum value that needs to
   be represented with the given bits.  The higher bit length allows for
   enhanced signal granularity and fewer configuration knobs in domains
   where the expanded CSIG format is viable to deploy (Section 6.5).
   20-bits are sufficient to represent a wide range of values with high
   granularity.  As an example, with a 8Mbps quantum for min(ABW), the
   signal value field can represent up to a max of 8Tbps.  With a 128ns
   quantum for max(PD), the signal value field can represent up to a max
   of 128ms.  More discussion on signal-specific quanta is in
   Appendix A.

   Signal quantization / bucketing parameters are configured directly at
   the transit devices where the signal is computed.  End hosts do not
   explicitly request or negotiate these parameters.  As described in
   Section 5, all devices MUST be configured with the same quantization
   / bucketing parameters for each signal type, in order to correctly
   compute the requested signal along packet paths.

4.1.3.3.  Locator Metadata

   Locator Metadata field LM is an optional 7 bits (16 bits) in the
   compact (expanded) format.  It captures relevant metadata about the
   bottleneck port or device, where the notion of bottleneck is specific
   to individual signal types.  Locator Metadata MAY include compressed
   attributes about the bottleneck that is relevant for the use case
   e.g., capacity of the bottleneck port, stage of the bottleneck device
   in the data center topology, orientation of the bottleneck port -
   uplink / downlink.  LM MAY also include expanded attributes of the
   bottleneck (e.g., port ID, TTL).  This document provides
   recommendations for the type of information that locator metadata MAY
   carry, but it does not require any specific set of metadata to be
   supported.  Metadata that is useful and viable to support will depend
   on the production setting, which is out of scope for this document.
   Instances of CSIG deployment MAY include locator metadata with
   custom-defined metadata beyond those described in this document.
   Section 5.5 discusses requirements for supporting LM in devices.

   End hosts initialize LM to a default value.  Transit devices that do
   not update the Signal Value S on a given packet MUST NOT alter LM on
   the packet.  Transit devices that update S on a packet MUST update LM
   on the same packet.








Ravi, et al.              Expires 5 August 2024                [Page 13]

Internet-Draft                    CSIG                     February 2024


4.2.  CSIG Reflection Header Format

   CSIG reflection enables consumption of tag data fields at the point
   where the signals are needed for telemetry or control.  This
   mechanism is particularly relevant for sender-driven / source-based
   telemetry and control.  For receiver-driven transports and
   controllers, CSIG reflection may not be necessary as the signals on
   the CSIG tag are available at the receiver without reflection (See
   Section 4.3).

   This document provides recommendations on how CSIG reflection SHOULD
   be implemented, and provides the framework to make the implementation
   deployment-specific.

   CSIG reflection header is a separate header from the CSIG tag,
   implemented at layer 4 or above.  The location of the header and the
   choice of which packets carry the header are transport-specific.  As
   an example, the header can be carried on TCP ACK packets from the
   receiver back to the sender.  Note that the presence of ACK
   coalescing, piggybacked ACKs, Selective Acknowledgements (SACK) etc.
   can impact the behavior of CSIG reflection.  More generally, there
   may not be a 1:1 mapping between forward and reverse path packets.
   In a scenario where the transport implements ACK coalescing, the CSIG
   reflection header SHOULD reflect the latest CSIG-tag data fields
   received across the packets being acknowledged or a more advanced
   summary of the CSIG-tag data fields across the packets being
   acknowledged.  It is important to note that since Signal Type is
   chosen on a per-packet granularity, a coalesced ACK may acknowledge
   multiple packets that carry different signal types in their CSIG-
   tags.  In such a scenario, the reflection header MAY only reflect one
   of the signals.  The sender transport should choose Signal Type for
   packets in a way that ensures that it can continue to receive all
   signals of interest.

   CSIG reflection header MAY include all of the CSIG data fields i.e.,
   2B for the compact version and 6B for the expanded version.  However,
   one could optimize header space and include only a subset of the data
   fields if the consumer is interested only in a subset of signals or
   locator metadata.

   CSIG reflection is an end-host-only protocol and transit devices do
   not participate in it.  Therefore, CSIG reflection header can be
   incorporated in portions of the packet that are e2e encrypted via PSP
   or IPSec.

   The following subsections discuss locations in the packet header
   where CSIG reflection could be implemented for different transports




Ravi, et al.              Expires 5 August 2024                [Page 14]

Internet-Draft                    CSIG                     February 2024


4.2.1.  Reflection in TCP

   Reflection in TCP is typically achieved via TCP options.  CSIG
   Reflection can be implemented via a new TCP Option, identified by a
   unique Kind.

      0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Kind     |    Length     |       CSIG data fields         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Kind              : Unique codepoint to recognize TCP CSIG option
      Length            : Length in bytes of the CSIG data fields
                          carried in the options payload
      CSIG data fields  : Values reflected from receiver to sender

                    Figure 3: CSIG Reflection TCP Option

4.2.2.  Reflection in non-TCP Transports

   Several transports such as QUIC [RFC9000] and PonyExpress
   [PONYEXPRESS] are built atop UDP.  Reflection in UDP can be achieved
   by including CSIG data fields in the UDP payload from receiver to
   sender.  For unidirectional UDP traffic, an out-of-band reverse
   connection from the receiver to the sender may be necessary for CSIG
   reflection.

   As an example, PonyExpress [PONYEXPRESS] is a custom transport
   implemented within a userspace host networking stack.  It supports a
   flexible L4 wire protocol that periodically changes as new features
   are added (Sec 3.1 in Snap).  CSIG reflection can be implemented as
   additional bytes within this wire format.

                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      |    Flags    | CSIG data fields|
                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 4: PonyExpress CSIG Reflection header

   For simplicity and to avoid the need for negotiation, the CSIG
   reflection header can be carried on all packets independent of
   whether CSIG is enabled on them.  The Valid bit in the Flags field
   can be set to 1 for packets that carry valid data fields in the
   reflection header.  In certain deployments, negotiation is
   unavoidable for a variety of reasons.  Section 6.3.3 provides details
   regarding options for negotiation.



Ravi, et al.              Expires 5 August 2024                [Page 15]

Internet-Draft                    CSIG                     February 2024


4.3.  CSIG Operation - Life of a packet

   This section describes the end-to-end operation of CSIG with the
   walkthrough of the life a packet.  It assumes that all nodes in the
   path are CSIG-capable and omits the negotiation phase.  Details of
   negotiation are covered in in Section 6.3.3

                               Forward Path
        --------------------------------------------------------->

        <---------------------------------------------------------
                               Reverse Path

   +------+   +-----+   +------+  +------+  +------+  +-----+   +------+
   | Host +---+ ToR +---+ Aggr +--+ Core +--+ Aggr +--+ ToR +---+ Host |
   +------+   +-----+   +------+  +------+  +------+  +-----+   +------+

           C:   800G      100G      100G      100G      40G

         ABW:   100G       95G       70G       90G      20G
                                                        ---
       ABW/C:  12.5%       95%       70%       90%      50%
               -----
           D:   10us       3us      18us       5us      8us
                                    ----

        Figure 5: Life of a CSIG packet.  Underlined values show the
        forward path bottlenecks for the corresponding signal types

4.3.1.  Forward Path

   The sender end-host first constructs a CSIG-tagged packet for a flow
   of interest and sends out the packet with the tag data fields
   initialized.  The transport determines these initial values for the
   packet, including Signal Type to request and default values for the
   other data fields.  Each transit device performs a compare-and-
   replace on the CSIG-tag to optionally update the Signal Value and
   Locator Metadata fields on the tag.  As the packet traverses through
   the network, the CSIG-tag data fields accumulate the desired
   aggregation of the requested signal.











Ravi, et al.              Expires 5 August 2024                [Page 16]

Internet-Draft                    CSIG                     February 2024


4.3.2.  Reverse Path

   When the CSIG-tagged packet reaches the receiver end-host, the data
   fields in the CSIG tag are extracted and delivered to the transport
   layer at the receiver.  The transport stores the data fields of the
   packet to be reflected, or a summary of these fields across packets.
   It reflects these data fields in the layer-4 CSIG reflection header
   on packets traversing the reverse path from receiver to sender.  The
   CSIG reflection header is unmodified as the packet travels from
   receiver to sender.  The sender extracts the CSIG data fields from
   the CSIG reflection header of the incoming packet, and hands it to
   the transport layer for use in applications at the sender.  As a
   result, the sender transport learns the desired signal for a flow
   within approximately one round-trip time.

4.3.3.  Multiple signals

   The transport layer has a significant role to play in making CSIG
   usable.  Although the CSIG data fields are carried on packets, the
   measurements are ultimately relevant at the flow / connection level
   for specific paths.  If the sender transport desires to obtain
   multiple signals for the same flow, it MAY choose Signal Type on a
   per-packet basis (e.g., in a round robin fashion across the flow's
   packets), and internally keep track of all of the requested signals
   as part of the flow's state variables.  This approach allows the
   sender transport to use all supported CSIG signals for use cases such
   as congestion control, load balancing and multipathing.

4.4.  Device Roles

   CSIG has three participating entities, each with their own roles and
   responsibilities for achieving end-to-end congestion signaling.

4.4.1.  Sender host

   The sender host is responsible for

   (i) Constructing CSIG-tagged packets for flows of interest and
   initializing the CSIG-tag data fields on each packet as specified by
   the transport, and

   (ii) Parsing the CSIG reflection header received in incoming packets
   and extracting CSIG data fields for use in the sender transport /
   applications.

   Only the sender is allowed to insert CSIG-tags into packets.





Ravi, et al.              Expires 5 August 2024                [Page 17]

Internet-Draft                    CSIG                     February 2024


4.4.2.  Transit device

   Transit devices are responsible for

   (i) Computing and tracking Congestion signals such as ABW and ABW/C
   of each port and hop delay per packet

   (ii) Parsing the CSIG-tag based on the TPID code point on incoming
   packets to identify the Signal type being requested, and

   (iii) Performing compare-and-replace on the Signal value and locator
   metadata fields on the CSIG-tag based on the aggregation
   corresponding to the requested signal type (min / max)

   Transit devices MUST NOT add CSIG tags to incoming packets that are
   not already CSIG-tagged.  Transit devices MAY delete the CSIG tag
   before forwarding the packet.  This functionality can be exercised
   when downstream devices are not CSIG-capable.  Further discussion on
   this topic is in Section 6 on Incremental Deployment of CSIG.

4.4.3.  Receiver host

   The receiver host is responsible for

   (i) Extracting the CSIG-tag on incoming packets and exposing the data
   fields to the transport layer and/or receiver-driven applications

   (ii) Inserting and populating the CSIG Reflection header at the
   transport layer for packets traversing the reverse path to the
   sender.

4.4.4.  Host roles for bidirectional flows

   Note that for bi-directional flows, the Sender and Receiver are
   specific to each direction within the flow.  For a bi-directional
   flow between hosts A and B,

   (i) A plays the Sender host role and B plays the Receiver host role
   for data packets traveling from A to B, and similarly

   (ii) B plays the Sender host role and A plays the Receiver host role
   for data packets traveling from B to A.









Ravi, et al.              Expires 5 August 2024                [Page 18]

Internet-Draft                    CSIG                     February 2024


   In this scenario, packets traversing from A to B contain both a CSIG-
   tag that captures the congestion signals on the forward A-->B path,
   and a CSIG reflection header that captures the CSIG data fields of
   the reverse B-->A path.  Equivalently, packets traversing from B to A
   contain both a CSIG-tag that captures the congestion signals on the
   forward B-->A path, and a CSIG reflection header that captures the
   CSIG data fields of the reverse A-->B path

5.  Signals in CSIG

   As described in the previous section, Signal Type indicates the type
   of congestion signal that CSIG-tag carries on each packet.  Up to 8
   signal types are supported by the compact format and up to 16 signal
   types are supported by the expanded format.

   In this section, we concretely define three signals driven by use
   cases described in Section 8.  While Section 8 covers how these three
   signals are useful to applications, this section focuses on precise
   definitions of these signals and how they may be implemented on
   transit devices.

   Note for future extensions: Signals in CSIG are intended to be
   aggregation functions of individual per-hop or per-port signals
   across the path of a packet.  The typical definition of such signals
   with max / min aggregations captures the notion of a path bottleneck
   for different definitions of bottleneck.  However, structurally, the
   format supports arbitrary read-modify-write operations, including
   aggregations such as max, min, count and sum, allowing future use
   cases to leverage this structure for new signals.

5.1.  Minimum Available Bandwidth - min(ABW)

   min(ABW) captures the minimum absolute available bandwidth (in bps)
   across all the ports in the packet path.  Available bandwidth is
   defined per egress port on each device.

5.1.1.  ABW Computation

   ABW can be computed using one of many algorithm variants, each having
   implications on HW or SW implementation complexity, timescales of
   computation and accuracy of the signal.  In its rudimentary form, the
   raw ABW for a given egress port p over a time interval delta_t can be
   computed as follows:

   // delta_txbit is the number of bits that exited on the wire
   utilization_bps[p] = (delta_txbit[p]) / delta_t;
   // capacity_bps[p] captures the link speed of port p
   abw_bps[p] = capacity_bps[p] - utilization_bps[p];



Ravi, et al.              Expires 5 August 2024                [Page 19]

Internet-Draft                    CSIG                     February 2024


   Implementation of these computations relies on at least one of the
   following capabilities in the devices:

   *  Timer-based computations: Most networking ASICs maintain hardware
      counters that track the number of bits that exit on each egress
      port.  To compute available bandwidth, a periodic-timer thread in
      SW or HW triggers the computation and update of available
      bandwidth every delta_t time interval , where delta_t is a
      configurable parameter.

   *  Per-packet computations: In this alternative, available bandwidth
      is computed and updated on every packet that is processed via the
      egress pipeline, typically in HW e.g., via Exponential Weighted
      Moving Average (EWMA) estimation where the weights are
      configurable. delta_t is not an explicit parameter in this
      approach, and is implicitly determined by EWMA weights.

   Variants such as Discounted Rate Estimator (DRE) [CONGA] use a
   combination of per-packet updates and timer-based approaches.

5.2.  Maximum link utilization - max(U/C) or min(ABW/C)

   ABW/C captures the fraction or percentage of available bandwidth on a
   given link relative to the link's capacity.  min(ABW/C) captures the
   link utilization bottleneck along the path of the packet.  This
   signal is most relevant in paths with heterogeneous link speeds,
   where it distinguishes itself from min(ABW). min(ABW/C) is equivalent
   to max(U/C), where

   U = utilization of a given egress port in bps
   C = capacity of a given egress port in bps
   ABW = available bandwidth of a given egress port in bps

   Therefore, max(U/C) = max (1 - ABW/C) = 1 - min(ABW/C)

5.2.1.  ABW/C Computation

   ABW/C can be computed from ABW as follows:

   // Represents fraction of available bandwidth on port p
   // relative to the port's capacity.
   abwc_frac[p] = abw_bps[p] / capacity_bps[p];

   Algorithms for ABW computation described in Section 5.1.1 also apply
   to ABW/C computation, except that the resulting value is normalized
   by the port capacity.  Quantization / bucketing is performed after
   normalization.




Ravi, et al.              Expires 5 August 2024                [Page 20]

Internet-Draft                    CSIG                     February 2024


5.2.2.  min(ABW) vs min(ABW/C) bottlenecks

   On paths with heterogeneous link speeds, min(ABW) and min(ABW/C)
   bottlenecks are not necessarily the same ports.  Figure 2 shows an
   example where these two bottlenecks are different.  Each type of
   bottleneck has its own value, as demonstrated in Section 8.

5.3.  Shared requirements for min(ABW) and min(ABW/C)

5.3.1.  Algorithm Requirements

   To support min(ABW) or min(ABW/C) in CSIG, the device SHOULD support
   raw ABW computation with a configurable delta_t, and MAY support
   additional algorithms such as EWMA or DRE.  This requirement enables
   the consistent interpretation of timescale over which available
   bandwidth is computed.  This consistent interpretation allows end-
   hosts to tune their control decisions based on this timescale e.g.,
   in relation to the flow's RTT.

5.3.2.  Timescale and Accuracy Requirements

   CSIG does not set strict requirements on the delta_t values to be
   supported by the implementation, except that it SHOULD be
   configurable to cover the range of RTTs in the network e.g., {10us,
   100us, 1ms, 10ms, 100ms, 1s etc.}.  Although one would expect all
   devices on a packet path to compute ABW at similar timescales to
   provide a consistent path-wide view, CSIG does NOT set strict
   requirements on the consistency of delta_t parameters chosen across
   the devices of a packet path.  Choices of signal accuracy and
   timescales are a function of the use case and are not enforced by
   CSIG.  End hosts MAY use EWMA across packets of a flow to calculate
   ABW or ABW/C over a longer timescale when CSIG on each packet carries
   ABW or ABW/C over shorter timescales.  This technique is useful when
   flows traversing a given egress port span a wide range of RTTs while
   ABW computation over the egress port is fixed to a chosen timescale
   at each transit device.

5.3.3.  Bucketing / Quantization Requirements

   The computed ABW or ABW/C values MUST be compressed to fit in the
   available Signal value bits on the CSIG-tag.  The device MUST support
   32 fully configurable ABW buckets and ABW/C buckets for compact CSIG,
   and configurable quanta for uniform quantization in expanded CSIG.
   All devices along the packet path MUST be configured with the same
   buckets / quanta per signal type in order to correctly compute
   min(ABW) or min(ABW/C) along the path.  Appendix A provides examples
   of these configurations.




Ravi, et al.              Expires 5 August 2024                [Page 21]

Internet-Draft                    CSIG                     February 2024


   Each transit device performs a compare-and-replace, i.e., updates the
   signal value on the CSIG tag if the incoming ABW or ABW/C signal
   value on the packet is higher than the device's locally computed ABW
   or ABW/C value for the packet's egress port, post bucketization /
   quantization.  E.g.,

   // Update the signal value on packet if current hop is the bottleneck
   pkt->csig_tag->abw = min(pkt->csig_tag->abw, egr_port->abw)

5.3.4.  QoS requirements

   min(ABW) and min(ABW/C) are unambiguous signals with low
   implementation complexity on network devices.  For simplicity, these
   definitions intentionally do NOT distinguish across QoS classes that
   may share the egress port.  Available bandwidth per QoS class on an
   egress port is complex to define and meaningfully interpret since it
   depends on the scheduling policy (Strict Priority / WRR / Deficit
   WRR), buffer carving configuration and other policies (e.g., AQM)
   associated with QoS.  Section 8 describes the applications of
   min(ABW) and min(ABW/C) as defined.  We leave QoS-based variations of
   these signals and their potential use cases as future work.

5.4.  Maximum Per-hop Delay - max(PD)

   max(PD) captures the maximum per-hop delay experienced by a packet
   among all the hops in the packet path.  Per-hop delay PD is the time
   spent by the packet in the device pipeline.  It MAY include link
   layer delays or it MAY only include the delays observed in the
   forwarding pipeline.

5.4.1.  Per-hop Delay Computation

   Unlike ABW and ABW/C which are per-port signals, PD is a per-packet
   signal.  It consists of PHY, MAC and switch pipeline delay
   experienced by the packet.  Pipeline delay is the most relevant
   component as it captures congestion related queueing delay.  Device
   implementations MAY track ingress and egress timestamps explicitly
   for each packet and perform a diff in the final stages of the
   pipeline.  Precise definitions of these stages depend on the
   architecture of the device.  For example, some devices could leverage
   existing timestamping support from tail timestamping capabilities for
   this purpose.

5.4.2.  Requirements







Ravi, et al.              Expires 5 August 2024                [Page 22]

Internet-Draft                    CSIG                     February 2024


5.4.2.1.  Algorithm Requirements

   To support max(PD) in CSIG, the device SHOULD support per-packet
   tracking of delay experienced through the device.

5.4.2.2.  Accuracy Requirements

   It is desirable to have minimal gaps in the components of packet
   delays captured by the device.  However, CSIG does NOT set strict
   requirements on the accuracy of PD to be supported by the
   implementation.

5.4.2.3.  Bucketing / Quantization Requirements

   The computed delay values MUST be compressed to fit in the available
   Signal value bits on the CSIG-tag.  The device MUST support 32 fully
   configurable delay buckets for compact CSIG, and configurable quanta
   for uniform quantization in expanded CSIG.  All devices along the
   packet path MUST be configured with the same buckets / quanta to
   correctly compute max(PD) along the path.

   Each transit device performs a compare-and-replace, i.e., updates the
   signal value on the CSIG tag if the incoming delay signal value on
   the packet is lower than the device's locally computed delay for the
   packet, post bucketization / quantization.  E.g.,

   // Update the signal value on packet if current hop is the bottleneck
   pkt->csig_tag->pd = max(pkt->csig_tag->pd, device->pkt->pd)

5.4.2.4.  QoS requirements

   Delay experienced by the packet on a device, as defined, is
   implicitly a QoS-specific signal.  This is because the packet is
   subject to QoS policies as it traverses through the device pipeline,
   including prioritization, scheduling and buffering.  For example, a
   high priority packet may see smaller delays than low priority
   packets.  Therefore, the delay measured for the packet SHOULD include
   components in the pipeline where QoS policies are applied.

5.5.  Locator Metadata Implementation

   Locator metadata (LM) captures information about the bottleneck
   device or port, as described in Section 4.1.3.3.  In this section, we
   discuss requirements for supporting LM in CSIG, and provide
   recommendations for commonly useful attributes to carry in LM.






Ravi, et al.              Expires 5 August 2024                [Page 23]

Internet-Draft                    CSIG                     February 2024


5.5.1.  Requirements

   A single deployment MAY choose a subset of the attributes in
   Section 5.5.2 and/or newly defined attributes beyond those listed in
   Section 5.5.2 to include in LM.  However, the total size of the
   individual attributes MUST be within 7 bits for Compact CSIG and
   within 16 bits for Expanded CSIG.

   CSIG does not set strict requirements on the LM internal format i.e.,
   how the individual attributes are organized among the available LM
   bits.  However, this LM internal format MUST be consistent across
   devices in the deployment domain so that the end hosts can
   consistently interpret these bits.  The LM internal format MAY be
   specific to each signal type.

   Devices SHOULD support configuring per-port values for LM to be
   written on the CSIG-tag.  Devices MAY provide more granular
   configurability of LM based on Signal type as well.  CSIG packets
   egressing on a given port that have their Signal Value updated by the
   device MUST be updated with the LM corresponding to the port and
   Signal Type.

5.5.2.  Attributes

   Attributes can be designed to capture the level of resolution desired
   by use cases for pinpointing the bottleneck.  Attributes may be
   encoded to fit within the limited number of LM bits available in
   CSIG.

   We separate the list of attributes into compact attributes and
   expanded attributes.  Compact attributes are motivated by the limited
   number of LM bits available in Compact CSIG, and therefore capture
   only the essential information about the bottleneck that is necessary
   for the use cases i.e., to inform control decisions or telemetry.
   Expanded attributes provide higher resolution information about the
   bottleneck, and can aid in directly pinpointing bottleneck devices or
   ports.  Expanded attributes typically require more bits and are hence
   more suited for Expanded CSIG.

   Examples of attributes are listed below.

5.5.2.1.  Compact Attributes

   *  Link capacity: Encodes the capacity of the bottleneck link.  In
      typical deployments, the number of link speeds deployed is a small
      set, can be encoded using <= 5 bits.





Ravi, et al.              Expires 5 August 2024                [Page 24]

Internet-Draft                    CSIG                     February 2024


   *  Stage of the bottleneck: Encodes the stage of the topology where
      the bottleneck device / port is located.  For example, in a
      5-stage clos topology, the stage of the device can be encoded with
      3 bits.

   *  Link orientation: Encodes the direction of a port in the context
      of the network topology.  For example, with three categories -
      uplinks, downlinks and side-links - link orientation can be
      encoded using 2 bits.

5.5.2.2.  Expanded Attributes

   *  Port ID: Encodes a unique identifier for each port within a
      deployment domain.

   *  Device ID: Encodes a unique identifier for each device within a
      deployment domain.

   *  TTL (Time-to-live): Captures the TTL value of the packet at the
      bottleneck device, represented using 8-bits.  End hosts can use
      this attribute to infer the hop number at which the packet was
      bottlenecked.

   LM attributes and encoding schemes are ultimately deployment specific
   and use-case specific.  CSIG supports a flexible specification of LM
   to accommodate a variety of requirements and future applications.

6.  Incremental Deployment of CSIG.

   Most production networks are heterogeneous, with a mix of network
   devices across generations.  This document addresses the brownfield
   deployment of CSIG in a heterogeneous network, where there may be a
   mix of devices that offer varying degrees of support for CSIG packet
   construction and processing.

6.1.  CSIG Stripping: A per egress-port primitive

   Before describing incremental deployment, we introduce the idea of
   CSIG stripping, an action primitive which is foundational to
   deploying CSIG in a heterogeneous environment.

   Devices that support CSIG MUST be capable of removing the CSIG tag
   before forwarding the packet.  Devices MUST allow configuring CSIG-
   stripping on a per egress-port basis.  If a port is configured to
   strip CSIG, then all CSIG-tagged packets that egress on this port
   must have the tag removed before being forwarded.





Ravi, et al.              Expires 5 August 2024                [Page 25]

Internet-Draft                    CSIG                     February 2024


   In the following sections, we describe how this capability can enable
   incremental deployment.

6.2.  Levels of CSIG Support

   We first classify devices into three simplified categories based on
   their level of CSIG support.  In the subsequent sections we describe
   how CSIG can interoperate with each category of device.  Note that
   the level of support is a function of the tag placement and whether
   the compact or expanded CSIG tag format is used as shown in
   Section 4.1.

6.2.1.  Discard

   Devices in this category are not capable of recognizing or parsing
   CSIG tagged packets.  If such packets are received, they will simply
   be dropped.

6.2.2.  Pass-through

   Devices in this category are able to recognize and parse CSIG tagged
   packets, and transparently forward the packet with the tag intact or
   with the tag stripped to neighboring devices (in the case of transit
   devices) or to the end host transport layer (in the case of end
   hosts).  However, they do not support updating the CSIG data fields
   on the tag.

   Some devices that do not natively support CSIG may be configured to
   support pass-through mode for CSIG if they support VLAN tags with
   configurable TPIDs.  This is discussed in more detail in Section 6.4.

6.2.3.  Complete

   Devices in this category support the complete CSIG protocol,
   including recognition, parsing, forwarding, tag-stripping, signal
   computation, and signal updates on the tag.  However, only a subset
   of signal types may be supported.

6.2.3.1.  Software-assisted support

   It is noteworthy that in some devices that do not natively support
   CSIG, resources available for VLAN tag processing can be repurposed
   to support CSIG for certain signal types using a combination of
   software and hardware capabilities.  We refer to this level of
   support as software-assisted support.  This capability is discussed
   in more detail in Section 6.4.





Ravi, et al.              Expires 5 August 2024                [Page 26]

Internet-Draft                    CSIG                     February 2024


6.2.3.2.  Native support

   Devices that natively support CSIG are explicitly equipped with the
   hardware capabilities required to implement the CSIG protocol.

   A CSIG domain is a deployment domain where all network devices have
   complete support or pass-through support for CSIG.

6.3.  Interoperability in Brownfield Deployments

   In this section, we first define the requirements for CSIG
   Interoperability in brownfield deployments.  Then, we consider
   devices with all levels of support described in Section 6.2 and
   describe how these devices MAY be configured to achieve
   interoperability.  Note that the following descriptions apply
   separately to both Compact and Expanded CSIG-tags.

         +==============+=======================================+
         | Device       | Interop support                       |
         | category     |                                       |
         +==============+=======================================+
         | Discard      | Upstream devices must strip CSIG tags |
         |              | before packets reach this device      |
         +--------------+---------------------------------------+
         | Pass-through | Device may strip tag or transparently |
         | support only | forward with tag unmodified depending |
         |              | on e2e signal accuracy requirements   |
         +--------------+---------------------------------------+
         | Native CSIG  | Device updates CSIG-tag as per        |
         | support      | protocol                              |
         +--------------+---------------------------------------+
         | SW-assisted  | Device updates CSIG-tag using VLAN    |
         | CSIG support | match/action with approximate signals |
         |              | computed in S/W agent                 |
         +--------------+---------------------------------------+

              Table 1: Interoperability with devices having
                     different levels of CSIG support

6.3.1.  Requirements for interoperability

   Forwarding: The fundamental requirement is that no CSIG-tagged packet
   should be dropped in the network due to a lack of CSIG support on a
   device.  This requirement means packets with CSIG-tags MUST never
   reach devices in the Discard category, or MUST have their CSIG-tag
   stripped before reaching such devices.





Ravi, et al.              Expires 5 August 2024                [Page 27]

Internet-Draft                    CSIG                     February 2024


   Negotiation: End hosts / flows SHOULD ensure that the path (including
   end hosts and transit devices) is CSIG-capable before enabling CSIG-
   tagging on packets.  Devices in the Discard category should not
   require any changes in order to achieve negotiation.  This
   requirement is to ensure correctness of data fields in end-to-end
   CSIG operation, and to interoperate with legacy devices or software
   stacks.

6.3.2.  Forwarding

   To achieve forwarding interoperability requirements for CSIG, CSIG
   stripping may be exercised as shown below

   *  When a neighboring device connected to a given egress port is a
      Discard device and cannot parse CSIG packets, this egress port
      MUST be configured to strip the tag on outgoing packets to ensure
      that the packet does not get dropped downstream.

   *  When a device supports Pass-through only or does not support the
      requested signal type on a CSIG packet, egress ports on this
      device MAY be configured to strip the tag on outgoing packets to
      ensure that CSIG does not carry inaccurate information.  In some
      use cases where it is acceptable for CSIG to miss capturing
      signals on certain hops, pass-through devices MAY transparently
      forward the packet with the CSIG tag intact.

   *  At the boundary of a CSIG domain, device ports that are connected
      to devices outside of the CSIG domain MUST strip the tag to ensure
      that packets exiting the domain do not contain CSIG-tags.  Only
      egress ports connected to devices within the CSIG domain SHOULD
      retain CSIG-tags on outgoing packets.

   CSIG packets and non-CSIG packets can be used together in a
   brownfield setting.  This requirement means that end hosts MUST be
   capable of transmitting and receiving both CSIG packets and non-CSIG
   packets, including for the same flow.  A packet marked with CSIG-tag
   at the sender host may arrive at the receiver host without the tag.
   In addition, Compact CSIG and Expanded CSIG packets may be used
   together on the same network.

6.3.3.  Negotiation

   Support for sending and receiving CSIG-tagged packets may require
   software and/or hardware changes on transit devices and end hosts.
   In many deployments, particularly those requiring hardware upgrades
   to support CSIG (such as Switch or NIC support), version stragglers
   continue to exist for long time horizons for a variety of reasons,
   and interoperability with such stragglers is a critical requirement.



Ravi, et al.              Expires 5 August 2024                [Page 28]

Internet-Draft                    CSIG                     February 2024


   Without negotiation for CSIG capability, devices that are not CSIG-
   compliant may drop CSIG packets and thus blackhole traffic.
   Negotiating for CSIG-capability of a path is critical to ensure that
   CSIG protocol operates safely end-to-end in a brownfield deployment.

   A path is considered CSIG-capable if end-hosts have at least Pass-
   through CSIG support and transit devices have Complete CSIG support
   (native or software-assisted).  Before sending CSIG-tagged packets on
   a network flow, end-hosts must negotiate for path CSIG-capability.
   We discuss one approach to negotiation for path CSIG-capability,
   which involves two parts: negotiation for transit device support and
   negotiation for end host support.

6.3.3.1.  Negotiation for transit device support

   In this section, we describe one simple approach to negotiate CSIG
   support on transit devices with CSIG stripping.

   CSIG stripping can be used to implicitly achieve negotiation by
   removing the CSIG-tag from the packet header at or before devices on
   the packet path that do not have the desired level of CSIG support.
   If the receiver end host receives a CSIG-tagged packet, it serves as
   an explicit indication that all devices on the packet path, including
   transit devices and end-hosts, have the desired CSIG support.  If the
   receiver end host receives a packet without a CSIG-tag, it is an
   indication that one or more devices do not have the desired CSIG
   support, or that the packet was not tagged at the sender to begin
   with.  This indication can be implicitly reported to the sender via
   an empty / invalid CSIG reflection header and the sender can
   determine whether the packet path was CSIG-capable.

   This approach assumes that each device has knowledge about the level
   of CSIG support in its immediate neighboring devices, which is viable
   through configuration in typical private SDN networks.  In the
   absence of centralization, mechanisms such as a new LLDP TLV may be
   defined to advertise aspects of CSIG support on the device, including
   compact vs expanded CSIG-tag support, signal types that are
   supported, pass-through vs complete support etc.  We leave the
   details of such an LLDP extension for future extensions of the
   protocol.











Ravi, et al.              Expires 5 August 2024                [Page 29]

Internet-Draft                    CSIG                     February 2024


6.3.3.2.  Negotiation for end host support

   A sender end host may need to explicitly negotiate with the remote
   end-host to ensure that the host networking stack at the remote host
   has the desired level of CSIG support.  Ideally such explicit CSIG
   negotiation should be performed during or before the initial
   connection handshake, after which CSIG is enabled / disabled on
   packets post connection establishment.  It may also be necessary to
   explicitly negotiate the use of CSIG Reflection in transports,
   separately from the negotiation for path CSIG-capability.  For
   example, in TCP, negotiation is required to use the CSIG Reflection
   TCP Option.  We leave the details of such negotiation schemes for
   future extensions of the protocol.

6.4.  Backward Compatibility via Software-assisted CSIG

   Transit devices without native CSIG support MAY participate in CSIG
   protocol via a Software-assisted approach.  This allows brownfield
   deployments to reap incremental benefits of CSIG without having to
   upgrade a significant fraction of device HW on their networks.

   Since compact and expanded CSIG tags are structurally similar to
   single VLAN-tags and double VLAN-tags respectively, VLAN resources in
   a transit device can be repurposed to support CSIG updates.  More
   specifically, configurable TPIDs for VLAN tags can be used to treat
   CSIG tags as VLAN tags, and VLAN match/action resources for tag
   updates in the device can be leveraged to support updating CSIG data
   fields on the tag.

   For signals such as ABW and ABW/C, a software agent running on the
   CPU of a transit device can periodically compute these signals based
   on hardware byte counters, and program VLAN match/action rules in the
   dataplane to update CSIG data fields based on the computed signals.
   Since the match/action rules are in the dataplane, CSIG packets can
   be processed at line rate without CPU involvement.  However the
   match/action rules themselves can be updated at a slower cadence via
   the software agent.

   Compact CSIG is designed to enable software-assisted backward
   compatibility while operating within the constraints of commonly
   available VLAN resources on transit devices.  Backward compatibility
   via software is a fundamental feature in the design of Compact CSIG.

   Note that it may not be possible to track signal types such as hop
   delay per packet in a software agent.  However, approximations of the
   signal based on available hardware counters and registers (such as
   latency histograms) can be implemented in the agent if software-
   assisted support is desired for such signal types.



Ravi, et al.              Expires 5 August 2024                [Page 30]

Internet-Draft                    CSIG                     February 2024


6.5.  Greenfield deployments

   In greenfield deployments of CSIG domains, all devices in the domain
   natively support the CSIG protocol.

   Expanded CSIG is designed to leverage greenfield deployments where
   backward compatibility, negotiation and interoperability are not
   requirements.  It provides enhanced signal resolution via higher bit
   width for signal values and locator metadata in comparison to Compact
   CSIG.  Expanded CSIG can also support up to 16 signal types.

   Devices in Greenfield CSIG domains MUST support CSIG stripping at the
   domain boundary to ensure that CSIG packets don't exit the domain.

7.  Design Rationale

   CSIG's design choices are shaped by an end-to-end perspective of what
   matters to applications and where tradeoffs can be made towards
   simplicity and practicality.  In this section, we discuss the
   rationale behind CSIG's design and the advantages it provides over
   existing state of the art.

7.1.  Choice of Layer 2

   CSIG-tag offsets at layer 2 are independent of headers and payload at
   layer 3 and above, which means that only a small set of tag placement
   offsets need to be supported for reading and updating the header.
   This makes device implementations of CSIG simpler.  In contrast, in-
   band network telemetry schemes implemented at layer 3 or higher
   require support for a large set of packet formats as this set grows
   by the cross-product of formats / encapsulations at each layer.  This
   complexity forces device implementations to restrict support for only
   a fraction of packet formats / encapsulations, hindering the adoption
   and deployment of such schemes.  CSIG-tagging, on the other hand, is
   simpler to support and deploy since it is at layer 2 and has a fixed
   offset despite various formats / encapsulation at layer 3 and above.

   The choice of layer 2 also makes compatibility with in-network
   tunneling and encryption simpler, which are common features in data
   center deployments.

   *  CSIG-tags are, by design, compatible with PSP encrypted packets
      and IPSec encrypted packets, where Layer 4 headers and payloads
      may be encrypted.

   *  CSIG tags are carried through Layer 3 tunnels e.g., IP-in-IP,
      VxLAN, Geneve, at a fixed offset in the packet header.  This
      avoids the need to copy and relocate CSIG tags across inner /



Ravi, et al.              Expires 5 August 2024                [Page 31]

Internet-Draft                    CSIG                     February 2024


      outer headers during encapsulation and decapsulation of packets,
      which would be necessary if implemented instead at layers 3 or
      higher.

   *  CSIG tags are placed as the last header in the Layer 2 header
      stack to ensure compatibility with layer 2 and layer 2.5 tunneled
      domains as well.  The placement of CSIG tags in MACSec and other
      Layer 2 encapsulations is shown in the table in Section 4.1.

   Most in-band network telemetry schemes are not backward compatible.
   However, CSIG tag's structural similarity to VLAN tags enables
   backward compatibility with many devices that don't have native CSIG
   support as described in Section 6.4.  This allows deployments to reap
   the benefits of CSIG without having to upgrade a significant portion
   of their network hardware.

   In addition, since expanded CSIG is limited to 8B, i.e., the size of
   double VLAN tags, the packet parsing depth required on devices to
   read and process headers at layer 3 and above is not affected.

   In summary, the choice of Layer 2 for CSIG-tag is a key part of
   CSIG's simplicity and efficiency, since it keeps device
   implementations simple while supporting multiple encapsulations and
   backward compatibility.

7.2.  Separation of headers for CSIG-tag and reflection

   CSIG's design separates the CSIG-tag and CSIG reflection headers into
   distinct layers.  This decoupling enables end hosts to develop
   different transport-specific implementations of CSIG reflection while
   sharing the underlying CSIG-tag mechanism.  This means that transit
   device behaviors are not impacted by innovations in CSIG reflection.

   In addition, this decoupling enables the separate tracking of forward
   and reverse path bottlenecks.  This is important since CCAs typically
   prefer to react to congestion on the forward path only and not react
   to congestion on the reverse path.  In contrast, in-band schemes that
   mix signaling and reflection into the same header do not provide
   distinctions between forward and reverse path.

7.3.  Fixed-size headers

   CSIG's fixed-size headers constitute less than 0.2% bandwidth
   overhead in packets with 4k or 9k MTU.  This means that there is no
   need for fragmentation or increasing MTU size for the purposes of
   supporting multiple congestion signals.  Furthermore, the performance
   of network device packets per second (PPS) is minimally impacted by
   the inclusion of CSIG tag and reflection headers.



Ravi, et al.              Expires 5 August 2024                [Page 32]

Internet-Draft                    CSIG                     February 2024


   The low overhead allows CSIG to be enabled on all live data packets
   or explicit probe packets or sampled packets.  This is an important
   capability because it allows for the direct quantification of the
   bottlenecks experienced by the data packets themselves instead of
   having to rely on probes.  However, leveraging CSIG on probes or
   sampled packets is still an option for deployments that require such
   visibility.

   CSIG is designed to perform compare-and-replace (or more generally
   read-modify-write for future extensions), with a fixed size header.
   Therefore, CSIG is not limited by the number of hops in a network
   path (i.e., diameter of the network) unlike schemes that append
   information at each hop.

7.4.  Signal Design

   CSIG's signal design focuses on simple, aggregate signals that are
   driven by use cases, as demonstrated in Section 5 and Section 8.

   CSIG allows a single packet to carry only one congestion signal.  To
   obtain multiple signals at the end hosts, it takes advantage of the
   fact that the end host can request different signal types across
   multiple packets of a flow.  In contrast, other schemes tend to
   overload each packet with a lot of information, including metadata
   about multiple signals, which can be limiting.  Moreover, CSIG-tag's
   format is also extensible, which means that it can be adapted to
   support additional signal types and locator metadata in the future
   without compromising the advantages of CSIG's design.

   A unique feature of Compact CSIG's design is the ability to fully
   configure signal value buckets, which allows for efficient signal
   representations with a limited number of bits.  For example, the
   encodings can be adjusted to provide greater granularity at value
   ranges that are more important to the application, and lower
   granularity at ranges that are less important.  Similarly, locator
   metadata can be efficiently represented by carrying fewer bits of
   relevant compressed attributes of the bottleneck that are important
   to applications.  Expanded CSIG, on the other hand, uses uniform
   signal quantization for more accuracy and provides even more
   flexibility in defining signals and locator metadata with a larger
   bit width.










Ravi, et al.              Expires 5 August 2024                [Page 33]

Internet-Draft                    CSIG                     February 2024


8.  Use Cases defined by Bottleneck Signals

   The use cases for CSIG are motivated by congestion control, traffic
   management and network debuggability.  These use cases have always
   existed in production before CSIG, often using signals that are
   measured end-to-end (such as packet loss and delay), or out-of-band
   signals from network devices such as port utilization.  CSIG provides
   a boost in performance, efficiency and debuggability by augmenting
   existing use cases with explicit in-band measurements.

   In this document, we present the use cases for the three signals
   defined in Section 5.  At the crux of a signal is the definition of
   bottleneck.  Over time we envision use cases for other signals that
   would define a bottleneck, e.g., the maximum number of co-sharing
   flows on a link.  For each of these new signals, locator metadata can
   continue to provide attributes about the bottleneck port such as port
   capacity.

8.1.  Congestion Control

   CCA can make use of CSIG signals in at least two different ways.
   First, existing CCA can use CSIG values to address blindspots in end-
   to-end signals such as packet loss, delay, and delivery rates.  This
   use case is immediately relevant as most production networks deploy
   some form of end-to-end congestion control including Swift [SWIFT],
   and BBR [BBR].  A second way to use CSIG is to design entirely new
   congestion control algorithms that use CSIG as their primary signal.
   We focus below on the former category.

   E2E CCA comes in various forms and for simplicity we describe the use
   cases taking Swift CC [SWIFT] as the baseline.  Swift is delay-based
   congestion control that uses accurate round-trip time (RTT)
   measurements done via the NIC hardware timestamps.  These signals can
   be applied to other CCA and are NOT limited to Swift.

   The interpretation and applications of CSIG for congestion control in
   lossless networks and networks that use packet spraying is a topic
   for future research.

8.1.1.  Using maximum per-hop delay in E2E CC

   E2E RTT measurements used in Swift include the queueing delays on all
   hops along the flows' path, including the forward and reverse paths.
   A consequence of using a lumped delay signal is that a flow reduces
   its sending rate in response to delays that it may not be able to
   directly control.  Furthermore, in deployments where there can be
   multiple congested links along the path of a flow, it is desirable to
   modulate the sending rate of a flow in response to just the maximum



Ravi, et al.              Expires 5 August 2024                [Page 34]

Internet-Draft                    CSIG                     February 2024


   of the per-hop delays, max(PD), along a flows' path.  Replacing the
   end-to-end measured delay with bottleneck delay into Swift's equation
   yields the following:

   // Reduce the congestion window when bottleneck hop delay
   // exceeds a chosen target hop delay
   if (max(PD) > target_delay) then
     md = beta * (max(PD) - target_delay) / max(PD)
     cwnd = (1 - md) *cwnd

   Poseidon [POSEIDON] is a CC proposed in literature that exemplifies
   the use of maximum per-hop delay in reducing its congestion window.
   By incorporating bottleneck information in congestion control
   response, POSEIDON flows achieve higher flow throughputs in presence
   of reverse path congestion, and congestion across multiple network
   hops.  Algorithm 1 in [POSEIDON] details the use of maximum per-hop
   delay in both the increase and the decrease of the congestion window.

8.1.2.  Using maximum link utilization in E2E CC

   E2E CC uses heuristics to determine by how much to increase the
   congestion window, e.g., in the case of Swift, when the measured
   round-trip time is lower than the target delay, Swift increments the
   congestion window by one per round-trip time.  BBR [BBR] increases
   the rate as a function of the flow's measured delivery rate.

   The problem with these heuristics is that they don't get the rate or
   window adjustments just right and either under or overshoot.
   Undershooting the rate would mean that transfers take longer to
   complete even when the bottleneck link has a low utilization, while
   overshooting can cause an unnecessary increase in queueing delay and
   packet losses.

   In the following example, we integrate the maximum utilization signal
   into Swift's congestion window update equation to ramp up adaptively
   faster when the bottleneck link has low utilization.  The congestion
   window evolution is represented below:

   // Increase congestion window in proportion
   // to the utilization headroom
   if (rtt < target_rtt) then
     fcwnd <-- fcwnd + additive_increment
               + kLambda . fcwnd . (1 - max(U/C))








Ravi, et al.              Expires 5 August 2024                [Page 35]

Internet-Draft                    CSIG                     February 2024


   As an example, the fixed additive increase in Swift of rate <-- rate
   + Additive Increment, means that it takes 200 RTTs to take 80 Gbps of
   bandwidth with an Additive Increment of 400 Mbps.  The fast ramp-up
   with CSIG using the bottleneck link utilization takes <10 RTTs to
   safely ramp to 80 Gbps.

8.1.3.  Using minimum available bandwidth in E2E CC

   E2E CC uses heuristics to determine the initial transfer rate for
   newly established connections.  Starting too slowly would cause the
   transfer to take longer than necessary while wasting available
   bandwidth, whereas starting too quickly would cause queue delays and
   packet drops.  The same dilemma exists for transfers that are
   starting on a connection that has been idle for multiple round-trip
   times.

   In networks where we know ahead of time that the degree of
   multiplexing is low i.e., just a handful of flows co-existing on the
   link at any point in time, transfers complete quickly when they
   "jump-start" to use up all of the bottleneck bandwidth.  This is
   especially helpful when transports employ robust loss recovery
   mechanisms such that even if the queue overflows, any lost packets
   can be quickly recovered.

   As an example, on an empty network of 200Gbps, a single transfer can
   use up the entire 200Gbps in the second RTT, after the CSIG feedback
   in the first RTT indicates the availability of 200Gbps at the
   bottleneck link.

   CSIG's min(ABW) bottleneck bandwidth allows transfers to start safely
   at line-rate.

8.2.  Traffic Management

   CSIG encodes the most notable information about the path for each
   flow by carrying bottleneck link signals and bottleneck locator
   metadata.  This path-level information, which is obtained directly
   from application data packets rather than synthetic probes, is
   directly attributable to the flow and is valuable for traffic
   engineering and application performance debugging.











Ravi, et al.              Expires 5 August 2024                [Page 36]

Internet-Draft                    CSIG                     February 2024


8.2.1.  Load Balancing and Multipathing

   Datacenter topologies employ a diverse set of paths between any
   source-destination pairs.  Transports employ techniques such as
   Protective Load Balancing [PLB] and Multipathing [RFC8684] to spread
   traffic across the multitude of paths.  Load balancing and
   multipathing in transports use a combination of end-to-end signals
   and heuristics to select which paths to use and how much traffic to
   channel in each of the paths.

   Using CSIG signals from bottleneck links along the diverse set of
   paths, load balancing and multipathing schemes can select high
   quality paths with lower congestion, and spread traffic across them
   in a congestion-aware manner.

   Locator metadata can also be used to distinguish between incast
   congestion and core network congestion, which can then be used to
   adjust load balancing / multipathing actions.  For instance, the
   stage of the bottleneck and link orientation attributes are enough to
   determine whether the last hop is the bottleneck or not.  When the
   last hop is the bottleneck, flow-level load balancing / multipathing
   actions may not be effective and may, in fact, worsen incasts.  Such
   cases may require application-level load balancing or job scheduling
   techniques to distribute traffic.  However, when congestion is
   instead known to be in the core network, flow-level load balancing /
   multipathing actions can route around congested areas and improve
   performance.

8.2.2.  Traffic Engineering

   Traffic Engineering carves out paths with apt bandwidth across
   aggregate source-destination pairs.  Examples within a datacenter
   include Datacenter Network Interconnection Layer (DCNI)
   [JUPITEREVOL].  CSIG can be used to provide fine-grained path level
   information, including short timescale microburst congestion, to TE
   systems.  By using summarized CSIG signals aggregated both spatially
   and temporally across flows, TE can select paths and balance traffic
   at the datacenter level to accommodate bursty traffic, e.g., from ML.

8.3.  Application Performance Debugging

   Applications often complain that the network is slow, but it can be
   challenging to identify the specific segment of the network that is
   causing the problem.  This is especially true with the scale of
   datacenters, where flows can traverse up to nine hops [JUPITEREVOL].
   Figuring out where the bottleneck is and the timescales at which the
   path poses a bottleneck is like searching for a needle in a haystack
   for an application with thousands of flows across various source-



Ravi, et al.              Expires 5 August 2024                [Page 37]

Internet-Draft                    CSIG                     February 2024


   destination pairs.

   On application network flows, CSIG information, with its bottleneck
   locator, can quickly and precisely answer why the flows are slow and
   where the network / path bottlenecks are.

   CSIG can also be enabled on mesh prober systems similar to [PINGMESH]
   to augment end-to-end probe measurements between any two servers with
   bottleneck information to aid troubleshooting.

9.  Security Considerations

   Only trusted sender hosts MUST be allowed to construct, initialize
   and insert a CSIG tag into packets for authorized flows.  Based on
   deployments, the authorization can be done at the NICs or at the
   switches, akin to firewall rules.  CSIG stripping may also be
   employed as fencing rules at domain boundaries to ensure that
   unauthorized CSIG-tags are not traversing across these boundaries.

   A rogue or broken network-device in a private network might put in
   arbitrary CSIG values, or insert a CSIG tag in packets on a transit
   node.  We expect there to be checks and balances to identify and take
   non-functioning or rogue network devices out of a private network, as
   they can impose greater harm than distributing misleading CSIG
   values.

10.  IANA Considerations

   There are no IANA considerations.  CSIG Tag Protocol Identifier
   (TPID) is requested from IEEE.

11.  Conclusions

   With the increased deployment of applications that are sensitive to
   delay and bandwidth usage in data centers, e.g., AI/ML/HPC workloads
   and RDMA based applications, relying solely on end-to-end signals is
   insufficient under dynamically changing traffic patterns.  Simple and
   timely signals from network devices to end-hosts can augment and
   optimize end-host transports to make optimal use of datacenter
   bandwidth.  CSIG is a simple, practical and deployable protocol for
   distributing congestion information in networks that builds on the
   successful aspects of prior work and is grounded in use-cases of
   congestion control, traffic management and network debuggability.








Ravi, et al.              Expires 5 August 2024                [Page 38]

Internet-Draft                    CSIG                     February 2024


12.  Acknowledgements

   This work would not be possible without the following individuals
   whose various engineering and design contributions shaped CSIG and
   its use cases:

   Christopher Alfeld, Neelesh Bansod, Jis Ben, Neal Cardwell, Yongzhou
   Chen, Yuchung Cheng, Dal Chand Choudhary, Mick Fingleton, Mahmudul
   Hasan, Jeffrey Ji, Marc De Kruijf, Praveen Kumar, Rich Lane, Chang
   Liu, Morley Mao, Carl Mauer, Sachin Menezes, Nipen Mody, Masoud
   Moshref, Alex Rumyantsev, Gerald Schmidt, Arjun Singh, Arjun Singhvi,
   Babru Thatikunta, Jeff Tikkanen, Frank Uyeda, Brian Vasquez, Rui
   Wang, Hassan Wassel, Yong Xia, Zhengxu Xia, Kevin Yang, Liangcheng
   Yu.

   We would like to thank Arjun Singh, David Wetherall, Neal Cardwell,
   Akash Deshpande and Arvind Krishnamurthy for their feedback on
   several portions of this document.

13.  Normative References

   [BBR]      Cardwell, N., Cheng, Y., Gunn, C., Yeganeh, S., and V.
              Jacobson, "BBR: congestion-based congestion control",
              Communications of the ACM vol. 60, no. 2, pp. 58-66,
              DOI 10.1145/3009824, January 2017,
              <https://doi.org/10.1145/3009824>.

   [CONGA]    Alizadeh, M., Edsall, T., Dharmapurikar, S., Vaidyanathan,
              R., Chu, K., Fingerhut, A., Lam, V., Matus, F., Pan, R.,
              Yadav, N., and G. Varghese, "CONGA: distributed
              congestion-aware load balancing for datacenters", ACM
              SIGCOMM Computer Communication Review vol. 44, no. 4, pp.
              503-514, DOI 10.1145/2740070.2626316, August 2014,
              <https://doi.org/10.1145/2740070.2626316>.

   [DCQCN]    Zhu, Y., Eran, H., Firestone, D., Guo, C., Lipshteyn, M.,
              Liron, Y., Padhye, J., Raindel, S., Yahia, M., and M.
              Zhang, "Congestion Control for Large-Scale RDMA
              Deployments", ACM SIGCOMM Computer Communication
              Review vol. 45, no. 4, pp. 523-536,
              DOI 10.1145/2829988.2787484, August 2015,
              <https://doi.org/10.1145/2829988.2787484>.

   [HPCCPLUS] "High-precision congestion control (HPCC++) deployment at
              Alibaba leveraging In-band Flow Analyzer (IFA)", n.d.,
              <https://www.broadcom.com/blog/high-precision-congestion-
              control>.




Ravi, et al.              Expires 5 August 2024                [Page 39]

Internet-Draft                    CSIG                     February 2024


   [I-D.kumar-ippm-ifa]
              Kumar, J., Anubolu, S., Lemon, J., Manur, R., Holbrook,
              H., Ghanwani, A., Cai, D., Ou, H., Li, Y., and X. Wang,
              "Inband Flow Analyzer", Work in Progress, Internet-Draft,
              draft-kumar-ippm-ifa-07, 7 September 2023,
              <https://datatracker.ietf.org/doc/html/draft-kumar-ippm-
              ifa-07>.

   [I-D.miao-tsv-hpcc]
              Miao, R., Anubolu, S., Pan, R., Lee, J., Gafni, B.,
              Shpigelman, Y., Tantsura, J., and G. Caspary, "HPCC++:
              Enhanced High Precision Congestion Control", Work in
              Progress, Internet-Draft, draft-miao-tsv-hpcc-02, 17 May
              2023, <https://datatracker.ietf.org/doc/html/draft-miao-
              tsv-hpcc-02>.

   [JUPITEREVOL]
              Poutievski, L., Mashayekhi, O., Ong, J., Singh, A., Tariq,
              M., Wang, R., Zhang, J., Beauregard, V., Conner, P.,
              Gribble, S., Kapoor, R., Kratzer, S., Li, N., Liu, H.,
              Nagaraj, K., Ornstein, J., Sawhney, S., Urata, R.,
              Vicisano, L., Yasumura, K., Zhang, S., Zhou, J., and A.
              Vahdat, "Jupiter evolving: transforming google's
              datacenter network via optical circuit switches and
              software-defined networking", Proceedings of the ACM
              SIGCOMM 2022 Conference, DOI 10.1145/3544216.3544265,
              August 2022, <https://doi.org/10.1145/3544216.3544265>.

   [P4-INT]   "In-band Network Telemetry (INT) Dataplane Specification",
              n.d., <https://p4.org/p4-spec/docs/INT_v2_1.pdf>.

   [PINGMESH] Guo, C., Yuan, L., Xiang, D., Dang, Y., Huang, R., Maltz,
              D., Liu, Z., Wang, V., Pang, B., Chen, H., Lin, Z., and V.
              Kurien, "Pingmesh: A Large-Scale System for Data Center
              Network Latency Measurement and Analysis", ACM SIGCOMM
              Computer Communication Review vol. 45, no. 4, pp. 139-152,
              DOI 10.1145/2829988.2787496, August 2015,
              <https://doi.org/10.1145/2829988.2787496>.

   [PLB]      Qureshi, M., Cheng, Y., Yin, Q., Fu, Q., Kumar, G.,
              Moshref, M., Yan, J., Jacobson, V., Wetherall, D., and A.
              Kabbani, "PLB: congestion signals are simple and effective
              for network load balancing", Proceedings of the ACM
              SIGCOMM 2022 Conference, DOI 10.1145/3544216.3544226,
              August 2022, <https://doi.org/10.1145/3544216.3544226>.






Ravi, et al.              Expires 5 August 2024                [Page 40]

Internet-Draft                    CSIG                     February 2024


   [PONYEXPRESS]
              Marty, M., de Kruijf, M., Adriaens, J., Alfeld, C., Bauer,
              S., Contavalli, C., Dalton, M., Dukkipati, N., Evans, W.,
              Gribble, S., Kidd, N., Kononov, R., Kumar, G., Mauer, C.,
              Musick, E., Olson, L., Rubow, E., Ryan, M., Springborn,
              K., Turner, P., Valancius, V., Wang, X., and A. Vahdat,
              "Snap: a microkernel approach to host networking",
              Proceedings of the 27th ACM Symposium on Operating
              Systems Principles, DOI 10.1145/3341301.3359657, October
              2019, <https://doi.org/10.1145/3341301.3359657>.

   [POSEIDON] Wang, W., Moshref, M., Li, Y., Kumar, G., Ng, E.,
              Cardwell, N., and N. Dukkipati, "Poseidon: Efficient,
              Robust, and Practical Datacenter CC via Deployable INT",
              2023,
              <https://www.usenix.org/conference/nsdi23/presentation/
              wang-weitao>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, DOI 10.17487/RFC3168, September 2001,
              <https://www.rfc-editor.org/rfc/rfc3168>.

   [RFC8257]  Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
              and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
              Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
              October 2017, <https://www.rfc-editor.org/rfc/rfc8257>.

   [RFC8684]  Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
              Paasch, "TCP Extensions for Multipath Operation with
              Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March
              2020, <https://www.rfc-editor.org/rfc/rfc8684>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [RFC9378]  Brockners, F., Ed., Bhandari, S., Ed., Bernier, D., and T.
              Mizrahi, Ed., "In Situ Operations, Administration, and
              Maintenance (IOAM) Deployment", RFC 9378,
              DOI 10.17487/RFC9378, April 2023,
              <https://www.rfc-editor.org/rfc/rfc9378>.



Ravi, et al.              Expires 5 August 2024                [Page 41]

Internet-Draft                    CSIG                     February 2024


   [SWIFT]    Kumar, G., Dukkipati, N., Jang, K., Wassel, H., Wu, X.,
              Montazeri, B., Wang, Y., Springborn, K., Alfeld, C., Ryan,
              M., Wetherall, D., and A. Vahdat, "Swift: Delay is Simple
              and Effective for Congestion Control in the Datacenter",
              Proceedings of the Annual conference of the ACM Special
              Interest Group on Data Communication on the applications,
              technologies, architectures, and protocols for
              computer communication, DOI 10.1145/3387514.3406591, July
              2020, <https://doi.org/10.1145/3387514.3406591>.

   [TCP-INT]  Jereczek, G., Jepsen, T., Wass, S., Pujari, B., Zhen, J.,
              and J. Lee, "TCP-INT: lightweight network telemetry with
              TCP transport", Proceedings of the SIGCOMM '22 Poster and
              Demo Sessions, DOI 10.1145/3546037.3546064, August 2022,
              <https://doi.org/10.1145/3546037.3546064>.

Appendix A.  Example encodings of CSIG signals

   The following table demonstrates an example encoding of a 3-bit
   signal value.  Note that this is an example ONLY.  The encoding that
   is meaningful to a certain deployment is specific to the use cases in
   consideration.

   Note that CSIG tag supports 5 bit (20 bit) signal value size for the
   compact (expanded) formats.

              +=======+============+===========+============+
              | Value | min(ABW/C) | min(ABW)  | max(PD)    |
              +=======+============+===========+============+
              | 0x0   | 0%-1%      | 0-1Gbps   | 0-10us     |
              +-------+------------+-----------+------------+
              | 0x1   | 1%-5%      | 1-5Gbps   | 10-50us    |
              +-------+------------+-----------+------------+
              | 0x2   | 5%-10%     | 5-10Gbps  | 50-100us   |
              +-------+------------+-----------+------------+
              | 0x3   | 10%-20%    | 10-20Gbps | 100-200us  |
              +-------+------------+-----------+------------+
              | 0x4   | 20%-50%    | 20-50Gbps | 200-400us  |
              +-------+------------+-----------+------------+
              | 0x5   | 50%-75%    | 50-75Gbps | 400-800us  |
              +-------+------------+-----------+------------+
              | 0x6   | 75%-90%    | 75-90Gbps | 800-2000us |
              +-------+------------+-----------+------------+
              | 0x7   | 90%-100%   | >90 Gbps  | >2000us    |
              +-------+------------+-----------+------------+

                                  Table 2




Ravi, et al.              Expires 5 August 2024                [Page 42]

Internet-Draft                    CSIG                     February 2024


Contributors

   Weida Huang
   Google LLC


   Tyler Griggs
   UC Berkeley


   Mohammad Jafar Akhbarizadeh
   Google LLC


   Jeongkeun Lee
   Google LLC


   Surendra Anubolu
   Broadcom Inc.


   Kok-Kiong Yap
   Google LLC


   Neal Cardwell
   Google LLC


Authors' Addresses

   Abhiram Ravi
   Google LLC
   Email: abhiramr@google.com


   Nandita Dukkipati
   Google LLC
   Email: nanditad@google.com


   Naoshad Mehta
   Google LLC
   Email: naoshad@google.com






Ravi, et al.              Expires 5 August 2024                [Page 43]

Internet-Draft                    CSIG                     February 2024


   Jai Kumar
   Broadcom Inc.
   Email: jai.kumar@broadcom.com
















































Ravi, et al.              Expires 5 August 2024                [Page 44]