Skip to content

Week 2 Synopsis

Jump to bottom
H.L Praveen Raj edited this page Oct 13, 2018 · 20 revisions

This page summarises our work in week 2. It also provides a synopsis of the works done.

Addition of ECN codepoints to IP: [RFC 3168]

Congestion control mechanisms pre-ECN

Traditionally, TCP uses packet drops as an indication of congestion. TCP’s congestion control and avoidance algorithms are based on the notion that the network is a black-box. The network’s state of congestion or otherwise is determined by end systems probing for the network state, by gradually increasing the load on the network (by increasing the window of packets that are outstanding in the network) until the network becomes congested and a packet is lost. This causes the queues at the bottleneck router to build up. With most packet drop policies at the router that are not sensitive to the load placed by each individual flow, this means that some of the packets of latency-sensitive flows may be dropped. In addition, such drop policies lead to synchronization of loss across multiple flows.

AQM

Active queue management (AQM) mechanisms detect congestion before the queue overflows, and provide an indication of this congestion to the end nodes. Thus, active queue management can reduce unnecessary queuing delay for all traffic sharing that queue. It also means that, transport protocols with mechanisms for congestion control (e.g., TCP) do not have to rely on buffer overflow as the only indication of congestion.

But it is important to note that, in the absence of ECN, AQM is restricted to using packet drops as a mechanism for congestion indication.

Thus, AQM can set a Congestion Experienced (CE) codepoint in the packet header instead of dropping the packet, when such a field is provided in the IP header and understood by the transport protocol. The use of the CE codepoint with ECN allows the receiver(s) to receive the packet, avoiding the potential for excessive delays due to retransmissions after packet losses.

ECN at IP level

The following are the different codepoints ECN provides:

+-----+-----+
| ECN FIELD |
+-----+-----+
  ECT   CE        [Obsolete] RFC 2481 names for the ECN bits. 
  0     0         Not-ECT
  0     1         ECT(1)         
  1     0         ECT(0)         
  1     1         CE

Bits 6 and 7 in the IPv4 TOS octet are designated as the ECN field.

ECN mandates that, upon the receipt by an ECN-Capable transport of a single CE packet, the congestion control algorithms followed at the end-systems must be essentially the same as the congestion control response to a single dropped packet. One reason for this is to accommodate the incremental deployment of ECN in both end systems and in routers. An additional goal is that the end-systems should react to congestion at most once per window of data, to avoid reacting multiple times to multiple indications of congestion within a round-trip time.

At a router, the CE codepoint of an ECN-Capable packet should only be set if the router would otherwise have dropped the packet as an indication of congestion to the end nodes.

When a CE packet (i.e., a packet that has the CE codepoint set) is received by a router, the CE codepoint is left unchanged, and the packet is transmitted as usual.

ECN at TCP level

The TCP mechanism for negotiating ECN-Capability uses the ECN-Echo (ECE) flag in the TCP header. Bit 9 in the Reserved field of the TCP header is designated as the ECN-Echo flag.

To enable the TCP receiver to determine when to stop setting the ECN-Echo flag, there is a second new flag in the TCP header, the CWR flag. The CWR flag is assigned to Bit 8 in the Reserved field of the TCP header.

For a TCP connection, a typical sequence of events in an ECN-based reaction to congestion is as follows:

  • An ECT codepoint is set in packets transmitted by the sender to indicate that ECN is supported by the transport entities for these packets.
  • An ECN-capable router detects impending congestion and detects that an ECT codepoint is set in the packet it is about to drop. Instead of dropping the packet, the router chooses to set the CE codepoint in the IP header and forwards the packet.
  • The receiver receives the packet with the CE codepoint set, and sets the ECN-Echo flag in its next TCP ACK sent to the sender.
  • The sender receives the TCP ACK with ECN-Echo set, and reacts to the congestion as if a packet had been dropped.
  • The sender sets the CWR flag in the TCP header of the next packet sent to the receiver to acknowledge its receipt of and reaction to the ECN-Echo flag.

