Editing Networking/NIC Software (section)

==Topics==

The area is open for innovation, and new topics are encouraged.

The current list of active topics are

===Telemetry===
Define a standard set of network device and queue statistics, with standard names and unambiguous definition of each statistic's meaning.

For Linux based deployments, this builds on and extends the standard '''rtnl_link_stats64''' and replaces much of the free-form current driver interface exposed through '''ethtool -S'''.

===Traffic Engineering===
Standardize state-of-the-art TE mechanisms.

Develop common support for stateless [https://www.kernel.org/doc/html/latest/networking/segmentation-offloads.html#generic-segmentation-offload generic tunneling offload]. Support TCP segmentation offload, an offload that is indispensible for many workloads, in combination with any tunnel protocols, as opposed to building an offload for each tunnel protocol. Hyperscalers may use protocols, protocol stacks and protocol variants --proprietary or not-- that the vendor cannot always anticipate. Generic tunneling is a requirement for deployment at scale.

Develop industry standard support for [https://legacy.netdevconf.info/0x12/session.html?evolving-from-afap-teaching-nics-about-time Earliest Departure Time] (EDT) stateless rate limiting offload.

===Flow Steering===
Device queues are the basis for scalable networking through load balancing (RSS), as well as task isolation and userspace network stacks.

Define
# a common interface for configuring devices queues and RSS groups, including dynamic addition and removal without link downtime.
# a common interface for steering flows to queue (groups), including expectations on datapath performance and scalability of number of steering rules.

Additionally, define
# a common queue interface for userspace network stacks like DPDK and [https://research.google/pubs/pub48630/ Google SNAP].

===Crypto===

TLS, QUIC, IPSec and other cryptographic protocols cover a huge fraction of all traffic.

Hardware support for offload of these and other protocols is uneven.

Define key requirements, such as support for specific cryptographic algorithms like ChaCha2020-Poly1305, specific protocols such as QUIC and resulting requirements, such as framing and stream re-synchronization.

Current protocols under active work are
# QUIC: [https://www.rfc-editor.org/rfc/rfc9000.txt rfc 9000]
# PSP: scalable tunnel and transport mode protocol developed at Google ([https://github.com/google/psp/blob/main/doc/PSP_Arch_Spec.pdf spec on github])

===Time Measurement===
Expand hardware capabilities from PTP to include high-rate, high-precision timestamps on every packet. Both Rx and Tx.

Accurate time measurement is essential to advanced congestion control (e.g., [https://dl.acm.org/doi/pdf/10.1145/3387514.3406591 Swift]), fleetwide latency SLO monitoring and even applications such as globally distributed databases ([https://research.google/pubs/pub39966/ Spanner]), among potentially others.