文章目录

设计背景

pHost这篇文章是加州伯克利分校在的CoNEXT会议上提出的，它也是后来的数据中心网络下接收端驱动的主动拥塞控制的雏形。我之前看的文章包括Expresspass，NDP和Homa都是在这篇文章上提出的后续改进方案。

这篇文章的的设计初衷是为了达到与pFabric相近的性能，同时兼具Fastpass的灵活性。这两篇论文它们分别来自和的sigcomm，这里简单介绍一下。

pFabric在性能上被认为是当时最优的设计，它的核心思想是通过流的大小来对不同的流进行优先级调度和优先级丢包，交换机上优先调度高优先级的数据包，缓冲区满的时候优先丢弃低优先级的包。但是pFabric其实是有问题的，一方面它是默认使用者可以从数据中心中获得每条流大小。但是事实上这种信息其实是很难获取的，因为有一部分流一边计算一边传输的，在传输完成之前数据中心也不知道它总共要传输多少字节。另一方面,商用交换机芯片并未广泛支持优先级丢包机制,一旦一个数据包进入了交换机的缓冲区,它就不会被新到来的包“挤出去”，即使这个包的优先级比它更高。基于这些原因，pFabric想要部署在商业交换机上其实是有难度的，所以被论文中认为它虽然有好的性能但是不够灵活。

而fastpass的核心思想是发送数据前,发送端会向集中控制器发送请求,集中控制器结合请求信息和网络状况作出相应的调度,包括发送数据的时间、速率和路径等。这种集中式调度优点是可以获取网络全局信息,理论上可以达到最优的调度,但是也存在明显缺点,系统实现上需要额外一个 RTT 去获取调度决策而这对于小流的完成时间有非常大负面影响．

所以这篇文章提出的pHost是想要做到兼具灵活性与性能。

作为接收端驱动的雏形，它不需要特别的硬件支撑，没有类似于fastpass的集中式调度，也没有显示网络反馈的环节，但是它可以接近最佳性能。下面来介绍pHost的具体设计：

pHost模型

pHost结构下的三种主要的数据包：

RTS包，request to send，这个数据包中包含了流的信息。每当有新的流到达时，RTS包就会从发送方发送到接收方。第二个包是Token，接收方会在每一个MTU的转发时间将其发送到发送方，提醒发送方发包，它携带的信息的包的偏移与发包的优先级。最后一种就是data packet，携带负载。

论文中认为对于一个拉动式的端到端的调度结构，最重要的就是保证发送端和接收端达到最高的利用率。这里对发送端和接收端进行具体介绍：

在发送端上，每当有新的流到达时，它就会发送一个RTS去接收端，发送端也允许同时接收多个不同的并行token包。发送端会从不同的流上接收到不同的tokens，通过tokens的到达顺序来对不同的流进行发包。

为了保证接收端上的高利用率，如果发送端接收到了Token但是没有立即使用，Token就会过期，然后token隶属的那一条流就会被降级，在三个RTT时间内不在允许被发包。

一对一的情况，这里介绍一个实例：这里有新的流到达，所以发送方发送一个RTS包给接收方，向接收方请求信息。

接收方在接收到RTS以后对流的信息进行记录，在每个MTU的发送周期发送一个Token包给发送发，提醒发送发发包，这样接收方就可以一直保持接近线速来接收包。这里是一对一的情况所以也不会出现token过期的情况。当整个流传输完毕时，接收方向发送方发送一个ACK。

总结

pHost可以解决发送端入口链路和接收端出口链路的拥塞问题，但是对于其它交换机仍然有可能出现拥塞，这个时候pHost就会失去作用。

NDP中提到了这样一种情况，拥塞发生在stage3 的sub-switch1的入口队列，pHost是没办法解决这个问题的。像NDP为了解决这个问题就引入了CP修建负载的机制。

如果觉得《CoNEXT pHost 论文读书笔记》对你有帮助，请点赞、收藏，并留下你的观点哦！