重读RFC1925,网络的12条军规

过了25年,似乎很多人已经忘记了这篇RFC然后开始干一些莫名其妙的事情,特别是云的人不懂网络,而网络的人也似乎过于守旧而不理解云。恰逢刚才看到了某研究机构写的SDWAN白皮书,就再来给大家复习一下吧。


写这篇文,不是为了嘲讽什么,只是在国内自主创新呼声很高的时候,希望能说一些事情,在做自己的协议时多考虑一些问题,避免常犯的错误,为国家的新基建做出正确的贡献,不要因为一些基本的问题没搞清楚而浪费国家的资源。


It Has To Work. 
1.必须要能够工作网络其实非常简单,无非就是编解码传输的工作而已。但是很多凭空臆想出来的编码方式总会有很多缺陷,甚至发现某些协议在一些非常常见的场景下无法工作,所以这第一条也无可厚非。例如做什么
SDWAN连IPv4 Underlay 都不支持,我在说啥有些人自己懂。

而针对IPv4 Internet,虽然有MPLS over UDP,但是又不得不考虑NAT的问题,我在设计Ruta的时候最开始定义的编码格式和转发方式与SRv6相似,但在NAT穿越时就做的很不好,后来更改SRoU头格式,内含源目的地址或者由中继节点保持Stateful的状态机建立动态Pinhole,最终选择了前者,保持中继节点stateless是一个非常重要的属性。这一点还有一个问题来自于Scale,很多时候我们验证某个技术是否能够工作可能没有考虑到Scale的问题。例如整个SDWAN的实践过程中,你面对的是广域网,和传统的SDN有极大的不同,广域网的各种故障使得一致性很难保障,而广域网设备和控制器交互的延迟也极大的影响了控制器的容量。因此很多人还按照局域网SDN的思路设计广域网控制器,自然会出大量的问题。可以见到的是现在要满足全球部署的SDWAN单体控制器规模也就1000~2000个的规模,路径计算决策放到控制器上更是大错特错,所以某CXXI研究院搞的白皮书可以自己算算,在10,000个骨干网路由器和100,000个CPE规模的SDWAN网络中,路径计算延迟有多大,算法应该如何写。


No matter how hard you push and no matter what the priority, you can’t increase the speed of light.
2. 无论你多么的努力推送或者调整优先级,您都无法增加光的速度。

(2a) (corollary). No matter how hard you try, you can’t make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won’t make it happen any quicker.

2a.推论,无论您多么的努力,你也不可能在九个月内生下一个宝宝,有些时候您像它变得更快最终反而变得更慢

这一点说的案例就是DetNet,对于严格的时序要求和时延控制只能靠调整流量的优先级,而这些网络通常只能是轻载的网络。在重载的广域网长距离传输上实现DetNet就是违反了这一条,说的是哪家自己心里清楚。
DetNet放在轻载短距离网络中有它的优势,我以前还给某个制造业企业做过基于PLC时序延迟分析做预测性检验的算法,DetNet控制抖动对于工业控制线路提速和标准化有好处,特别是现在新的Single-Pair 10Mbps Ethernet标准用于替代原有的RS485还是很有价值的,在那上面执行DetNet可行。

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. 

3.如果有足够的推力,猪都可以飞起来。然而,这未必是一个好主意,因为我们很难确定它会在哪儿着陆。当这样的猪飞过头顶是,一定感觉很危险吧~

重读RFC1925,网络的12条军规

欲速则不达,其实在很多拥塞控制算法中,很多人都尝试着用更精确的RTT测量然后能够实现MIMD的方式,但最终很多有效的算法就是AIMD。HPCC采用INT获得了更精确的延迟测量,但是MIMD可能仅限于3Hops以内RTT小于100us的短距离通信使用,将其用在广域网上MIMD就没有价值了。所以你看Google的Swift依旧使用AIMD。

Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.

4.生活中的一些事情只能经历过了才会被充分的评估和理解。同理,网络中的某些事情绝对不会被某些既没做过商用网络设备也没有运营过实际网络的人充分理解。

