Re-ECN and the ECN Nonce

Documents:

• ECN: , September 2001.
• The ECN Nonce: RFC 3540, June 2003.
• Re-ECN: draft-briscoe-tsvwg-re-ecn-tcp-02.txt, June 2006.
• History of the ECN Nonce in RFC 3168:
  The ECN Nonce codepoints ECT(0) and ECT(1) were added to RFC 3168 in early 2001 as part of a Last Call requirement from the IESG, replacing a single codepoint for ECT.

Sender protection against misbehaving receivers:

• General environments.
  • The ECN Nonce is used by the transport sender to protect against receivers who lie about whether a packet was dropped or ECN-marked. No cooperation is needed from routers. Cooperation is needed from the transport receiver, for the sender to verify that the receiver is correctly reporting losses. For DCCP, all receivers must be ECN-Capable. Tor TCP, the sender can't tell if the receiver is uncooperative or just not ECN-capable. In either case, in times of congestion the sender could give preferential service to receivers that use ECN.
  • Re-ECN is used to protect network-layer resources.
• Paths without a pair of re-ECN policers.
• Paths where the congested link is one of the two access links to the end host.
• Short flows.

Possible Use Cases for Re-ECN, but not for the ECN Nonce:

• Misbehaving senders.
• SYN flooding?
• SMURF?
• UDP flooding?
• Reflection DoS?
• DNS flooding?
• ACK flooding?
• Frag attacks?