“浅谈高端通信系统中一些分布式理论基础（4）”有43个回复

1. shisco 于 2011-10-02 2:17 上午

   辛苦了。

2. 水煮鱼 于 2011-10-02 6:43 上午

   一口气读完了，但是发现没有发现我觉得有些价值的内容，哎！

3. 陈怀临 于 2011-10-02 6:49 上午

   这些文章基本上不是为你们写的。是一些基本的概念。更是为刚出学校的工程师写的。另外，queue 算法和分布式调度会慢慢展开。到时不要觉得太符号化就好。。。

4. 潜水员 于 2011-10-02 5:17 下午

   能否具体化一些，感觉太抽象了。：）

5. asr1k 于 2011-10-02 5:23 下午

   莫非首席又要扯SLIP一类的算法, 然后比较了? 嘿嘿….

6. 陈怀临 于 2011-10-02 5:26 下午

   尽量不。否则写的是网络文章。这个系列希望拽分布式的东西，这样才有点新意。。。：－）

7. asr1k 于 2011-10-03 7:11 下午

   调度的东西总归得写点, buffer speed up的设计和相关的balance, 挺关键的. 特别是某些场合unicast和multicast的通盘考虑, 在什么地方fanout, 首席倒也可以多介绍一点经验撒…

8. 陈怀临 于 2011-10-03 8:21 下午

   你还挺精的。。。还楞猜出来我会写组播。。。
   是的，queue scheduling不写是不行的。绕不过去。。。

9. asr1k 于 2011-10-03 8:41 下午

   嘿嘿… 我一直很精的嘿嘿…

10. kernelchina 于 2011-10-03 9:23 下午

    多播的成熟应用是什么？

11. igp2bgp 于 2011-10-03 10:35 下午

    围观，都是MX and 9k的区别在mcast，一直想知道专家如何说 …

12. 理客 于 2011-10-04 3:17 上午

    to kernelchina：是IPTV中的MTV，在调度上，首先要保证能独立调度，在实际engineering中，是否和其他业务上做一定的sharing，最好不要做，因为组播缺乏重传和加速机制，即使后来增加了这样的辅助机制，具体实现也是很复杂的，对一旦发生的视频质量问题troubleshooting非常困难，所以才有运营商直接用一个独立的管子比如一个波长单独跑组播到终端，如verizon，次一点的是用单独用backhaul的一个链路，如telefonica spain，也有不少完全共享物理链路的，但视频质量一般，或者不太理想。提供成熟稳定的共享链路型的组播业务，是应该努力的

13. asr1k 于 2011-10-04 3:55 上午

    To Kernel China

    主要的问题在于如果分布式系统如果仅考虑单播, 则在某些条件下, 如果有少量的组播流都会导致HOL Blocking. 即便是业务不成熟, 或者其它, 也需要在系统设计的时候考虑到这个问题. 通常就牵扯到调度算法, Buffer size, 还有Speedup的问题了.

    一个典型的例子或问题: 为什么CRS的S3会有两套, 并且S2和S3之间建立了双归属链路.

    另外我一直觉得avici的TSR上用的3-D-Torus 是一个很好玩的东西. 可惜啊, 大家都跟着C和J上了BENES/CLOS的贼船咯….

    嘿嘿, 俺就搬个板凳等首席讲课咯…

14. momo 于 2011-10-05 9:06 下午

    对于控制队列与数据队列的总结实在是精辟啊，看了就有一种突然眼前一亮的感觉。

15. 陈怀临 于 2011-10-05 9:21 下午

    TNND，总算来了一个优秀的工程师。。。：-）

16. flyfish30 于 2011-10-06 6:34 下午

    我本来对这篇文章不感兴趣的，在往上滚动网页时看到文章末尾对控制队列和数据队列的总结，眼前一亮，于是点进来看评论。

17. Ezchip微码开发 于 2011-10-09 8:03 上午

    to 理客
    请教个问题，为什么要用一个独立的管道跑组播呢？比如上下游设备都是10G的接口，那么上游设备的出端口物理上就只能发出10G的流量，不会超过链路的最大带宽啊。在转发设备内部还是要靠QoS保证组播的优先级啊。