魔幻的事情多的去了,毕竟行业规模扩大的过程中员工是稀缺的,而且一个行业快速发展了20多年后,真正懂的长者都大于35岁了。
最近有个客户抱怨,说十多年前IOS的CLI多好用,完全声明式的方式很容易理解,现在搞的乱七八糟的,编程也不好弄,CLI也不好记忆。
想起来去年一个同事跟我争论的时候说:“我的XXIE老师告诉我应该 xxxx”。荒诞的剧情啊,然后很多研发的同事也没有一线的网络运维经验,所以很多时候设计出来的东西也不好用。这一条太伤人了,就不多说了,心里明白就好。

It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.

5. 对于很多个独立的问题,总会找到一个复杂的相互依赖的解决方案,但通常来说,这是灾难开始的地方。

很多人都有癔病,一个技术好,哪里都想用,特别是在一些热门技术上。例如SRv6就是这样。例如加密本来好好的该用IPSec的,也要在里面去搞个SID做SFC来加密,DPI结果还要反过来Rewrite在SID里。最后SID太长了吧,采用压缩冗余前缀、二维指针定位、G-SID拼接、多种SID混编等创新技术来解决。其实很多事情你要想清楚,路由编码就是解决路由编码的事情,你非得把安全策略怼上来,这样就出现问题了啊。想我以前说过的,拓扑和策略是分离的两个东西,千万别混合在一起编码。不同的问题交给不同的系统来做,别总是想着一个东西控制全部。

非常经典的描述,也就是说,其实本质上policy需要做的一件事情是和拓扑解耦,解耦的结果其实就变得非常简单和显而易见了,也就是我们常说的SecOps和NetOps,一个管能不能访问,另一个管如何保证访问质量。SecOps更多是全局上的考虑通常采用Centralized Policy,而网络相关的则是Distributed Policy

zartbot.Ling,公众号:zartbot意图网络的语言学思考

重读RFC1925,网络的12条军规

It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.

6. 推卸问题总比解决问题简单,例如将问题推到网络架构的别的部分

(6a) (corollary). It is always possible to add another level of indirection.

推论:总是可以增加一层来迂回解决问题

从SDN上考虑,最开始的变革来自于数据中心虚拟化,数据中心的SDN伴随着应用为中心的ACI架构提出解决了自己的问题。然后就是园区网有线无线融合和基于用户为中心的UCI策略方案。都做完了,把最脏的活推给了中间的SDWAN,所以没有一家SDWAN能够做好的原因就在于此,SDWAN这个Domain中既要识别用户身份标签,又要识别应用标签,同时又把安全策略和选路策略同时执行,对于任何一个设备厂商都是挑战。


那么增加一层来解决问题的方案中,很多人会想到Overlay,但也存在问题,数据中心是按照应用划分Overlay的,而园区网是根据用户身份来划分Overlay的,中间SDWAN上只能大量的跨VPN的Route Leakage,性能和容量进一步下降。
所以最后荒唐到如下的地步:



It is always something7. 此事古难全

 (corollary). Good, Fast, Cheap: Pick any two (you can’t have all three).

好,快,便宜:最多可以拿两个

虽然说成年人的世界不讲选择,都要,但是网络上很多事情还是难以解决的,要承认任何方案都有其缺陷,例如ATM当年在技术上考虑的很周全,但是唯一的缺陷就是贵。如何经济有效的设计方案才是关键。最近这次疫情给我上了一课。很多人都需要100%的安全,不愿冒任何风险。有些省市发现一例就几百万人的规模做核酸,的确是安全了,做好了,但是也不便宜啊。上海市政府面对突发的机场周边感染做的就非常棒,张文宏的一句话:只要追踪的速度大于传染的速度就可控制,本质上就是在好、快、便宜中选择了快和便宜,而没有大规模的检测去追求好。

