Skip to content

Week 2 Synopsis

Jump to bottom
Rithesh17 edited this page Oct 12, 2018 · 20 revisions

Addition of ECN codepoints to IP: [RFC 3168]

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.

Active queue management 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.

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.

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