TCP congestion control

       An important problem in the Internet is congestion. If the load on a network (that is, the number of packets sent to the network) is greater than the capacity of the network (that is, the number of packets the network can handle), the network is likely to be congested. Congestion control refers to the mechanisms and techniques used to control congestion so that the load remains below capacity.

       We might ask why is there congestion in the network? Any system that involves waiting will be congested. For example: any traffic jam caused by something unexpected in the flow of traffic is the cause of congestion on the highway, such as a car accident during rush hour.

      Congestion in a network or internet is due to some queues in routers or switches, ie buffers used to hold packets before or after they are processed. Packets are put into the appropriate outgoing queue and wait their turn to be sent. These queue spaces are limited. Therefore, the number of packets arriving at the router may be greater than the number of packets that the router can hold.

      Congestion control refers to techniques and mechanisms that can prevent congestion before it occurs, or eliminate it after it occurs.

 

Open Loop Congestion Control

     Using some strategies to prevent congestion before it occurs is called open-loop congestion control. In such mechanisms, congestion control can be handled by the source or the focus.

 

retransmission strategy

      Sometimes retransmissions are unavoidable. If the sender feels that a sent packet is lost or damaged, then the packet needs to be retransmitted. In general, retransmissions may increase network congestion. However, a good retransmission strategy can prevent congestion. This requires the retransmission congestion period and the retransmission timer to be designed to optimize efficiency and prevent congestion at the same time.

 

window strategy

      The type of sender window can also affect congestion. 

 

Confirmation Policy

       The acknowledgment strategy attempted by the receiver may also affect congestion. If the receiver is not acknowledging every received packet, it also enables the sender to slow down the transmission rate, thus helping to prevent congestion. Several ways can be used in this situation. The receiver can send an acknowledgment only when it has packets to send, or when a special timer expires. The receiver may also decide to send acknowledgments for N packets at a time. Be aware that these confirmations are also part of the network burden. The fewer confirmations that are sent, the less burden it places on the network.

 

closed loop congestion control

       Closed-loop congestion control mechanisms attempt to alleviate the extent of congestion after it has occurred. Several such mechanisms have been used in different protocols. What we are going to describe is the mechanism used in the transport layer. The sender's window size can be flexible. One factor that determines the size of the sender's window is the congestion of the Internet. The sender's transport layer can monitor the congestion of the Internet by observing packet loss, and if the congestion worsens, use a strategy to reduce the window size, and vice versa.

 

congestion window

The sender's window size is determined by the receiver's available buffer space (rwnd). In other words, we assume that only the receiver can instruct the sender application how large the send window should be. At this point, we completely ignore another entity, the network. If the network can't deliver data to the receiver as fast as the sender produces it, then it has to tell the sender to slow down. In other words, apart from the receiver, the network is the second entity that determines the size of the sender's window.

      The sender has two kinds of information: the window size advertised by the receiver and the congestion window size. The true size of the window is the smaller of the two.

      real window size = minimun(rwnd, cwnd)

 

Congestion Policy

      TCP's general strategy for handling congestion is based on three phases: slow start, congestion avoidance, and congestion detection. In the slow start phase, the sender starts with a very slow transmission rate, but quickly increases the rate to a threshold value. When the threshold is reached, the growth of the data rate starts to slow down. Finally, as soon as congestion is detected, the sender goes back to slow start or congestion avoidance, depending on how the congestion was detected.

Slow start: exponential increase

        The slow start algorithm is based on the idea that the congestion window size (cwnd) starts from 1 maximum segment length (MSS). MSS data is determined at build time with an option of the same name. Every time a segment is acknowledged, the congestion window is increased by 1 MSS. As the name implies, the slow-start algorithm starts slowly but increases exponentially. To illustrate this concept, refer to the diagram below. We assume that rwnd is much larger than cwnd, so the sender's window size is always equal to cwnd. To keep it simple, we ignore the delayed ACK policy and assume that each segment is acknowledged individually.

       发送方从cwnd=1MSS开始。这标识发送方只能发送一个报文段。在第一个ACK到达后,拥塞窗口大小增加1,也就是说现在cwnd是2.此时可以发送两个报文段,当相应的两个ACK到达后,对于每一个ACK,窗口大小增加1MSS,这就是标识cwnd 现在是4,。此时可以发送4个报文段。当四个ACK到达后,窗口大小又增加4,也就是cwnd等于8.

 

      如果我们从往返RTT的角度来看cwnd的大小,就会发现它的增长速率是按指数规律的,如下所示:

        在推迟确认的策略下,慢开始策略的增长速度要更慢一些。我们知道,对于每个ACK,cwnd只能增加一个MSS。因此,如果三个报文段被累计确认,那么cwnd的值仅增加1MSS,而不是3 MSS。这个增长仍然是指数的,但是它不再是2的乘方。如果每两个个报文段使用一个确认,那么它大约是1.5的乘方。

       慢开始不能无限制的继续下去。一定要有一个门限来停止这个阶段。发送方密切关注一个为ssthresh(慢开始门限)的变量。当以字节的窗口大小到达这个门限时,慢开始阶段就结束了,并进入下一个阶段。

 

