拜读孟哥学位论文(1)
孟哥个人首页: https://zilimeng.com/
由于清华大学的学位论文不是公开的, 只能在官网上拜读了,
首先我需要了解一下这方面的背景知识, 从孟哥的学位论文文献综述部分开始
此笔记为本人阅读该论文后的个人理解, 以及对该领域背景的了解和阐述, 本人承诺记录此文章仅用于个人学习, 未存在转发校内学位论文内容的情况.
研究背景和研究意义
实时多媒体传输
- 背景: 互联网和生活密不可分, 随着时代的发展, 互联网的速度和带宽也得到了极大的提升
- 应用: 多媒体传输应用非常广泛 , 包括音乐, 图像, 文本等, 实时传输的媒体包括直播, 游戏, 以及医疗应用等
- 架构 : 多媒体传输说白了也是包传输 , 同计算机网络的多层机制一样 (物理层, 链路层, 网络层, 传输层, 应用层) , 目前的科研工作主要围绕 网络层, 传输层和应用层展开.
会议:
- 网络高水平会议包括: SIGCOMM , NSDI 等
- 多媒体方向会议有: MM , MMSys 等
- 工业界: 谷歌的 WebRTC , 阿里巴巴的 AliRTC , 腾讯的 TRTC 等
性能评估
- 延迟(最重要) , 其他的有用户体验QoE(Quality of Experience 等)
- 截止时间(很严格) , 端对端延迟不同的应用有不用的要求, 一般约为 50-150ms
- 截止时间措失率(DMR, Deadline miss ratio) , 超过截止时间丢失的包的比例
- CCDF (见另一篇解释)
现在前沿的研究, 会研究极端情况, 比如说 RTT == 1.6 时的网络情况
(这部分虽然占比很小, 但是有可能发生, 发生时可能造成严重的后果, 尤其是延迟敏感的应用程序)
传统研究多半研究中位数, 就是网络延时的一般情况
研究内容
- 研究大对象 : 多媒体传输的延迟波动等一系列问题
- 研究展开 : 为了解决延迟问题, 我们可以从多媒体传输架构, 多媒体传输协议, 媒体压缩, 以及数据通路等多个方面展开.
孟哥的大论文里提了一下控制通路和数据通路, 然后提了一下现有研究的一些缺陷.
传输架构
实时多媒体, 比如说视频, 包括很多视频帧 其他多媒体也类似, 都是拆分成小件, 然后最后重新组合成为大件
在这个过程中, 有两个通路, 一个是数据通路(也可以理解为包的传输通路, 应用层,传输层, 网络层), 一个是控制通路, 这两部分很大程度的影响整体端对端的延迟.
整个传输架构中有很多组件, 组件对组件之间也有影响.
控制通路
控制通路 , 顾名思义, 就是对整个网络的传输进行控制
如果发生了网络阻塞或者发生了网络故障, 控制通路就会像交警一样, 指挥数据包进行传输, 从而解决拥塞问题.
所以如何决策, 以及如何检测, 就是控制通路主要要解决的问题
- 检测: 主要是网络拥塞之后, 如何发信号到我的控制中心, 因为网络中噪声很大, 所以这种检测不能太敏感, 也不能太迟钝. 而且检测信号发出后, 到达控制中心也需要一定的时间
孟哥举了一个例子, TCP 传输中, 消息主要是通过 ACK 包的延迟变化进行传递. 这时反馈的时间就需要一个往返时延
- 决策 : 现在是控制中心接收到了我的信号, 那么我需要怎么做呢, 等待? 还是立即行动. 如果要行动, 那么需要做什么. 这是决策的内容.
数据通路
数据通路, 顾名思义, 就是在传输信道里, 数据进行流动
抛开物理因素不谈(传输介质对传输速度的影响,应该是物理学家要做的工作)
我们关注于排队在等待队列里的数据.
- 应用层: 这里的延迟主要是数据处理不够及时, 新来的数据就会在等待队列里排队
传输层: 这里的延迟主要是丢包恢复. 丢包的原因有很多(网络干扰, 队列溢出等),
发送端需要检测这些问题, 然后重传, 这些都会产生额外的延迟(检测对应控制通路)
网络层: 这里的延迟则是队列的速率和带宽不匹配造成
多个用户的不同流量会共享（或竞争）同一资源一带宽。而其他用户的流量特性又往往是当前用户难以提前预料的。例如，如果与某个实时多媒体传输的流竞争的其他用户突然增大了发送速率，那么该实时多媒体传输流量的可用带宽便一般也会因之减少
孟哥的工作 : 减少控制通路的反馈时间, 优化决策框架, 数据通路延时优化, 丢包恢复优化, 抑制排队(多的不方便说, 不过孟哥的文章写的确实好啊)
