HPCC是阿里推出的针对高速RDMA网络的新的拥塞控制协议，借助于INT提供的详细信息来进行精确的速率控制，具有快速收敛，保持接近zero-queue的优点。
Motivation
论文认为，如今高速网络中传输普遍存在三个问题：
- 收敛慢
- 始终有standing queue，增加latency
- CC的参数调优困难，operators总是需要在stability与utilization，latency与throughput之间做trade-off
导致这三个问题的根本的原因是现在的拥塞控制算法只有粗粒度的反馈， 而INT带来了新的机遇
Design
HPCC的核心思想是借助于INT提供的细粒度信息，如timestamp (ts), queue length (qLen), transmitted bytes (txBytes), the link bandwidth capacity (B) 等，去精确计算流速率。HPCC的两个核心设计点: 基于inflight bytes的发送端速率控制、RTT-based与ACK-based反馈结合避免overreaction.
CC based on inflight bytes
（1） 为什么用inflight控制不用rate控制：
$inflight = rate \times T$ $\quad T$是baseRTT
$inflight$可以对应链路利用率。当拥塞未发生时，控制 $inflight$ 与控制rate等价，但是当拥塞发生时，improves the tolerance to delayed feedback during congestion. 在反馈返回前发送方仍然以原速率发送，可能会导致拥塞加剧，网络不稳定。HPCC相当于又回到了TCP这种window-based的速率调整方式。
For a link, the inflight bytes is the total inflight bytes of all flows traversing it.
（2） inflight for a link: $I = \sum{W_{i}}$ $\quad W_{i}$是第$i$条流的窗口，相当于速率为 $R_{i} = \frac{W_{i}}{T}$
如果 $I < B \times T$，则 $\sum{\frac{W_{i}}{T}} < B$，$\frac{W_{i}}{T}$ 是流 $i$ 的吞吐，说明未发生拥塞，链路没有充分利用；
如果 $I > B \times T$，则 $\sum{\frac{W_{i}}{T}} > B$，说明该链路发生了拥塞，该链路是流 $i$ 的瓶颈链路（之一）；
HPCC调速的目标就是使得每个link的 $I$ 略小于 $B \times T$。
（3） 利用INT计算 $I$。每个发送方独立地估计第 $j$ 段链路上的 $I_{j}$。假设：所有流具有相同的base RTT $T$。
$I_{j} = qlen + txRate \times T$
$txRate = \frac{ack_{1}.txBytes - ack_{0}.txBytes}{ack_{1}.ts - ack_{0}.ts}$
$I_{j}$ 就是对链路 $j$ 的 $inflight$ 的估计。这里体现出INT的必要性：需要获取 $txRate$ 这个关键参数
（4）调速策略
乘性减窗口：factor: $k_{j} = \frac{I_{j}}{ \eta \times B_{j} \times T}$
$W_{i} = \frac{W_{i}}{max_{j}(k_{j})} + W_{AI}$
增速：先加性增 $maxStage$ 次， 每次加 $W_{AI}$；然后根据上式乘性增
Fast reaction without overreaction
Thoughts
PCN和HPCC大致发表于同一时间，两篇论文风格不同，读过PCN再重新审视HPCC，个人觉得HPCC有的地方道理没有讲的非常透彻 。当然，HPCC的出发点不同，阿里应该是想运用INT这个技术改善拥塞控制。PCN中指出的三大基本问题：PFC干扰拥塞识别、拥塞流减速太慢、增速算法慢而不灵活，实际上HPCC借助于INT提供的更精确的信息也在解决这三个问题。 通过控制 $inflight$ 接近 $B\times T$，HPCC也能接近PCN在一个RTT内减到合适速率的效果（特别是Incast场景下）。HPCC增速算法采用的先线性增再乘性增，其实与PCN中先缓慢再激进的增速策略不谋而合。
无论是PCN还是HPCC，二者因为需要获取更多信息来进行拥塞控制（PCN需要交换机根据PAUSE信息标记数据包，接收端采集接收速率，HPCC直接需要全网部署INT技术收集$txBytes$、$timestamp$等），都需要对fabric进行较大改动。
这里放两张论文中的结果图，可以看到其实DCTCP，这种根据队长利用multi-bit信息去做速率调整的协议本身在无损网络中性能并不很差（不考虑kernel bypass），甚至超过DCQCN和Timely很多（小流），论文认为是由于DCTCP的窗口相当于一定程度上限制了inflight bytes。笔者认为，一方面，HPCC相当于把队列长度阈值设成了零，其他拥塞控制协议队列阈值均大于零，其中DCTCP的阈值比DCQCN小得多，对小流来说显然队列长度十分影响latency；另一方面DCQCN与DCTCP相比，DCTCP是根据拥塞程度进行细粒度调整，而DCQCN是根据一个周期内有无拥塞进行调整，这方面也可能造成性能差距。 DCQCN等加了inflight bytes 的限制后性能能够得到很大提升，可见基于 inflight bytes 的速率控制具有很大优势。
HPCC的 trade-off 也可以在图中看出。Load 50% 时，HPCC, the residual capacity is $(95\% − load \times (1 + INT overhead))$ which is 36.1%. So at 50% load the long flows are 1.24 times slower with HPCC than with other schemes. INT 的 overhead 对长流影响较大，the long flow slowdown is inversely proportional to the residual capacity of the network.