其实关于网络安全也是如此,看到很多金融机构在整个交易链条上构建了大量的防火墙,一个不放心还要换厂商异构,自然速度就慢下来了。所以针对网络安全我也一直倾向于根据终端行为的遥测数据采取逐步升级的做法进行清洗和隔离,例如日常监控的时候只看看有没有一些异常的连接行为,和异常的终端间互相通信,简简单单的Netflow日志就可以了,然后Netflow日志中根据Talos公布的高危或者Bad Reputation记录做一些Mapping分析就好。后面再慢慢的看到有问题的连接上沙箱或者SSL Proxy解密分析,没必要所有的流量都去做分析。

It is more complicated than you think.

8.事情总会比想象的复杂


对于技术,保持敬畏之心。任何时候当你想到一个“完美”的解决方案的时候,你要反思,为什么别人没想到,是否有潜在的不完美的地方?例如用SRv6来做SDWAN,其实最大的一个问题就是转发策略明文的放置在报头,如果BSID被盗用怎么办?特别是涉及到一些低延迟链路需要按流量计费的场景,某研究院的白皮书关于这个问题一个字都没提。
这也是我在做Ruta的时候被人问到的问题,都是需要满足First Hop Security的要求,最后想了一下,
如果真要做

最简单的方法
是PE设备预先产生OTP,如同
游乐园卖门票那
样,OTP可以通过别的TLS会话动态获取,
让终端
通过
OTP
Ticket构建一个SID
来短暂的开通一个Pinhole,例如买的2小时的票就Pinhole timeout 2小时,
但是问题又来了

终端如果在NAT后,开的Pinghole又有问题咯
… 那是SRv6的问题,毕竟有的企业为了安全和内网拓扑隐藏的需求还是会启用NAT66的。Ruta怎么解决的以后会说。

For all resources, whatever it is, you need more.

9.资源永远是不够用的

(corollary) Every networking problem always takes longer to solve than it seems like it should.

推论:每一个网络的问题,解决它的时间总比期望的要长。

最近同时跟各个公有云上的研发以及设备厂商的研发沟通交流,发现最大的一个问题就是:每个人都觉得对方的资源是无限的。设备厂商会假设云上的资源是无限的,因此设计的控制器强大到无所谓不能,可以上帝视角那样精确的为每个设备规划路线。而云端总认为接入的网络设备一个不够再加一个就行了。最终问题没解决的最大原因是:“还不是因为穷”。在资源调度上,设计要有一定的余量,同时在算法上去协调好各个部分,通盘的考虑资源,例如做Telemetry分析,某家的VTrace是很牛,P4 INT也很厉害,但是真要采集处理这些东西,一个数据中心起码要几百台服务器的资源,恐怕某些大厂大云都没有这个能力做。所以我前段时间关于这个问题写了一文:

遥测数据分析本质上就是统计,对于网络的测量无非就是延迟抖动和丢包,玩来玩去就这几个值。所以很多人看到别人做的工作想都不想就说:“不就是测个延迟么”,而真正懂的人会问你怎么测的, 结果的分布如何,数据是如何处理的,如何通过测量避免偏差的。

zartbot.Net,公众号:zartbot遥测的误区

我简单的在网络设备的控制面上做分布式的数据分析和聚合就解决了这个问题,具体的方案可以看这里。

我们就可以实现一种基于申明式的遥测(Declarative Telemetry) 系统。无论是运维人员还是最终客户,都可以输入<Who,When,Which>的Traffic Label,然后获取到详细的信息。但这样的系统需要在设备侧构建一个遥测分析引擎,实现分布式的AIOps,我们把这个引擎称为Nimble Engine. Nimble Engine是一个完全容器化部署的轻量级流式计算引擎,可以通过分布式KV数据库相互共享一些特征信息,例如应用名称和IP地址对应,或者用户名和设备地址对应等。所有的数据聚合都在这个地方,控制器仅需要获得最终的性能评分和故障分析结果即可。

zartbot.Net,公众号:zartbotThe Art of Telemetry

One size never fits all.

10.没有一个方案可以适用所有场景的