In the TCP connection setup phase, the source and destination TCPs exchange information about their willingness to use ECN. Subsequent to the completion of this negotiation, the TCP sender sets an ECT codepoint in the IP header of data packets to indicate to the network that the transport is capable and willing to participate in ECN for this packet.

A receiver will respond to incoming data packets that have the CE codepoint set in the IP header by setting ECE in outgoing TCP Acknowledgement (ACK) packets. And a sender will respond to incoming packets that have ECE set by reducing the congestion window and setting CWR when appropriate.

It is very important to note that, the rules for ECN initiation and usage forbid the hosts from setting ECN bits in IP as an implicit signal that the other host ECN-capable.

Certain implementation details mandated by RFC 3168

According to [RFC 3168], a host must not set ECT on SYN or SYN-ACK packets. It also says that TCP should not react to congestion indications more than once every window of data.

[RFC 3168] says that, ECN-capable TCP implementations must not set either ECT codepoint (ECT(0) or ECT(1)) in the IP header for retransmitted data packets, and that the TCP data receiver should ignore the ECN field on arriving data packets that are outside of the receiver’s current window. The reasons for this are:

  • If the TCP sender were to set an ECT codepoint on a retransmitted packet, then if an unnecessarily-retransmitted packet was later dropped in the network, the end nodes would never receive the indication of congestion from the router setting the CE codepoint Thus, setting an ECT codepoint on retransmitted data packets is not consistent with the robust delivery of the congestion indication even for packets that are later dropped in the network.
  • To protect against an attacker capable of spoofing the IP source address of the TCP sender could send data packets with arbitrary sequence numbers, with the CE codepoint set in the IP header. More info on this is in section 6.1.5 in [RFC 3168].

Advantages of ECN

  • Avoid unnecessary packet drops for short or delay-sensitive TCP connections.
  • Avoiding some unnecessary retransmit timeouts in TCP.

Disadvantages of ECN

  • A non-compliant TCP connection could falsely advertise itself as ECN-capable.
  • A TCP ACK packet carrying an ECN-Echo message could itself be dropped in the network. This issue is is addressed by the addition of the CWR flag in the TCP header.

Doubts

  1. How is the interface between the IP and TCP designed for the ECN to work?

    Ans: An implementation of ECN in NS-3 can be found here and a implementation plan is found here. We can alo go through the Linux implementation of ECN.

  2. What is the necessity for two different ECT codepoints?

    Ans: As mentioned in Section 20.2 in the same RFC (RFC 3168) "The primary motivation for the two ECT codepoints is to provide a one-bit ECN nonce". (A nonce is something used only for an occasion). It "allows the development of mechanisms for the sender to probabilistically verify that network elements are not erasing the CE codepoint"

    For example, consider the scenario where a router could make some changes in the ECN bits that would result in effectively erasing the congestion indication after it had been set by a router upstream. It can do so by replacing the CE codepoint with ECT(0) or ECT(1) codepoints. But with the use of two ECT codepoints a router erasing the CE codepoint has no way to know whether the original ECT codepoint was ECT(0) or ECT(1). Hence with a probability of 0.5 we can detect such erasures of the CE codepoint.

    The other (minor) reasons for the use of two ECT codepoints, along with some of the alternate possibilities for the fourth ECT codepoint, is mentioned in Section 20.2

Using ECN codepoints in SYN/ACK packets: [RFC 5562]

  • When the router detects congestion before buffer overflow, the router can provide a congestion indication either by dropping a packet or by setting the Congestion Experienced (CE) codepoint in the Explicit Congestion Notification (ECN) field in the IP header [RFC3168].

  • RFC 3168 [RFC3168] does not specify the use of ECN for the first SYN/ACK packet itself. However, because of the high cost to the TCP transfer of having a SYN/ACK packet dropped, with the resulting retransmission timeout, rfc5562 specifies the use of ECN for the SYN/ACK packet itself.

  • Initiator: The node which initiates the TCP connection establishment. Responder: The node which sends the SYN/ACK packet.

