pHost: Distributed Near-Optimal
关键词：端上拥塞控制 接收端驱动
1.背景
1.1现有技术
pFabric依赖特殊硬件，并且只做了FCT的minimize，不能与其他policy联动
FastPass仲裁器调度会慢
1.2 Data Center Feature
- RTT小：物理距离近
- 直通交换机：开销小，但提供了优先级，ECMP，(packet spraying)
- 全平分带宽：带宽均匀分配
2.目标
提出了一种新的分布式协议，允许终端主机直接做出调度决策，在不依赖于特殊的硬件的基础上，最小化FCT
2.1 优点
不需要专门的网络硬件
不需要在交换机上关注每个流状态或复杂的速率计算
无需中央仲裁器
无需显式的网络反馈
性能接近pFabric
3.设计
总结：基于双端的调度，Request To Send，包token分配，接收方决定接收流
-
RTS:每个发送端主机发送前，向接受端发送请求发送（RTS）包：可能包含与制定调度决策相关的信息（例如流的大小等）
-
token:
- 接收端调度：接收端在一组RTS中选择一个发送端为其分配token，允许发送端从该流发送一个数据包，同时可能会指定发送的包的优先级；在收到token 1.5MTU传输时间后，token失效。
- 发送端调度：另外，发送端可以自主分配少量token。同时，发送端可以将token自主选择分配给流中的包。
-
ACK:接收方完成一个流所有数据包的接收，会向发送端发送一个ACK包
ACK,RTS,Token设置为高优先级
3.1 设计缘由
- DC中的 packet-spraying几乎可以消除中心的拥塞
- 充分利用有限的优先级可以尽可能减少丢包
- incast情况仍然发生，导致接收方拥塞
- 中央仲裁器开销大，所以使用分布式的，类似于PIM的路由器调度程序设计
3.2 额外的机制以提高利用率
- 发送方starvation:
- 发送方并行发送RTS避免饥饿
- 发送方可以分配少量free token避免RTT时间的等待
- 接收方starvation:
- 暂时停止（原文是默认3*RTT）向过期token达到阈值的发送方分配token
4.具体实现
描述终端主机实现的协议（§3.1），然后详细说明该协议如何确保高网络利用率（§3.2）。然后，我们将描述phost如何支持灵活的调度策略（§3.3）。最后，我们描述了如何在丢包的情况下进行可靠的传输（§3.4）
4.1协议本身
规定收发双方交换和使用RTS、令牌和数据包进行通信的协议
当flow到达时，源立即向流的目标端发送RTS（含flow size等）
发送端基于可配置的free tokens，为每条flow初始化了一个ActiveTokenslist，可以让少数包发送，所有后续token只能由接收端在响应RTS时授予，接收方的token将会放入ActiveTokenslist，持有未过期的token的包才能发送。
接收端将所有RTS添加到PendingRTS中，每经过一个（MTU大小的）包传输时间，接收端根据自己的策略发送token给PendingRTS中的一个发送端。同时，发送端记录者每条流的超时token，当超时token过多，那么将会对减少这条流分配的token。
接受完所有的流之后，接收方会给发送方发送一个ACK。
注意：All control packets in pHost are of 40 bytes：对于一个普通的RPC调用，数据大小也不过如此，对short message来说是否开销过大。文章做到对短流优先分配token（但可不可以短流不需要token(这个是否freetoken做到了)）
4.2调度策略
分配哪些发送端和接收方通信的调度策略
4.2.1优化FCT
SRPT:在分配令牌时，接收方为剩余包数最少的流优先分配token，同时，token允许发送端短流设置第二个优先级，长流第三高优先级（RTS ACK第一高优先级）
4.2.2 限时流量
EDF:在分配令牌时，接收方为最接近deadline的流优先分配token，同时，发送端优先将收到的token发送给最接近deadline的流
4.2.3 多租户之间的公平性
pFabric会导致如果网络中存在密集的短流和一个长流的时候，长流会出现Starvation。pHost可以为每个租户提供一个计数器计算每个周期接收包数量，优先给计数最小的租户分配
4.2.4 丢包
token超时到一个阈值后，接收端会重新将这个token发送给发送端，发送端重发这个包