18. 理客 于 2011-10-09 1:10 下午

    你的问题看似简单，其实不好回答，因为这不是组播要不要QOS的问题，而是IP网络要不要QOS的问题？因为QOS只有在拥塞时才有意义，如果不拥塞，QOS有啥用？这是涉及IP QOS本质的问题。
    简单回答就是IP网络有拥塞。为什么有拥塞？目前可以说IP应用基本还是C/S模式，如果极端到直接在服务器上运行应用，还需要QOS吗？如果C/S间没有一个IP网络，是直接连接，还要QOS吗？可能在SERVER上要一定的QOS，当然现实的internet是一定要一个IP承载网络的，在Wintel下，PC的能力是足够的，比如现在可以处理几百兆业务是问题不大的，如果满足所有PC的能力，server够吗？IP承载网络够吗？在资本主义和社会主义社会，显现是不够的，除非到共产主义社会，并且是在共产主义个人道德自发约束下。所以建设一个在C/S间没有带宽拥塞的网络在目前的社会是不现实的。
    那么拥塞在哪里？一般在最后一公里和业务网关，比如ADSL/DSLAM和BRAS。
    有拥塞之后，为什么要给组播单独的QOS保证？因为组播协议没有报文重传机制，这个是组播协议设计之初没有仔细考虑的问题，丢包和时延对视频的实时性影响很大，而人的眼睛对视频体验的要求又比较敏感，并且组播视频丢包的监控和恢复都非常麻烦，所以尽量隔离组播流量和其他业务流量，无论内部还是外部，是一个很好的方案

19. mpc8240 于 2011-10-09 1:26 下午

    给组播一个独立的Queue，原因是不要让组播影响单播业务。组播Queue往往是最低优先级的。强调不能丢包的业务，不会推荐用组播的吧。
    对于组播，不是出口有10G，入口就可以灌10G流量的。两个原因，组播replication操作本身往往不是线速的，并且涉及1对多的replication。

    理客老大倒底人在何方？怎么好象无时无刻不在线上？

20. 理客 于 2011-10-09 3:42 下午

    组播内部调度因为这种1：N的复制，变得有较多麻烦，因为组播业务近几年才因为IPTV而多起来，所以成熟度和协议优化的进展也比单播差很多。
    不敢称老大，我常出差，现在欧洲

21. kernelchina 于 2011-10-09 6:42 下午

    组播的replication, order, reliable等是比较头疼的问题，在ingress复制，还是egress复制，是个艰难的决定。

22. lucky 于 2011-10-09 7:11 下午

    看来半天 一头雾水。。。。。。

23. Lucien 于 2011-10-11 1:10 上午

    multicast应该既有ingress，又有egress的。ingress为每个linecard复制一份，egress为每个port复制一份

24. 陈怀临 于 2011-10-11 6:16 下午

    ASR9000 在multicast上做了不少东东。。。

25. Ezchip微码开发 于 2011-10-12 6:56 上午

    想问下这里的大牛一个问题，用芯片实现组播报文复制，要获取同样的组播出口流量（假设10G），有两种方法
    1少量的组播流量复制多份（10M*1000），
    2大一点流量复制份数少一点（2500M*4）
    上门两种方法对芯片而言哪种容易实现啊，呵呵。

26. 阿土仔 于 2011-10-12 7:57 上午

    如果仅是简单的复制，都不复杂。一般来说，还是2更容易。

27. 根本不相干 于 2011-10-12 6:10 下午

    组播不过是网络工程师自己的YY罢了，从应用开发角度看，这玩意巨难用无比。

    理论上组播有好处：1）节约骨干网带宽；2）把服务器从重负荷中解脱出来。可在实际工程环境中，有比组播更容易实施的办法去避开这两个问题。回头有时间专门开个帖子阐述一下，从全系统端到端的角度，而不是从单点网络设备的角度。目前组播不过是设备商忽悠客户竞争的一种手段而已。

28. song6015 于 2011-10-13 8:06 下午

    还有待续吗？

29. 理客 于 2011-10-15 8:13 上午

    根本不相干说得有一定道理，体会很深，愿闻高见，简单几句要领即可

30. asr1k 于 2011-10-15 10:03 上午

    to 25楼, 要看具体的复制方式, 例如是采用NP或者通用处理器架构, 则可能需要涉及大量的memory copy操作, 可能10M*1000反而更快. 而如果是一些FPGA/ASIC的东西, 可能反而做基于crossbar的fanout会在复制份数少的时候省事一点,

31. 根本不相干 于 2011-10-15 10:04 下午

    to 29: 标准的捧杀啊！这个问题讨论开话长了，就简单聊两句，次序乱将就着看。要是字面意思没表达清楚引起误解争议请恕暂时没时间回了。

    1) 应用开发：网络不再对开发人员透明；应用增加功能需要网络配合(如鉴权)；与OS标准的流管道IO模式不匹配；历史上看需要网络支持的应用没成功案例(RSVP,P4P…)

    2) 带宽问题：把网络复制变为端节点复制，根据接入网特征可分为cache模式(不对称运营网如宽带接入)和P2P模式(对称专网如LAN/Campus)

    3）端节点复制效率问题：零拷贝(throughput)，EPoll(并发连接)，近年来Linux内核发挥PC硬件能力对10K问题的IO效率的改善进步巨大

