Subject: Re: [quicwg/base-drafts] Consequences of bad ECN markings (#1626)

From: ianswett <[email-masked]>
Date: Wed, 01 Aug 2018 09:04:36 -0700

ianswett approved this pull request.

I'm not sure I'd call this a 'security' consideration, but it's a consideration of some sort, so it's likely better in this section than elsewhere.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1626#pullrequestreview-142449129

---

From: mirjak <[email-masked]>
Date: Wed, 01 Aug 2018 16:15:11 +0000 (UTC)

mirjak commented on this pull request.

> +peer.  Suppressing reports of ECN-CE markings could cause a peer to increase
+their send rate.  This increase could result in congestion and loss.
+
+An endpoint MAY attempt to detect suppression of reports by marking occasional
+packets that they send with ECN-CE.  If a packet marked with ECN-CE is not
+reported as having been marked when the packet is acknowledged, the endpoint
+SHOULD then disable ECN for that path.
+
+Reporting additional ECN-CE markings will cause a peer to reduce their sending
+rate, which is similar in effect to advertising reduced connection flow control
+limits and so no advantage is gained by doing so.
+
+Endpoints choose the congestion controller that they use.  Though congestion
+controllers ideally use reports of ECN markings as input, the exact response for
+each controller could be different.  Failure to correctly respond to information
+about ECN markings is therefore difficult to detect.

Actually this is a bit weak. RFC3168 say
"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."
(where RFC8311 adds a
"unless otherwise specified by an Experimental RFC in the IETF document stream"
to this last sentence, however, this is not really important here).

The text as currently written indicates that the congestion controller can choose to account for ECN information at all or not which is not the case.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1626#pullrequestreview-142453295

---

From: ianswett <[email-masked]>
Date: Wed, 01 Aug 2018 09:23:40 -0700

ianswett commented on this pull request.

Clearly there are congestion controllers which don't support ECN, particularly not 3168 style ECN.

As an example, DCTCP (RFC8257) specifies a mechanism which is different from 3168.

Maybe we don't need this paragraph at all?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1626#discussion_r206945335

---

From: mirjak <[email-masked]>
Date: Wed, 01 Aug 2018 09:46:17 -0700

DCTCP is not applicable to the Internet. The point being is that if you mark your packets as ECN-enabled, you also must react to CE marks accordingly, you can't just ignore them. I guess we can remove the whole paragraph or just this one sentence in the middle.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1626#discussion_r206952526

---

From: Christian Huitema <[email-masked]>
Date: Wed, 01 Aug 2018 11:30:08 -0700

huitema commented on this pull request.

RFC3168 does say that the response to an ECN mark must be the same as to a dropped packet. However, different congestion control algorithms may well respond to dropped packets differently. Receivers may detect that the sender's algorithm does not respond as TCP-Reno would, but then so what? It just means that the sender's congestion control algorithm is different from TCP-Reno.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1626#discussion_r206985670

---

From: Martin Thomson <[email-masked]>
Date: Wed, 01 Aug 2018 17:05:17 -0700

martinthomson commented on this pull request.

Would this be better if it said "Though congestion controllers generally treat reports of ECN-CE markings as equivalent to loss [RFC8311], the exact response for each controller could be different." ?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1626#discussion_r207068135

---

From: mirjak <[email-masked]>
Date: Thu, 02 Aug 2018 02:06:32 -0700

WFM.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1626#discussion_r207153062

---

From: Martin Thomson <[email-masked]>
Date: Sun, 05 Aug 2018 22:48:02 -0700

@ianswett I think that this is ready.  It's all yours now.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1626#issuecomment-410595673

---

From: Martin Thomson <[email-masked]>
Date: Sun, 05 Aug 2018 22:48:03 -0700

@martinthomson pushed 1 commit.

716f89e  Agreed changes to ECN response text

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1626/files/598dd853b4dca63e3334cddd66c2dc358e96f4ff..716f89ee822cc057eb36262d256977a8755118f6

---

From: ianswett <[email-masked]>
Date: Mon, 06 Aug 2018 05:57:11 -0700

Merged #1626 into master.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1626#event-1772818600