IMP: Figures 1, 2 and 3 in RFC 5562

  • A TCP node may respond to an initial ECN-setup SYN packet by setting ECT in the responding ECN-setup SYN/ACK packet, indicating to routers that the SYN/ACK packet is ECN-Capable.

  • This allows a congested router along the path to mark the packet instead of dropping the packet as an indication of congestion.

  • Case 1: If a SYN/ACK packet with the ECT codepoint is dropped, the responder should resend the SYN/ACK packet without the ECN-Capable codepoint. (responder uses a 3 second retransmission timer) (Check Figure 1)

  • Case 2: if the TCP responder is informed that the SYN/ACK was ECN-marked, the TCP responder immediately sends a SYN/ACK packet that is not ECN-Capable. The TCP responder is only allowed to send data packets after the TCP initiator reports the receipt of a SYN/ACK packet that is not ECN- marked. (Check Figure 2)

  • According to RFC 3168, in response to an ECN-Echo packet, the TCP responder also sets the CWR flag in the TCP header of the next data packet sent, to acknowledge its receipt of and reaction to the ECN-Echo flag.

  • In response to an ECN-Echo packet acknowledging the receipt of an ECN- Capable SYN/ACK packet, the TCP responder doesn’t set the CWR flag, but simply sends a SYN/ACK packet that is not ECN-Capable.

  • On receiving the non-ECN-Capable SYN/ACK packet, the TCP initiator clears the ECN-Echo flag on replying packets.

  • Case 3: The TCP responder sets a timer once it sends the SYN/ACK packet(in both cases, irrespective of whether the received ECN-Echo was marked as CE by the intermediate routers)

  • Suppose the responder has sent an SYN/ACK without ECT, and Congestion-Window = 1 (as explained in Case-2), and if the timer expires before the TCP responder receives an acknowledgement for the other end, the TCP responder resends the previously sent SYN/ACK packet (Check Figure 3)

Discussion:

Flooding Attack: the addition of ECN-Capability to SYN/ACK packets could allow SYN/ACK packets to persist for more hops along a network path before being dropped, thus adding somewhat to the ability of a SYN/ACK attack to flood a network link.

  • SYN/ACK Flood attacks or trying to congest a specific link is not possible.

Why should we not use ECN in the TCP SYN packet:

  1. There is no guarentee that the other end of the connection is ECN-enabled.
  2. If there is a malicious host at the other end of connection, this information could be used for improving the TCP SYN attack ie if CE is set by a router in the TCP SYN packet, we can purposely flood the network path by congesting the router/routers even more.

TODO: section 4.3 and 4.4

Doubts:

  1. What are the reasons TCP packets can be dropped? Is it only congestion??

    Ans: This article provides a very good answer to this question.

  2. Does ECN help with reducing the unfairness caused by packet drop with the previous congestion control mechanism?? How?

    Ans: ECN is deployed incrementally on the routers hence is backward compatible with previous congestion notification mechanisms. ECN also mandates that the response to a CE notification should be same as that for a packet drop due to congestion.

  3. Why wasn't the previous workflow of the responder setting Congestion Window = 1 sufficient? Justification for this new behaviour by the TCP responder?

  4. In Section-4 (Discussion) paragraph-2, it is said that "Congestion is most likely to occur in the server-to-client direction." Why is this true? Empirical studies?

    Ans: RFC 5562 is written keeping the conventional client-server communication in mind. And in most of the client-server communication, the data transfer from the server to the client (i.e., the downstream data w.r.t the client) is much higher than the data transfer from the client to the server (i.e., the upstream data w.r.t the client). And since this inequality of data transfer is dominant in the Internet, congestion is most likely to occur during server-to-client communication. This is also the reason for the unequal bandwidth distribution for upstream and downstream data transfer.

    This will be reversed in out situation. The data transfer from client side is usually much higher than the data from the server end.

Clone this wiki locally