Re: [tcpm] Case for ECN-capable TCP control packets: draft-bagnulo-tsvwg-generalized-ecn

[Praveen Balasubramanian <[e-mail]>]

This is certainly interesting work and very relevant.

Marking ECT on SYN makes sense and data shows that for schemes like DCTCP, not marking SYN puts new flows establishment at a disadvantage especially when schemes like Dual Q AQM are in play. FIN occupies a byte in sequence number space so marking ECT on packet with FIN (with or without data) seems reasonable. Marking RST is probably harmless. I don’t have a strong opinion about window probes and retransmissions but the consistency argument should hold unless there is a demonstrable DoS attack.

My main concern is with pure ACKs. If the receiver is a dumb reflector by sending ECE upon receiving any control packet marked with CE then it could interfere with “accurate ECN” like schemes. For example if the application has bi-directional traffic then how would the sender distinguish a ECE was in response to a mark on a data packet versus an ACK packet? I am of the opinion that the receiver should not echo ECN marks on pure ACK packets. Any other ideas?

I think bringing this up for discussion in working group would be very valuable.

Thanks

From: tcpm [mailto:[e-mail]] On Behalf Of Bob Briscoe
Sent: Friday, July 15, 2016 11:31 AM
To: Black, David <[e-mail]>; tsvwg IETF list <[e-mail]>; tcpm IETF list <[e-mail]>
Cc: [e-mail]
Subject: [tcpm] Case for ECN-capable TCP control packets: draft-bagnulo-tsvwg-generalized-ecn

David, [re-sending to include tsvwg & tcpm, which is what I had intended to do first time.]

Here's a heads-up for tsvwg, plus cross-posting to tcpm as suggested,
And for a fast read, there's a summary of every argument below.
Pls bash the arguments.

Summary:
The ECN spec [RFC 3168] says various TCP control packets must not be ECN capable.
This draft lays out each argument given in the RFCs, and articulates a rebuttal against each one:
draft-bagnulo-tsvwg-generalized-ecn<https://tools.ietf.org/html/draft-bagnulo-tsvwg-generalized-ecn>
Subject to some more experiments, we think this knocks down every reason given, so that all these packets could safely be ECN-capable.

Pls read the draft for more details (preferably before responding).

Enumeration of arguments about each type of control packet follows, starting with some arguments common to many:
___________________________________________________________________________________________

Common arguments against ECT

  1.  Unreliable congestion notification delivery
  2.  DoS Attacks
Common rebuttals (respectively):

  1.  No worse than undetectable loss of Not-ECT control packet, and better performance
  2.  Mandating Not-ECT does not stop attackers using ECT for flooding. Nonetheless, it would allow firewalls to discard control packets not meant to be ECT., however this would negate the benefit of ECT for compliant transports and seems unnecessary for the following reason.
RFC3168 (Sec.7) and RFC7567 (Sec.4.2.1) say an AQM MUST turn off ECN support if under persistent overload. This makes it hard for flooding packets to gain from ECT, but more experiments needed to see how much might be gained by an attacker flying "just under the radar".

SYN/ACK
ECT on SYN/ACK already justified in RFC5562

SYN
Arguments against ECT:

  1.  Unknown ECN capability at the responder (may discard ECT SYN or RST connection)
  2.  Loss of congestion notification due to lack of support for feeding back CE on SYN at the responder.
  3.  DoS attacks.
Rebuttals (respectively):

  1.  No RFC mandates these responder behaviours, but 0.6% - 0.8% of Alexa top 1M Web sites (or their network paths) exhibit this. Could retransmit the SYN without ECT, and cache this knowledge to avoid 1 RTT delay in future
  2.  Support for CE feedback in SYN needed in the TCP wire protocol. Solution proposed in AccECN<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn> draft: if SYN/ACK shows lack of support for feeding back CE on SYN (i.e. no support for AccECN) IW MUST be reduced conservatively as if CE on SYN (no need to be as conservative as drop of SYN - cannot be severe congestion as packet got through). Could cache this knowledge.
  3.  See common DoS Attack rebuttal

Pure ACK
Arguments against ECT:

  1.  Unreliable congestion notification delivery
  2.  No means to feed back congestion notifications (no ACKs of ACKs)
Rebuttals (respectively):

  1.  See common unreliability rebuttal
  2.  No worse than drop of Pure ACK, and better performance

Retransmission
Arguments against ECT:

  1.  Unreliable congestion notification delivery
  2.  DoS attacks
  3.  Over-reacting to congestion.
Rebuttals (respectively):

  1.  See common unreliability rebuttal
  2.  See common DoS Attack rebuttal, complemented by recommendation to ignore CE on out of window packets
  3.  Correct to react twice to congestion in different RTTs

Window Probe

Arguments against ECT:

  1.  Unreliable congestion notification delivery
Rebuttal:

  1.  See common unreliability rebuttal
FIN

No arguments against using ECT in RFCs.
To be discussed in next rev of draft.

RST

No arguments against using ECT in RFCs
To be discussed in next rev of draft.

Cheers


Bob & Marcelo

On 11/07/16 21:28, Black, David wrote:

Marcelo and Bob,



Interesting draft - I need to read it in more detail ... in my "copious spare time" this week ;-).



While it is of interest to TSVWG, as general ECN work happens here, I suspect

that as a proposed modification to TCP it would be in the domain of the TCPM WG,

as was the case for RFC 5562.



Thanks, --David

----------------------------------------------------

David L. Black, Distinguished Engineer

EMC, 176 South St., Hopkinton, MA  01748

[phone]     Cell: [phone]

[e-mail]<mailto:[e-mail]>

---------------------------------------------------



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/