TCP中ECN的工作原理分析二(摘自:RFC3168)

英文源:http://www.icir.org/floyd/ecn.html

发送端和接收端处理:

The TCP Sender

For a TCP connection using ECN, new data packets are transmitted with    an ECT codepoint set in the IP header.  When only one ECT codepoint    is needed by a sender for all packets sent on a TCP connection,    ECT(0) SHOULD be used.  If the sender receives an ECN-Echo (ECE) ACK    packet (that is, an ACK packet with the ECN-Echo flag set in the TCP    header), then the sender knows that congestion was encountered in the    network on the path from the sender to the receiver.  The indication    of congestion should be treated just as a congestion loss in non-    ECN-Capable TCP. That is, the TCP source halves the congestion window    "cwnd" and reduces the slow start threshold "ssthresh".  The sending    TCP SHOULD NOT increase the congestion window in response to the    receipt of an ECN-Echo ACK packet.

对于使用ECN的TCP连接,需要在数据包的IP包头上设置ECT位。当TCP连接中发送端发送的数据包

仅需要一个ECT位时,应该使用ECT(0)。如果发送端接收到了一个带有ECE的ACK包(也就是说,这

个ACK包带有设置在TCP头上的ECE标记),那么发送端就知道该包在网络中从发送端到接收端的途中

经历了拥塞。此拥塞指示应该被看作和没有启用ECN的TCP的拥塞丢包是一个意思。也就是说,TCP发

送端应该减半发送窗口和降低慢启动阈值。即发送端对接收端返回的带有ECE位的ACK包的相应不应该是

增加发送窗口。

TCP should not react to congestion indications more than once every    window of data (or more loosely, more than once every round-trip    time). That is, the TCP sender's congestion window should be reduced    only once in response to a series of dropped and/or CE packets from a    single window of data.  In addition, the TCP source should not    decrease the slow-start threshold, ssthresh, if it has been decreased    within the last round trip time.  However, if any retransmitted    packets are dropped, then this is interpreted by the source TCP as a    new instance of congestion.

同时,TCP也不应该在一个数据往返时间的窗口内对拥塞指示做出多余一次的响应(或者更多的丢包,

每个往返时延多余一次)。也就是说,对于一系列的丢包或ACK包的ECE指示,在一个往返时延内,TCP

发送端拥塞窗口应该只降低一次。除此之外,如果阈值在上一个往返时延内已经被减少,这次就不应该再

降低慢启动阈值。然而,如果出现任何重传的包丢失,TCP发送端就可以把它作为拥塞指示做出响应。

After the source TCP reduces its congestion window in response to a    CE packet, incoming acknowledgments that continue to arrive can    "clock out" outgoing packets as allowed by the reduced congestion    window.  If the congestion window consists of only one MSS (maximum    segment size), and the sending TCP receives an ECN-Echo ACK packet,    then the sending TCP should in principle still reduce its congestion    window in half. However, the value of the congestion window is    bounded below by a value of one MSS.  If the sending TCP were to    continue to send, using a congestion window of 1 MSS, this results in    the transmission of one packet per round-trip time.  It is necessary    to still reduce the sending rate of the TCP sender even further, on    receipt of an ECN-Echo packet when the congestion window is one.  We    use the retransmit timer as a means of reducing the rate further in    this circumstance.  Therefore, the sending TCP MUST reset the    retransmit timer on receiving the ECN-Echo packet when the congestion    window is one.  The sending TCP will then be able to send a new    packet only when the retransmit timer expires.

源端TCP作为对ECE位的ACK包做出减少窗口的响应后,已经减少的发送窗口把后续即将到来的ACK包看作是“下班”的包(无效指示)(?)如果拥塞窗口仅是一个MSS大小(最大报文段字节数),发送端接收到一个带有ECE位的ACK包,那么,原则上来说,源端TCP仍然应该减少发送窗口。但是发送窗口的值已经到达了最少一个MSS的下限。如果发送端想要用一个报文段大小的窗口继续发送数据,就会导致每个RTT仅传送一个包。但拥塞窗口是一个MSS且受到来自接收端返回的带有ECE位的ACK后,TCP发送端甚至需要进一步减少发送速率。在这种情况下,我们用重传定时器作为一个进一步减少发送速率的方式。因此,但拥塞窗口是1个MSS且又收到ECE位的ACK时,发送端TCP必须复位重传定时器。如此,只有重传定时器超时时TCP才能发送一个新的数据包。

上一篇:java的八大排序


下一篇:关于使用 no-js (Modernizr)