@@ -307,30 +307,100 @@ corruption. When receiver notices corrupted packet from invalid checksum, it
307307will ignore the packet. When data sender notices that packet is lost, it reacts
308308to it as congestion event and reduces transmission rate.
309309
310- Explicit congestion notification (ECN, [ RFC
311- 3168] ( https://datatracker.ietf.org/doc/html/rfc3168 ) ) was introduced as a
312- mechanism for network routers to signal that they are congested before dropping
313- packets. When connection is opened, the transport protocol (e.g. TCP) client
314- checks if the other end of the connection supports ECN by using a couple of bits
315- in transport header. When sending packets, it also marks a bit in IP header to
316- indicate the the current connection is capable of using ECN. When active queue
317- management algorithm at router wants to signal congestion, it marks another bit
318- in the IP header. Receiver transport protocol echoes the status of this bit back
319- to sender with the acknowledgment of the packet, after which the sender should
320- reduce the transmission rate similarly than it would react to packet loss.
321- Therefore ECN can help to avoid many of the congestion-related packet losses.
310+ ** Explicit congestion notification (ECN, [ RFC
311+ 3168] ( https://datatracker.ietf.org/doc/html/rfc3168 ) )** was introduced as a
312+ mechanism for network routers to signal that they are congested without having
313+ to drop packets. Therefore ECN should be used together with one of the active
314+ queue management algorithms discussed above. ECN uses two bits in the IP header
315+ and two bits in the TCP header for its signaling.
316+
317+ If a sender supports ECN, it marks a ** "ECN-capable transport (ECT)"** bit in
318+ the IP header for all outgoing packets, to indicate the routers on the path that
319+ ECN is available for this data flow. If this bit is enabled, and router is
320+ congested, it sets another ** "congestion experienced (CE)"** bit in the IP
321+ header to tell this. If the ECT bit was not set on IP header, the router behaves
322+ in the traditional way, dropping the IP packet entirely. Because ECN helps to
323+ avoid packet losses due to congestion, data senders have incentive to use ECN if
324+ the implementation supports it.
325+
326+ Because the congestion window and sending rate is managed at the sending end of
327+ the transfer, the received needs to echo the congestion information back, when
328+ it receives a packet with ** CE bit** on. This happens inside the TCP header
329+ (because routers do not need to see this information), using a ** "ECN-Echo
330+ (ECE)"** bit in TCP acknowledgment header. When the TCP receivers this
331+ acknowledgment, it knows to reduce the sending rate and congestion window, even
332+ if no packet loss is detected. Because it is important that sender actually
333+ receives the congestion information, but it is possible that also acknowledgment
334+ packets are lost in the network, the ** ECE** bit is applied in all subsequent
335+ acknowledgments, until the TCP receiver gets a TCP header with "** Congestion
336+ Window Reduced (CWR)** " bit on. Using this the TCP sender tells that it has
337+ received the ECE bit, and has reduced congestion window. After this the receiver
338+ can stop sending ** ECE** bits, until another congestion indication comes. This
339+ resembles the three-way handshake in the beginning of TCP connection. From this
340+ we can notice that the basic TCP can deliver only one congestion indication per
341+ round-trip time. This is also the case with loss-based congestion control.
342+
343+ The below diagram illustrates the packet sequence when congestion is noticed at
344+ a router (at red "X").
345+
346+ ![ ECN operation] ( /images/cc-ecn.svg ) {: width="90%" .center-img }
347+
348+ In the beginning of the connection, during TCP connection establishment
349+ handshake, the TCP sender must verify if the receiver also supports ECN. If it
350+ is not able to echo the congestion information back, ECN cannot be used. This is
351+ done by setting the TCP-layer ECN bits on. The receiver echoes back the ** ECE**
352+ bit, if it is capable of using ECN, and ECN can be used for this connection.
353+
354+ ### Setting up ECN in Linux
355+
356+ Linux supports ECN both at TCP layer and on IP packet forwarding. By default
357+ Linux works in a "passive mode": ECN is enabled only when incoming connection
358+ indicates in TCP handshake that it wants to use ECN, by having the ECN bits set.
359+ In other words, by default a Linux client that opens the connection does not use
360+ ECN. This choice was made after it was observed that there are (outdated and
361+ old) routers in the Internet that cannot handle packets with ECN bit properly,
362+ and in worse case drop them. This is, of course, unfortunate considering the
363+ wider deployment of the ECN protocol.
364+
365+ Linux uses ** sysctl** parameters to control various aspects in kernel behavior.
366+ For example, for the networking operations alone, there are tens of parameters
367+ than can be used to tune TCP and IP behavior. One of the parameters is
368+ ` net.ipv4.tcp_ecn ` that tells whether ECN should be used with TCP. You can query
369+ the current value by:
370+
371+ sysctl net.ipv4.tcp_ecn
372+
373+ This likely returns value 2, which stands for the passive mode ECN described
374+ above. ECN can be enabled in all connections, in active mode, by setting this
375+ parameter to 1:
376+
377+ sudo sysctl -w net.ipv4.tcp_ecn=1
378+
379+ By default many Linux systems apply FQ-CoDel forwarding, with ECN enabled, as we
380+ could see in the Traffic Control ` qdisc ` example in the above FQ-CoDel section:
381+ "` ecn ` " in the tc output tells that ECN is enabled in packet forwarding. If this
382+ was not the case, it could be enabled, for example by:
383+
384+ sudo tc qdisc replace dev eth0 root fq_codel ecn
385+
386+ Replacing the interface name with actual interface.
387+
388+ In Mininet, assuming our ** aalto/simple_topo.py** , ECN can be enabled using the
389+ ` --ecn ` command line option. Note that after this, you'll need to enable the ECN
390+ separately in the Mininet virtual hosts using the above sysctl in each of the
391+ ones you are using to start TCP connections.
322392
323393## Classes of Modern congestion control
324394
325395For decades TCP congestion control was based on window-based algorithm, quite
326- often Reno or NewReno, and it is still typically what is taught on the basic
327- networking course books. The classical algorithm has been successful, because it
328- is simple and easy to understand for anyone new to computer networks: if there
329- are no packet losses, TCP congestion window is increased at steady pace, but
330- reaction to congestion is stronger: the congestion window is reduced to half on
331- detected packet loss, or in some cases initialized to one, if there is a
332- retransmission timeout. This kind of algorithms have been called Additive
333- Increase, Multiplicative Decrease (AIMD) algorithms.
396+ often Reno ( or NewReno) or Tahoe algorithms , and it is still typically what is
397+ taught on the basic networking course books. The classical algorithm has been
398+ successful, because it is simple and easy to understand for anyone new to
399+ computer networks: if there are no packet losses, TCP congestion window is
400+ increased at steady pace, but reaction to congestion is stronger: the congestion
401+ window is reduced to half on detected packet loss, or in some cases initialized
402+ to one, if there is a retransmission timeout. This kind of algorithms have been
403+ called Additive Increase, Multiplicative Decrease (AIMD) algorithms.
334404
335405The loss based AIMD-algorithms are not ideal: they are reactive and take action
336406when congestion has already caused problems. The active queue management
0 commit comments