32. 根本不相干 于 2011-10-15 10:14 下午

    补充一下，纯理论而言，端接点复制效率永不可能达到网络复制的水准，只能不断逼近。但只要超过一定的门限，它支撑应用发便利性带来的好处将远远盖过它所引发的效率损失。而这个门限，大约在6、7年前或更早时间差不多就达到了，这年头几乎没出现什么基于组播的新业务。记得以前和人讨论过游戏运营商内部服务器间数据同步，我又去专门确认了一下，肯定的说没有组播，全是服务器自己玩点对多点复制。

33. 理客 于 2011-10-16 11:47 上午

    任何一个事物，无论什么原因，一旦无法广泛应用，就很难存活，不仅技术，文化语言等也是如此，从apple失败的产品和成功的产品中也可看到这点端倪。
    IP网络和应用decouple确实是TCP/IP的一个本质，或者说TCP/IP对每个节点和主机的自智能性/自愈性有自己一套较高的要求。组播应用少到基本是MTV，确实值得研究，组播业务和网络couple过紧应该是一个重要原因。
    组播协议一直没有进一步优化到通过自我协议解决对网络QOS的严重依赖，严重阻碍了组播的发展，从成本的角度看，任何一项技术，如果和前任或者其他技术比不能有效的降低成本，基本上前途很难，组播简单看理论上是个好技术，但是因为其对QOS依赖性命中了IP在QOS上的某些不足，导致极端情况下，有运营商基于WDM/PON用一个波长跑MTV，但是这种案例，全球又有几个运营商能做到呢？表面上看，比如组播TV，似乎对QOS要求不是十分苛刻，但实际上，除了目前还没有实际商用的基于IP的时间同步，组播是对QOS要求最高的，语音看起来很高，但因为语音的带宽太小了，所以就很好解决，并且，VOIP在即时通讯大潮的带动下，已经靠自己解决了QOS的问题，并不严重依赖网络，比如skype，而组播视频，因为对带宽大小和质量同时要求高，所以提供和传统电视体验相近的业务，很难，目前看到的商业MTV，绝大部分都距离传统电视还有一定的距离。
    没有定量研究过丢包率对MTV的实际影响，简单看人眼接受的正常视频是24帧/秒，是不是1/48的丢包率就可以了？但实际上，因为目前视频压缩算法都是基于增量的算法，所以还要看丢帧的类型，如果是P帧，也许不是问题，但如果是I帧，可能就问题很大了，也许丢包不是MTV的普遍问题，但问题是一旦出了，定位很麻烦，因为单播业务有重传可以解决，所以并对丢包要求并不是很高。另外就是频道切换时间问题，也是非常影响QOE的很头疼的问题

34. 理客 于 2011-10-16 12:20 下午

    同样是理论上和技术上看，基于端节点复制的P2P应该是最优视频解决方案，但实际上却不是那么简单。
    合法P2P不是问题，技术也不是问题，比如可以在城域网增加视频源，解决频道切换和用户少时的问题等等，运营商级P2P TV最难解决的是钱的问题，是运营商的利益保证问题，因为P2P利用了用户的资源，吃人家嘴短，用人家手短，怎么好意思向用户多收费？而收不到钱的事，又有哪个资本家会傻到用这个做慈善呢？简单看P2P TV如何赚钱：
    1、卖带宽，要看有质量保证的TV，那么用户就一定要增加接入带宽，这块利润，无论谁做IPTV，钱都是运营商赚的，但是运营商如果自己做，可以至少把带宽的成本早点赚回来，并且把视频用户从cable那里吸过来，现在的internet，用户真的是ISP/ICP的衣食父母。
    2、wholesale：这个和上面类似，卖用户线，还可以提供更多的增值服务，比如视频服务器/系统托管等
    3、自己的IPTV业务，如果用P2P，这个钱就不好直接赚了，一种是提供免费的P2P TV，但要植入广告，还有就是收费的没有广告的P2P TV，按照目前互联网的模式，可能前者更有前途些，但是如何有效的植入广告，这个并不那么容易。
    具体到技术未必太复杂，比如终端可以分运行在PC/laptop/pad/phone等上面的软终端和运行在STB的硬终端，在上行QOS上要做一些工作，解决和和其他业务的冲突问题。这种模式下，比较开放，可开发的应用会比较多，这也是IP应用生存的根本，所以，可能会远比组播TV有前途
    IP/IT下的TV终端，目前巨鳄都已经张开了嘴，包括MS/GOOGLE/APPLE等，国内也有盛大等尝试，但至少到目前为止，IPTV是组播到底了，还是可以有真正适合的模式统一天下，不好说，也确实是不是一两句话能说清楚的，不知道业界对运营商级的P2P TV有何研究？或者叫CP4P TV,感觉应该是一个可以做一下的大点的题目，期待根本不相干的大作

