Skip to content

Week 2 Synopsis

Jump to bottom
chennakeshava1998 edited this page Oct 10, 2018 · 20 revisions

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)

Doubts:

  1. What are the reasons TCP packets can be dropped? Is it only congestion??
  2. Does ECN help with reducing the unfairness caused by packet drop with the previous congestion control mechanism?? How?
  3. Why wasn't the previous workflow of the responder setting Congestion Window = 1 sufficient? Justification for this new behaviour by the TCP responder?
Clone this wiki locally