dcn 隔离长短流的交换机 aqm

经理们试图通过折腾端到端算法搞定 incast，没diao用。

各类端到端 cc 成立的前提是不止一个 rtt 的长流，只有它们才有足够的反馈作为 cc 输入，一个 pingpong 的 rpc 流你跟我说 aimd，扯淡。

现实是，突发的短流，大量这种突发，不但干扰长流，也干扰自己。短突发到达，塞入长流队列，长流咯噔一下，一个 rtt 后欲做出反应时，短流已去。如果大量短突发同时同出，视为 incast，很难从端上管理它们。

当 buffer 周期小于反馈周期，端到端算法严重滞后性意味着任何奇技淫巧都是扯淡。端到端办不到的事就别办了。

还是尽可能让所有报文在交换机中保持有序才高尚。要想办法将短流和长流隔离，才好让调度器做调度。这种辅助对无论是端到端 cc 还是短流一锤子梭哈，都别提有多重要了。

由于短流转瞬即逝，如果将其排入一个 queue，它很快会离开该 queue，而长流所在的 queue，由于其端到端算法大多犯贱，其 qlen 不会太短，这种启发式判断是合理的。

因此倾向于将任意流头排入 qlen 最小的 queue，后续报文自然也排入流头的那个 queue(此时不一定最小)，如果是长流，该 queue 的 qlen 不会短，如果是短流，比如 10 个报文，它很快离开后 qlen 不会太长，一切交给自然。

但不可能为每一个可能的 5-tuple 创建一个 queue，于是加个中间层，用概率替代，足够好就 ok。创建大小合适(比如 8192)的 flow table，将每个报文 hash 到这个 flow table，再为该 flow table 的 bucket 指定 queue，这是个全相联结构，上述长流短流的论述来源于该结构完全由时间局部性和空间局部性构建的真理。

以下是伪代码：

Enqueue(pkt): 
  key = hash(pkt)
  If flow[key].queue != null
    flow[key].queue.enqueue (pkt)
  Else
    flow[key].queue = smallestq
    flow[key].queue.enqueue (pkt)
  flow[key].size += 1

Deueue(pkt):
  key = hash(pkt)
  flow[key].size -= 1
  flow[key].queue.dequeue (pkt)
  If flow[key].queue.qlen < smallestq.qlen
    smallestq = flow[key].queue
  If flow[key].size == 0
    flow[key].queue = null

enqueue 和 dequeue 都可嵌套，类似 linux qdisc 结构，不再赘述。调度也是分层的，比方说一个 queue 内部可继续调度子 queue。至少来个 round-robin 也能让长流抖得不那么厉害，也能让短流尽快有序通过。

排队和调度是两码事，排好队可以让调度器更好调度。不光 dcn，广域网路由器交换机也能用这种。

浙江温州皮鞋湿，下雨进水不会胖。