35. 根本不相干 于 2011-10-16 6:18 下午

    to 理克

    你已经把我很多想说的说了，多谢！我码字实在太慢，不过你提出了一个重要的问题，我就多唠叨几句。

    1) 从运营的角度，Cache(或者某些同志非要冠以xDN之类的噱头)比P2P实用，更容易掌控用户体验。看国外Internet Video，几乎没有P2P的。成本上看以前P2P确实有极大优势，但现在server的每流成本急剧下降，也到可接受程度了。(中国是特例，垄断造成带宽成本高得吓死人)

    2) P2P的价值主要在管理域内，比如服务器之间或者专网内节点之间的复制，这时候不存在谁占谁便宜，不存在商业问题，只是个技术工具。不看好运营环境下的P2P，确实会碰到商业问题。

36. 理客 于 2011-10-17 12:24 上午

    IPTV因为频道数量和HD，至少目前看是一定要一种能节省带宽的技术，否则目前的IP网络是难以承载的，总结一下：
    1、当前主流MTV/BTV方案：传统组播+FCC/RET caching and monitor/troubileshooting，主要问题在cache如果只在中心，可能时延抖动保证会有问题，并在FCC时可能冲击网络，而用cache card到ME路由器，在路由器上维护一个cache card，则是十分奇怪的网络
    2、基于P2P的运营商TV，关键是还没有清晰的商业运营模式
    3、基于PON的真正的超宽带网络：用带宽换技术复杂度，历史上X25/FR/ATM都是这样被踢出历史舞台的，但问题是，在许多国家和地区，超宽带的普及时间，很难预测，在没有普及前，怎么办？

37. kernelchina 于 2011-10-17 2:39 上午

    在有线电视网上做视频点播有难度吗？IPTV，对用户来说，有什么好处？

38. 理客 于 2011-10-17 2:46 上午

    需要对小区的cable系统做改造，美国有一半以上的cable IP用户，本来是很好的方案，但中国情况比较复杂，包括ZZ和cable接入网络质量难以改造等问题，和电力上网有点类似，IPTV可以相比传统TV提供更多的增值业务app，但目前还缺少killer级app，所以还有很大的市场空间

39. 根本不相干 于 2011-10-17 3:02 上午

    我也认为路由器的cache板是个怪胎

    不过，cache下方是一个解决带宽问题的思路，但要注意三点：1)是单独外置而不是路由器的XX板子；2)接LSW而不是Router；3)基于通用服务器而不是啥专门的xDN硬件设备。这三点是真正低成本用起来的关键，可惜多数运营商被设备商在忽悠。

    另外补充一点：时延抖动对视频业务(非通信类)是伪命题

40. 理客 于 2011-10-17 4:25 上午

    如果继续传统TV的运营思路，只是把cable换成IP，是换汤不换药，可能没啥出路。如果做一个基于P2P的运营商TV开放平台，把从电视用户收费的收入模式改成WEB2.0的共享和从更有钱的商人那里收取广告费和平台应用开放分成费用，而只从传统用户那里返回系统成本即可，用户也可以自由选择用运营商的终端还是各种其他终端，只要兼容开发平台标准即可。

41. 胡不才 于 2011-10-17 7:19 下午

    组播的一个出路也许在单播上，即在地理上不同地方设置cache服务器，之间用单播点对点相连，然后上面跑多播，甩开恼人的router。

42. 根本不相干 于 2011-10-18 2:32 上午

    看来理客同学还是很有P2P情节的:)

    不过P2P越来越倾向于只保留其技术在广泛应用(如DHT)，而应用尤其是公网运营业务则逐渐退化。一个例子就是互联网视频P2P流量已经大大小于VoD(前面说过但中国是个例外，原因是带宽成本)

43. 理客 于 2011-10-18 2:44 上午

    P2P因为涉及合法源内容问题，各国家和地区法律及其执行上的环境差异很大，导致在流量差异很大。但从技术的角度，是很符合TCP/IP的好东西，总感觉还有前途没有被挖掘出来，没遇到Jobs