拥塞避免:加法增大

       如果我们从曼算法开始,拥塞窗口大小就按指数规律增长。为了在拥塞发生之前避免它,就必须使这种指数增长的变慢。TCP定义了另一个算法,叫作拥塞避免(congestion avoidance),使cwnd的值按照加法规律增长,而不是按照指数规律,见下图。

 

        当拥塞窗口大小达到慢开始的门限时(此时假设cwnd=i),慢开始阶段就停止,而加法增加阶段就开始了。这种算法中,每当一整个“窗口”中的报文段都被确认后,拥塞窗口大小才增加1。一个窗口就是指在一个RTT期间传输的报文段的数量。换言之,这个增长是基于RTT的,而不是基于到达的ACK数量。为了说明这个思想,我们把这个算法应用到和满开始一样的情况中。此时,发送方收到了一个完整窗口大小的报文段的确认后,窗口的大小增加1个报文段。如果我们从往返时间RTT的角度来看cwnd的大小,就会发现速率是按照加法规律增长的。

 

 拥塞检测:乘法减小

        若拥塞发生了,拥塞窗口的大小就必须减小。让发送方能够猜测到拥塞已发生的唯一现象就是它需要重传一个报文段。这也是TCP做出的一个重要的假定,之所以需要重传是为了恢复一个意识的分组,而这个分组假设是因为某个路由器有太多的输入分组而不得不丢弃,所以才被丢掉的,也就是说,路由器或网络已变得超载或拥塞了,不过,重传可以发生在以下两种情况之一:当RTO计时器超时,或者是当收到了三个重复的ACK时。不管是哪一种情况,门限值都要下降到一半(乘法减小)。大多数的TCP实现由下面两种反映:

1、如果是计时器超时,那么出现拥塞的可能性就很大。某个报文段可能在网络中的某处被丢弃了,而后续的报文段也没有任何消息。在这种情况下,TCP有下面较强烈的反映:

a、把门限值设置为当前窗口大小的一半

b、把cwnd重新设置为一个报文段

c、再次从满开始阶段开始

 

2、如果是收到了三个ACK,那么出现拥塞的可能性就较小。某个报文段可能被丢弃了,但之后的几个报文已安全到了,因为它收到了三个重复的ACK。这就称为快重传和快恢复。在这种情况下,TCP有下面这样较弱的反映:

a、把门限值设置为当前窗口的一半

b、把cwnd设置为门限值(某些实现会在门限值上再增加3个报文段)

c、启动拥塞避免阶段。

 

拥塞小结

TCP拥塞策略以及这三个阶段的关系见下图。

 

       假设最大窗口的大小的初始值是32个报文段。门限值的初始值设置为16个报文段(最大窗口的一半)。在慢开始阶段,窗口大小从1开始逐渐按指数规律增大,只是窗口大小达到门限值。在达到门限值后,拥塞避免(加法增大)过程使用窗口大小按线性规律增长,直至出现了超时现象或者达到了最大窗口大小。在图中,窗口大小达到20时发生了超时现象。此时,乘法减小过程开始生效,并把门限值减小到窗口大小的一半。因为超时发生时,窗口大小是20,所以新的门限现在是10.

 

        TCP重新进入满开始,并从窗口值为1开始,到达新的门限值时变为加法增大。当窗口值为12时,三个重复的ACK时间发生了。现在又转为乘法减小过程。门限值和窗口大小设置为6,这一次TCP进入加法增大阶段。TCP一直停留在这个阶段,直至发生另一个超时时间或3个重复的ACK事件。

 

 

 

最长报文大小 MSS(Maximum Segment Size)

Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=326391518&siteId=291194637