拥塞管理者.pdf

拥塞管理者 Nick Feamster 麻省理工学院计算机科学实验室 6.829 计算机网络 2001年10月24 日 概述 o 动机（CM解决什么问题？） 并发的流的信息共享 允许应用的适应性 o CM 的体系结构 o CM API （以及权衡） o 更多的关于CM 的框架的信息… o 实现 o 局限性 动机 o 端系统提供更多的功能性 可靠性 按序的递交 解复用 信息边界 连接抽象 拥塞控制 在这些当中，拥塞控制是所有通信应用程序都 要求的唯一的功能性。 问题 “多媒介传输将网络引向堵塞Multimedia Transmissions Drive Net Toward Gridlock” o Sara Robinson, NYT, 8/23/99 目前端系统的体系结构 TCP 的AIMD 解决这样这个问题，是吗？ o 不允许应用的适应性 流（例如，视频，音频等） o 不能控制并发的流 例如，WWW 可从共享信息中获益的任何应用 适应性 o 很少的信息会穿越层到达应用程序 o 日益增长的非TCP应用 CM输出了一个简单的适应性API 并发流：Web 的问题 o Web浏览器执行并发的下载 内嵌对象的同步下载 代理可以复用请求 积极的下载= 更高的带宽 o 但是 为什么每条连接启动非常慢？ 信息的丢失在流间不能共享 更多的连接＝更多的带宽！（公平？） 并发流间存在竞争，应该还有协作！ 我们如何来保证行为的公平性并且从并发下载中获得一 些好处？ CM抽象了所有拥塞相关信息到一个位置。 概括图 o CM为宏流macroflow执行所有的拥塞相关工作 o 应用使用CM －输出API来进行适应 o 从CC重新执行的自由传输/API协议 问题 o 发送什么？ API o 何时发送 拥塞控制器 o 谁来发送 调度器 o 什么是网络状态？ 应用反馈/CM探测 或者…当应用提供反馈时避免修改接收者的栈 CM体系结构 CM体系结构 o 从传输中分离拥塞管理 o 多应用和协议可以共享拥塞信息 o 分离拥塞控制和调度 Macroflow宏流 o 所有在一个“宏流”上的流量共享拥塞状态 o 什么是一个“宏流” ？流量被如下方式分组： 目的地址? 地址和端口? 端主机应用？ o 让应用将流分组成宏流来共享状态信息 o 快速的检测好的宏流… CM API o 状态管理 cm_open() – 返回流ID cm_close() – 关闭会话 cm-mtu() – 为流获得路径MTU o 数据传输选项 缓存的发送 请求/ 回叫 速率回叫 o 应用通知 cm_u