作者：manjusri

      （2） 事后丸：IP QOS，有两种事后丸，第一种是带有一定的预防效果的，既然要做一点事前预防工作，所以就要做在进去的时候，而不是出去的时候，这里还有两粒，一粒是RED/WRED，也就是根据设定的阈值，在还没有发生congestion的时候就开始丢弃，为了处理TCP的慢同步带来的同呼吸问题，所以要random，而为了区分业务的质量重要性，要给予不同的weight；另外一粒就是CAR，有什么单桶三色和双桶三色，具体算法区别记了又忘。CAR也可以和业务优先级结合，具体就是在CAR后的remarking上做文章，通过重新对CIR和PIR着色，使其在出去的时候得到不同的待遇。实际应用中，CAR是流行和直接的方式，RED/WRED偶尔辅助一下，用得不多，没仔细去对比为什么，仔细比一下应该有原因的。第二种就是出口队列技术，其实队列本身也可以用在前面，比如AL7750的CAR其实就是用队列处理的，用队列其实比不用队列好，队列因为报文缓存而具有shaping能力，CAR只是保存一些token，没有实际报文存贮，所以不能shaping，也就是没有token的时候没缓存直接丢弃，有token的时候想补救也没有对象了，子欲养而亲不在，称父母在的时候多孝敬父母吧。所以在上面的方法中，华为使用入口H-QOS的方式实现更精确的功能，可能其他不少vendor也是类似这么做的，这里还是主要讨论outbound方向，实际上，在这个方向上用得队列最多。都是用在congestion发生的时候，congestion可以精细化到对时延的抢占上，也就是即使没有报文丢失，也有congestion发生的可能，比如调度的先后会影响到时延，所以对时延敏感的重要业务可以有限调度，比如分配一个PQ，这里要加上重要二字，因为即使你对啥都敏感，但你对别人不重要，也没人理你，你自己过敏去吧。技术上主要是PQ/WFQ，同时支持带宽抢占，就是其他队列没人排队的时候，你也用他们的带宽，蹲位紧张的时候，别浪费了。当然对于UNI接口，运营商可以设置限制不让用户超出合同带宽，也是很合法的。不是有带宽就免费给你用，放那放着，你多多掏银子的时候才能给你，运营商是商人，不是开源社区，这里分为UNI和NNI，海量队列主要就应用在UNI上，当然某些vendor比如华为比较强，在NNI也做了被其称为VPN-QOS的技术，把用户队列带到NNI出口。IP QOS中最有趣的MPLS TE部分放在了上面，这里不是详细介绍MPLS TE技术的地方，就不展开了。

        IP QOS大体可能就这么多。对于IP QOS的实际使用，大体有两类观点：
      （1）不需要QOS，因为带宽足够大，网络中的带宽利用率其实很低，还没等congestion，运营商已经扩容了，没有congestion的真正发生，所以QOS根本就没有真正发生作用。这是实际运营经验的一种体现，在许多情况下似乎很正确，但实际情况下是有一定问题：
       1）一个是不丢包不代表时延OK，所以在带宽没有满，但是已经开始有拥挤的情况下，对时延敏感的重要业务需要给予一定的有限调度权利，那么就需要PQ的QOS机制。
       2）如果带宽一直得不到充分利用，那么成本的降低有问题的，或者反应了竞争不够充分，比如中国的电信市场，在欧洲电信法后，出现很多的tier2/3运营商，为了成本和效率，不可能带宽很充分，所以需要QOS来保证非internet业务。再就是有时对热点链路估计不足，导致这些链路发生拥塞。
       3）基于用户的业务需要，一个是你要保证你承诺的带宽，另外就是你不想把没有承诺的带宽给客户免费午餐，当然更恶劣的还有甚者故意劣化没有承诺的流量，达到让你购买承诺的不可靠人的目的，这里是玩笑了，但是在P2P泛滥而运营商看着带宽白白流水而不能变成白银流到自己口袋的时候，是真想让P2P流量恶劣得使用户讨厌用P2P了才好，实际上我们的P2P还一直用得还可以，运营商虽然恨在心里，可以也不敢下手太狠，毕竟，我们客户是他们的衣食父母，太狠了，道德上不好，我们做父母得也不会允许孩子们太过分纵容。
      （2）另外一种就是从精细化运营角度，来做非常精确精细的QOS控制，包括一套集中控制的策略服务器，路由器山充分的队列，用户可以通过portal定制的menu等等，看起来很美，但实际中被使用得有限，准备了精美的餐具和食品，可惜以草根为主的用户不感冒，所以投入产出不是很好，这种精细化QOS的思路也就在不冷不热中偶有被人们提起。

       此外还有一些公平理论，就是运营商不应该做QOS，QOS对用户不够民主自由和公平，在internet来看似乎如此，但如果考虑到internet和电信业务融合在一个网络，就不太一样了，具体在上面有描述，所以这种基于社会理论的想法，学术上很好，但实际上遵循的人不多。

       大多数实际部署上，很多就是用每端口的8个队列，对于UNI端口，一般不会超过4个，UNI的端口可能有逻辑接口的考虑，多扩展到N个逻辑接口，这也是AL7750的H-QOS的主要永无之地。只有其中的hierarchy有什么用，大多数情况下没有用，尤其是号称的5级，实际上号称的5级，真正生效的也未必有这么多级。在实际中，H发生有两种情况。
       （1）需要做基于用户的QOS调度，那么此时一个用户内部再有不同的业务，比如数据/语音/视频，以及用户还可能非为金银铜，那么就需要2、4甚至4级了，更多的是两级。
       （2）需要做基于VPN的QOS调度，具体情况和上面类似。
       实际上在H-QOS不多的应用中，主要是2级的应用，偶尔有3级的可能，在应用中，因为业务的灵活性，实际上的映射和调度模型优势更灵活，这里AL7750的H-QOS在灵活性上的设计是比较好的，当然华为后来做得也不错，其他的C/J就要逊色很多了。
       QOS用软件实现性能基本没法保证，后来强大的QOS，都是借助硬件实现，并且嵌入在转发引擎的QOS协处理能力是有限的，要更高更强的QOS，都是用独立的ASIC做TM，同时该ASIC也可以顺便兼做一些计数器等兼职功能。HQOS的实现网友HJ说了，一般队列就在和接口或者用户关联，后面的几级都是调度组合，并不再分配单独的队列。