Subject: [quicwg/base-drafts] In an unlikely event of emergency.... set ECN marks (#3454)

From: mirjak <[email-masked]>
Date: Thu, 13 Feb 2020 07:03:03 -0800

This is an editorial change marking clear that ECN-based black-holing is rather unlikely today.
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3454

-- Commit Summary --

  * In an unlikely event of emergency.... set ECN marks

-- File Changes --

    M draft-ietf-quic-transport.md (11)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3454.patch
https://github.com/quicwg/base-drafts/pull/3454.diff

-- 
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/3454

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Feb 2020 15:51:29 -0800

martinthomson approved this pull request.

I think that this is OK.  I don't know why CI is complaining; I can sort that out though.

> @@ -3485,10 +3485,13 @@ packets on a new path to a peer:
 * If all packets that were sent with the ECT(0) codepoint are eventually deemed
   lost {{QUIC-RECOVERY}}, validation is deemed to have failed.
 
-To reduce the chances of misinterpreting congestive loss as packets dropped by a
-faulty network element, an endpoint could set the ECT(0) codepoint in the first
-ten outgoing packets on a path, or for a period of three RTTs, whichever occurs
-first.
+During the initial deployment of ECN an implementation bug was observed that
+led to black-holing of ECN-marked packet (mostly in home router equipment).
+While this case if unlikely in the Internet today, if this is as a concern for

```suggestion
While this case is unlikely in the Internet today, if this is as a concern for
```

Did you want to cite the study paper here to support this statement?

> @@ -3485,10 +3485,13 @@ packets on a new path to a peer:
 * If all packets that were sent with the ECT(0) codepoint are eventually deemed
   lost {{QUIC-RECOVERY}}, validation is deemed to have failed.
 
-To reduce the chances of misinterpreting congestive loss as packets dropped by a
-faulty network element, an endpoint could set the ECT(0) codepoint in the first
-ten outgoing packets on a path, or for a period of three RTTs, whichever occurs
-first.
+During the initial deployment of ECN an implementation bug was observed that
+led to black-holing of ECN-marked packet (mostly in home router equipment).
+While this case if unlikely in the Internet today, if this is as a concern for
+a certain network, an endpoint could set the ECT(0) codepoint only in, e.g., the

I would strike "for a certain network" here.

-- 
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/3454#pullrequestreview-358632715

---

From: mirjak <[email-masked]>
Date: Fri, 14 Feb 2020 02:48:38 -0800

@mirjak pushed 1 commit.

c1aa5d318ad7e895e41bcf868b4d7f413781b3f3  Update draft-ietf-quic-transport.md

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3454/files/06b3403f17f50cc01d8018e33c8b0a560e4458ed..c1aa5d318ad7e895e41bcf868b4d7f413781b3f3

---

From: mirjak <[email-masked]>
Date: Fri, 14 Feb 2020 02:50:53 -0800

I though giving a paper reference is not necessarily needed. The latest measurement we did and published is from 2017 in this paper (table 1):

https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/317151/tma-traceroute.pdf

-- 
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/3454#issuecomment-586208105

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 25 Feb 2020 15:24:48 -0800

janaiyengar commented on this pull request.

I would prefer to keep the original text. We could perhaps add a sentence at the top of the paragraph, saying something like this: "It is expected to be rare that a faulty network element drops packets carrying ECT(0) or ECT(1) codepoints. However, to reduce the chances of ..."

-- 
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/3454#pullrequestreview-364523689

---

From: mirjak <[email-masked]>
Date: Wed, 26 Feb 2020 02:50:54 -0800

I think that is not strong enough. I think "unlikely" is a bit stronger but I also think you need to provide some reasoning why this case is discussed as all (if it is unlikely). I would really like people to understand the situation rather than indicate to implement something complicated that is probably not needed which might cause some people not implement ECN support 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/3454#issuecomment-591364026