摘要：
首先说明更便宜的内存，高速链路、和更高速处理器会解决计算机网络中的拥塞是假的；然后建议一个给予供给和需求的简单拥塞定义和各种拥塞模式。使拥塞控制变得困难被讨论并呈现且影响拥塞模式设计的架构决策。针对长期、中期和短期拥塞问题有不同的方法被讨论。
介绍
拥塞控制是关于在需求超过或接近网络资源容量的时候如何分配资源来得到一个可接受的性能级别。网络资源包括链接贷款、缓冲区空间（内容）和中间节点处理器能力。尽管资源分配即使在低负载的时候也是很重要的，但随着负载增加公平性问题和低overhead变得更重要，如果没有适当的拥塞控制机制，在重负载下网络吞吐量会减少的很严重。
关于拥塞控制的神话
拥塞发生在需求大于可用资源；因此就会说如果资源不再昂贵，拥塞问题就会被解决，这就是下面的几个神话：
1. 拥塞由空间缺乏导致的，能随着内存便宜而解决，因为有无限的内存。
2. 拥塞由低速链路造成的，随着高速链路普及而被解决。
3. 拥塞由慢处理器导致的，随着处理器速度的提高被解决。
实际上即使上面的这些说法，如果没有适当的协议控制，上面的解决办法不会解决拥塞反而导致更多拥塞因此降低性能。下面详细解释。
1. 大的缓冲区空间不能解决拥塞问题。一些研究发现无限缓冲区大小的交换机与有限缓冲区大小有同样的拥塞。有限缓冲区交换机会丢包；但无限缓冲区的交换机会将数据缓冲的太长而导致应用层已经认为数据无效而重传。总之，无限缓冲区实际上是有害的，主要因为其可能导致无效的使用网络资源。
2. 高速链路的使用不会解决拥塞问题，反而增加了对拥塞控制的需求。因为所有的高速网络都是和低速网络连接的，而且随着高速网络的增加也不会导致低速网络就能自动消失，这要求应用层设计协议能确保不会降低性能。
3. 高速处理器的引入也不能解决拥塞问题；因为和链路速率一样这也会导致拥塞速率不匹配的问题。
4. 即使所有的网络资源都是同等速度的，但仍然不能解决这个问题。这是因为不能保证网络的任何地方都是合理配置而保证没有不匹配现象。
因此拥塞是一个动态问题，不可能使用静态的办法来解决，这需要协议设计来保存拥塞下的网络。高速网络的扩大导致更多不平衡的网络是拥塞的原因，而由缓冲区缺乏导致的丢包是一个症状但不是拥塞的原因。
拥塞问题的定义和解决方法
计算机网络中，如果一段时间总资源的需求数量是小于可用资源数据量，就导致简单的拥塞。计算机网络中有很多资源，如：缓冲区、链路带宽、处理器和服务器等。如果某个间隔缓冲区空间不够，那么导致包丢失。简单的说，如果短时间内期望进入链路的总流量比带宽大，那么链路就是拥塞的。
拥塞模式分为两大类：
1. 动态增加可用资源
2. 动态降低需求
资源创建模式
这个模式同通过动态的重新配置资源来决定，例如：
1. 在高使用率情况下增加拨号连接
2. 增加卫星链路的电力来增加带宽
3. 考虑使用低负载时非优化的网络来传输额外的数据
上面的所有模式，资源用户都不需要被通知，他们甚至不知道网络的拥塞，网络自己负责接着拥塞问题。
需求减少模式
这通常要求资源的用户能知道负载的状况来调整流量。三种基本的模式：
1. 服务拒绝模式：拥塞时不允许建立新的会话。面向连接的计算机网络使用相似的模式在中间节点上组织会话的建立。
2. 服务降级模式：这个要去所有的用户（已经存在的或新加入的）减少负载。动态窗口就是这种方法的表现。
3. 计划模式：这种模式要去用户能计划资源而保证小于容量。必须指出的是这种模式只是降级模式的特殊情况。
在无连接网络中，会话的建立不需要中间节点的同意，因此服务拒绝模式通常无效，而使用服务降级模式和计划模式。
反馈和控制
所有上面的模式通常都是先测量网络的负载然后采取补救措施。第一部分叫做反馈，后面的叫做控制。反馈通常是从拥塞资源出到一个或多个控制点；在需求减少的模式，控制点一般是数据源，而创建型模式控制点可能是中间节点。
反馈模式
1. 反馈消息，拥塞资源点生成单独的消息发送给控制点；源收到消息后降低负载或者增加负载如果没有收到的话。代价是需要额外的负载。
2. 路由消息中的反馈:每个中间节点给邻居发送负载信息
3. 注入更多的流量：背压
4. 探测包：发送探测包来得到负载状况
5. 顺带包中的反馈字段：不单独产生反馈包，而是在反向数据中捎带。
控制点位置
1. 传输层: 通讯流量是由终端系统产生的，因此最好的控制点在传输层。例如动态窗口机制。
2. 网络接入层：就像告诉公路的入口出的红绿灯，在网络层增加访问控制来限制拥塞时流量进入网络。
3. 网络层：在路由器和网关上增加对拥塞控制的处理。
4. 数据链路层：在每跳的数据链路层上使用流控机制。
为什么问题是困难的？
虽然有很多关于拥塞控制的提案，但这方面的研究至少进行了20多年，主要有两方面的原因。首先对拥塞控制模式的需求很难让其达到一个满意的方案；其次有几个网络策略影响拥塞模式的设计。因此一个模式在一种结构下工作很好，但其他结构却不一定。关于第二点的几个问题下面来讨论。
1. 模式必须是低开销的：这要求控制不会增加额外的开销，这就是为什么单独反馈消息是不合理的原因。有些人建议只有在低负载的时候发送反馈，而缺少反馈默认表示高负载。
2. 模式必须是公平的：公平性在高负载的时候非常重要；重要的问题是如何合理分配资源。
3. 模式必须是反应灵敏的：网络可用资源是变化的，随着节点和链路的增加或减少，可用容量增加或减少；用户开始或停止，需求也增加或降低。拥塞控制模式应该能和需求以及可用容量动态匹配。因此其在可用容量增加的时候要告诉用户增加需求，反之告诉用户减低需求。需求曲线应该和容量跟随紧密。
4. 模式必须能在差的网络环境下工作：
5. 模式必须是社会最优的：
影响拥塞控制模式的策略
拥塞控制的基本原则
拥塞控制是一个关于控制的问题，大多数拥塞控制模式都是由反馈机制和控制机制组成。在控制理论中，控制频率应该等于反馈频率。快则不稳定，慢则反应不够。这个必须在设计控制模式的时候考虑怎么样处理间隔。
另外一个可以从控制理论中学习的是，没有任何模式可以解决持续时间小于反馈延迟的拥塞。传输层的动态窗口（或速率）模式，只有在拥塞持续几个RTT才能控制；对于时间非常短的拥塞，数据链路和网络层控制更合适（例如：优先级，缓冲区，输入限制等等）。
如果是长期的拥塞，或者是会话级别的祸资源创建性模式应该被使用。如果拥塞持续时间不确定，安装一个额外资源是最好解决问题的办法，而很短的拥塞动态模式更好。
显然拥塞长短不能提前检测，因此最好的办法是将不同层次的方法合并起来。
其他建议方法
基于时间溢出的拥塞控制
这种方法是基于这样的想法：包丢失是拥塞的好的指示，而时间溢出表明网络上的负载要减少。后来如果没有丢失，那么负载慢慢的增加。其中之一CUTE（congestion using timeout at the End-to-end layer）窗口在时间溢出的时候降低到1，仅仅只能传输一个包。
拥塞避免的DECbit模式
正常的数据传输表现这样的特点：在低负载时，吞吐量随着负载增加而增加；如果网络负载达到网络容量是，吞吐量停止增加，这个点叫做knee，如果负载进一步增加，开始排队，可能导致丢包，达到一定程度吞吐量突然下降，这个点叫做cliff。
拥塞避免模式就是让网络在knee和cliff之间运行。
简单的拥塞避免方法是在网络层头加一个bit，参见：congestion avoidance in computer networks with a connectionless network layer.
拥塞避免基于延迟的模式