网络通信行业PR的艺术

像渣这种左手写代码，右手写PR，既搞技术，又搞MKT深入技术的并不多.因此渣有另一个比较擅长的领域就是把一些看似奇葩新的技术让客户广泛的接受并且又创造新的看似奇葩的技术。

渣的职业生涯里就有这样一段，某司ASR1000系列路由器发布以后在国内年销售额一直徘徊在人民币2000万不到的水平，美国那边BU比较着急就把渣弄来兼职丢锅里搞一搞… 花了三四年的时间就很快做到了人民币4个亿，于是渣也有了写这个行业PR艺术的能力. 

国内一些除了华为阿里(因为这两家做的特别好)的厂商可以思考一下

任何新技术推向市场是否能够成功都需要考虑很多因素, 而最根本的问题是讲清楚自己的产品逻辑并和客户的商业逻辑绑在一起. 

记得我刚接手ASR1000的时候,某司四大行的一个销售工程师就怼过我:“你一个20Gbps的路由器卖的比7600 720Gbps的路由器还贵,你们BU定价脑子抽了”,

结果这个销售很快就把这个银行的单子丢了,而其它大行和交易所则在ASR1000这个平台上持续的换了几代.而破局的关键根本就不是路由器的功能，而是NAT、防火墙、DPI、性能路由、IPSec等…

同样当年也有Pipeline和RTC的争论，ASR1000作为唯一个RTC的平台和NE40E、SR66、JNPR-MX以及自家高端的ASR9K竞争，性能不到人家的1/10，价格还基本上一致，大家可想而知在国内这种简单粗暴算pps数端口的招投标下我是如何把这个产品销售额在4年时间翻了20倍的？

最终赢下来的都是因为在同样的速率下提供了更多的功能，去和用户商业逻辑紧耦合的功能。其实你会发现一个用户当年可能广域网带宽就10Gbps，根本就不需要一个720Gbps的路由器，而同样一个10Gbps的接口可能因为连接数千个分支机构，需要加密、需要大量的QoS队列，需要大量的ACL和防火墙功能，以业务需求为导向让用户去明白自己真的需要的是什么，自然就很快打动用户下单了。例如我们最早做CGN和清华一起做NAT64最后将ASR1000作为防火墙参加某运营商集采然后还中标了.另外还有某个大型国有银行直接拿ASR1000来做TAP流量分析和APM、NPM，上线十年后思科终于把这个解决方案构建成了一个标准的产品,也就是Cisco DNA Telemetry Server解决方案。至于很多关键的证券交易所，很简单的去满足行情公平和Burst抑制的功能就够了，正是这些细节的和用户商业逻辑紧密结合的功能，国内很多厂商做的并不好，只是徒有高性能指标，但真的无法解决用户的刚需。

如今DPU的乱战里，也有很多反思，AWS是唯一一个商用的RTC平台，当然还可以算上Fungible和国内的云豹，以及Marvel CN10K，而其它一众清一色的FPGA或者P4 Pipeline。要功能还是要速度，还是满足速度的前提下提供更多的功能？例如AWS可以很快的通过软件实现SRD，而其它家很有可能在可靠传输协议上走太多的弯路…

>包处理的艺术(3)-RTC vs Pipeline<

当然新产品的或者新的协议对于上下游的生态也是需要关注的。很多技术都有自己的生命周期和相应的技术债务，这是很多人在做一个产品管理的时候经常出现的问题。通常一个产品的PM在产品前期导入市场的时候特别忙，run rate跑起来了以后却忘记了相应的技术债务和产品转型，直到产品本身不适合市场了，或许也就是和产品一起消失在整个行业中。

一个新产品在研发初期一定不会是只是去解决某一个特别的问题，而且解决某个特别的问题一定不是那种推倒重来的方式。例如MPLS-SegmentRouting的成功就是非常好的一个案例，通过新增一个加法(IGP分配SID)，然后不影响原有的LDP，同时又支持SR-LDP的互操作，然后通过TI-LFA替代了FRR-TE，最后通过BSID替代整个RSVP-TE，然后去掉LDP，一步步导向市场做的非常干净漂亮。而SRv6虽然标准制定也结束了，但最终很难推向企业市场，即便是运营商市场也没有明显的看出比MPLS-SR的优势，技术本身的问题就在于此。所以你会看到华为提出NewIP时几乎很多厂商都发文反对的原因。

另一方面像P4这样的技术，技术本身是很不错的，但是推向市场的时候出了什么问题？因为性能可满足的情况下用RTC DPDK可以获得更好的灵活性，而性能不满足的地方，P4本身的可编程能力也解决不了很多问题，例如网络里那些Stateful的转发功能。而且这样的功能导入用户侧的学习成本太高，也是值得各个DPU厂商深思的，你们的DPU未来两三年就要投放到市场里，软件的生态和用户生态考虑好了么？虽然一颗DPU来看是一个硬件的ASIC项目，配套的软件生态其实更难培育。而且有些时候你还不得不为了软件生态而放弃一些硬件的技术路线，这也是我们当年做ASR1000那块核心芯片QFP的时候所考虑的， ASR1000 QFP和CRS-1 SPP/QFA、ASR9000 LightSpeed同宗同源，但是为啥单纯的转发性能差了那么多？很多时候转发pps不是一颗DPU的本质。

