Subject: [iccrg] Followup on draft-pan-tsvwg-hpccplus

From: "Rui, Miao" <[email-masked]>
Date: Wed, 10 Mar 2021 15:57:48 +0800

Hi,

It was our great pleasure to present HPCC++ today. Thanks for all the comments and feedback! 
Question: our draft (https://datatracker.ietf.org/doc/draft-pan-tsvwg-hpccplus/)  is expiring soon on March 15, and thus do we need to refresh it under ICCRG? 

Here we would like to list a brief summary for today's discussion:
Is this protocol intended to be used on the Internet at large or just inside a datacenter?
Technical-wide HPCC++ can work for both the Internet and datacenter as long as routers support INT/IOAM for congestion control purposes. But, there might raise privacy concerns for different ASes to share their telemetry data.

How is it related to IOAM, L4S, and XCP?
IOAM: Thanks José and Spencer for the clarification in the meeting. IOAM is a general protocol to report various telemetry information from the switch, while HPCC++ defines which info is useful for congestion control and it is orthogonal. 
L4S: L4S provides efficient and fine-grained network load info, while HPCC++ embraces both queue and tx-rate. For example, HPCC++ can maintain tx-rate to 95% utilization to achieve a zero queuing delay.
XCP: XCP requests read &write operations from/to switches, while HPCC++ only needs to read IOAM info from switches and it has already been supported. From algorithm apects, HPCC++ uses TX rate while XCP uses RX rate. Generally, we view the TX rate is more stable because RX rate and queue_length are overlapped and thus it causes oscillation.

Difference between the HPCC(presented at SIGCOMM) and HPCC++?
HPCC++ is more production-ready from our deployment experience with the network operators and device vendors. HPCC++ adds a receiver-side algorithm to reduce PPS overhead and switch-side optimization for fast notification. Also, it has a reference NIC implementation framework and a few other enhancements and guidelines.

In addition, Bob shared a nice point that HPCC++ is an effective use-case of using in-band telemetry but focusing on the congestion and traffic, while in-band telemetry like IOAM can enable a broader range of applications, like troubleshooting, failover, QoS, etc. We totally agree that it will enable protocol evolution on those aspects.

Thanks again for all the comments and feedback.

Thanks,
Rui