网络厂商总想把自己的产品卖到网络的各个地方去,以前某个厂商非要在数据中心交换机上加大Buffer说是为了应对Incast的场景,最后笑而不语。事实上不同的Domain都有不同的需求,例如有些时候为了快,吞吐率就要受损失或者承受误码率。例如我针对一些高频交易的公司通常建议他们关闭RSFEC,甚至在做FPGA的时候,不要使用AXIS协议。而这些东西对于高吞吐的业务反而会劣化。多学习一些知识没有错,多了解一些应用的开发也没有错。
根据应用的特征来设计网络才是关键,有的人看AWS做啥,看Azure做啥也要跟着做,看着Google有Swift,Facebook有自己的交换机也要跟。其实每个公有云都有自己的业务特征,例如阿里以交易居多,可靠传输要求更高,而腾讯自己游戏对时延要求更高,头条则是对带宽的需求更多。多了解自己的业务模型才能更好的为它设计网络。

Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.

11. 每一个旧的想法总会用不同的名字或者方式再次呈现,不管它是否能工作

(corollary). See rule 6a.

推论:见6a:总是可以增加一层来迂回解决问题

记得有位大佬说过,网络上屠龙刀式的变化哪有那么容易,都是把已有的技术组合起来适合当今的场景。因此不要以为自己的创新能够做出什么惊天动地的变革。注意关键的前提是:已有的技术要在适当的场合出现,例如20年前搞Overlay和SR源路由可能因为网络带宽本来就小,这些header占用太多的带宽直接就被毙掉了。
例如Ruta,很简单就是一个
QUIC+SR的结合,
只是它巧妙地出现在一个终端能力越来越强,整个系统越来越去中心化的地方。
但另一方面这也不是我们守旧的理由,例如前几天说某厂搞了一个BGP的HA TCP socket,说实话BGP自己的问题为什么要魔改TCP协议栈呢?BGP把自身的状态机和TCP会话耦合在一起,本来就是当年设计的缺陷,历史上为了解决这个问题还诞生过Multistreaming BGP,我自己也搞过BGP over SCTP来通过Multihoming解决HA的问题。说实话这样魔改TCP协议栈完全没有意义,所以推论里参考6a.把传输层和应用层解耦才是解决问题的关键。

In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.

12.在设计协议时,仅当无法再拿掉什么时才算完美,而不是无法再增加什么


这一条讲两个故事,
第一个
故事

Clarence在设计Segment Routing时,
减掉了LDP,直接在IG
P里面把一些事情处理就好了。第二个故事关于SDWAN,常用的IPSec就是增加到再也无法增加的地步了,各种各样的协商消息,加密套件,长年累月的向后兼容搞的无比的复杂,本质上你需要的是什么?两个节点之间的对称密钥和地址构建SA就好了,所以为什么Linux的用户非常喜欢WireGuard就是这个原因,我在Ruta的SDWAN解决方案中没有选择IPsec也是这个原因。而在SDWAN中很多厂家用BGP做路由控制平面,然后又添加Yang/Netconf做编排控制,然后还有用Netflow、YangTelemetry、BGP-Linkstate做性能采集和Assurance的。何必呢?我在设计Ruta时直接把所有的复杂协议都去掉,简单的构建一个ETCD就完成了所有上述的任务,本质上就是节点间的分布式协同罢了。

我们采用了ETCD来实现分布式一致性,同时伴随着标准的操作接口,降低了传统路由协议编码的复杂度,而且现阶段网络带宽已经足够大了,并没有太大的必要去精心压缩bit位,编码解码带来的汇聚收敛延迟可能比网络传输还大,而利用ETCD的接口,应用层也可以轻松的定义自己的网络SLA,对网络的编程更加容易。自组织的实现可以是大量的核心交换机路由器节点构成ETCD集群,而任何一个网络上的设备都可以构成一个Proxy,通过LinkLocal地址relay控制信息。这样又很容易的解决了Controller placement的问题。

zartbot.Net,公众号:zartbotRuta?智能插座?重新发明路由器!

重读RFC1925,网络的12条军规》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/375.html