很欣赏AMD zen架构师Mike Clark接受采访的一段话：

MC：所以对于 Bulldozer 架构，我想这些年来我已经了解到构建 x86 内核就是在架构中找到频率、IPC、功率和面积之间的正确平衡。我们没有使用 Bulldozer，所以我觉得我们的新项目需要一个名称来说明我们的真正目标是什么，即拥有一个平衡的架构。Zen “禅”这个名字对我来说对我们正在做的事情很有意义。

Zen的成功来自于平衡，什么都做到最好当然有可能，但是一定包含价格最贵。很多时候你需要设计一个用户可承担的架构体系并在更新换代的过程中为用户节省开支。例如很多国内客户一直叫我们做分布式的ASR1000，因为对标产品都有，但是我们一直坚持不做，原因非常简单，分布式看似性能提升很多倍，但是带来的用户叉车升级的代价也是巨大的，有些时候为了一个功能每块卡都要升级，费用太高，而集中式通常换一块转发引擎就行。而我们也实现了我们的承诺从最初的10Gbps引擎逐渐平滑升级到200Gbps，如今依旧能在满足用户广域网带宽需求的情况下提供很多功能，而内在的成功关键也在于平衡。

而给一个架构师的最大的褒奖也就是设计了一个平衡的架构。因为一些激进的架构通常存活时间不超过5年，而大师估计能做一个用十年的架构，大神例如冯诺依曼的架构会在经历70年后才遇到瓶颈。国内很多架构师为了KPI做PR，然后以PR为导向做架构，其实很快的就会把自己陷入到一个尴尬的境地，几年后要自己推翻自己的心血，那种痛苦渣就不多说了，例如渣看到当年某司搞IWAN，渣阻止了自己的很多客户上这个架构以至于销售额下降还得罪了不少人，不过很多客户事后还很感谢渣。而后期即便是Viptela SDWAN，渣也是慢慢的等技术演进成熟了才让导入市场，因为你需要让客户在惯性思维上实实在在遇到问题了，才会想着用新的方法解决问题。

例如现在几乎所有搞SDWAN的还在用集中式算路的解决方案，渣也就笑笑等你们后面遇到生产事故了才发现分布式的好。还有某司搞集中式的AIOps，直到现在碰壁了才想起渣的分布式AIOps解决方案,于是渣最近又要开始把几年前的另一个工作导向市场了…

渣基本上做一个架构会先去看到5年后的市场会如何，然后倒推做预研。例如2018年在网络设备上做AI推理引擎和遥测智能分析，本质上就是预测到2022年以后集中式控制器解决不了数据量的问题，所以很简单的就在2019年获得了某司的大奖。但是渣并不急于推向市场只是作为技术储备直到工业界都真的看到这个问题了以后再拿出来。

而同样像NetDAM这样的项目，只是本质上会看到未来3~5年主机网络到了400Gbps以后，传统的DMA本身就会遇到缺陷，而提前在这个赛道布局，但是整个布局过程中也不急于推出到市场，因为Fungible和juniper很多人都犯了这样的错误。当年juniper推Q-Fabric的时候，很多人对于SDN本身的复杂度还没有意识，所以当时JNPR的广告并没有打动多少人，而是等到Insieme的时代，以应用为中心去解决SDN的各种复杂逻辑并且伴随着OpenFlow的失败，恰当的时机推出才会获得成功。

至于NetDAM技术路线上，现阶段数据中心100Gbps因为DMA带来的开销即便是在LLC完全CacheMiss的时候也就20GB/s对于整个系统影响并不是很大，但是userspace的内存直接访问去绕开RDMA这些特殊硬件实现或许是更关键的，因此渣更倾向于现阶段使用软件的memif方案即开源的zmemif，通过软件的解决方案为Go赋能高性能I/O，并把Serverless中的网络栈慢慢取消掉而进一步降低冷启动时间。然后慢慢的等memif这样的方案成为市场主流了而数据中心200Gbps、400Gbps主机网络逐渐出现的时候，再导入硬件的NetDAM。有些时候先期进入市场反而是死的最惨的那个，例如Fungible 从2016年就提出DPU，多么先进的理念啊，但是最终获得Reputation的居然在公众眼里是收购卖螺丝的黄教主。

而其他一些技术，例如Ruta这样的SegmentRouting Over UDP的技术，我也尽力避免和SRv6、IPv6+的标准争论。只是简单的在底层我都支持MPLS、IPv6、IPv4，上层更多的和一些应用团队合作导入落地，例如某个元宇宙大厂，当然还有华为云也学了类似的技术。本质上的技术标准因为分布式控制器本身颠覆了一些传统的思维及云原生的架构并不能被传统网工接受，所以导入市场的时候故意在过去一年放缓了一些节奏，直到大家看到GCP、FB因为BGP和控制器的一些大的生产事故后，以及Google发布Orion这样的分布式控制器架构后，再慢慢开始加速导入。

让客户意识到生产故障和潜在风险，并在风险即将发生时，导入新产品，而新产品本身设计需要有足够的泛化能力去适应用户未来5~10年的需求，其它的什么指标第一都是空话.