Subject: [quicwg/base-drafts] ECN not required (#2156)

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 12:56:35 -0800

The current text in S 13.3.2 and other places implies that if my
endpoint can access ECN information, it is required to do so and
use ACK ECN. This doesn't match my memory of the consensus, which
was that ECN support was strictly optional. If people think there
was consensus to the contrary, I'd appreciate a pointer. Otherwise
this should be changed. I can supply a PR on request.

-- 
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/issues/2156

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 16:35:31 -0800

The text matches my understanding of consensus.  I guess that you can't access the markings if can't be bothered to write the code to access the markings.

-- 
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/issues/2156#issuecomment-447171932

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 16:54:01 -0800

That seems like spec lawyering, when we have an opportunity to make this clear.

Suppose that I am on a platform which supports ECN, but I just choose not to do anything with it. Do you believe I am compliant with this document or not?

-- 
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/issues/2156#issuecomment-447175179

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Dec 2018 17:33:04 -0800

No.  But I believe that we had consensus to require ECN.  My point here is that if you don't like that requirement, no one is stopping you from being non-compliant.

-- 
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/issues/2156#issuecomment-447182244

---

From: ekr <[email-masked]>
Date: Thu, 13 Dec 2018 17:41:14 -0800

This wasn't my understanding, and I would have objected to it if I had understood it to be that. @mnot @larseggert what is your understanding of the situation?

-- 
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/issues/2156#issuecomment-447183689

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Dec 2018 23:16:37 -0800

This change was introduced in <https://github.com/quicwg/base-drafts/pull/1631>. 

As far as I can tell, this requirement level in particular has never been discussed; I do note that the discussion on the PR among the editors did brush up against it.

I've removed the `editorial` label for now. I'll defer to Lars on deciding here, but would suggest that if you can't work it out between yourselves, to take it to the list.

/cc @gloinul 

-- 
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/issues/2156#issuecomment-447237226

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 13 Dec 2018 23:17:00 -0800

/cc @mirjak too.

-- 
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/issues/2156#issuecomment-447237306

---

From: Brian Trammell <[email-masked]>
Date: Fri, 14 Dec 2018 00:27:43 -0800

As I recall the discussion in Kista seemed to converge to requiring ECN when possible (I disticntly remember “using QUIC as a driver for ECN deployment” raised as a reason to do so), but I also don’t recall detailed discussion of requirements levels (SHOULD vs MUST); there was also a recognition that the state of userland access to ECN bits would be a big obstacle to mandatory deployment.

(FWIW I’m strongly in favor of “SHOULD offer/negotiate, unless implementation platform does not support; SHOULD allow config to disable for operational reasons (largely in non-Internet networks using the bits with other semantics a la DCTCP)” i.e. as MUST as realistically possible)

Is there a good reason not to do ECN when the underlying platform supports?

-- 
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/issues/2156#issuecomment-447252222

---

From: mirjak <[email-masked]>
Date: Fri, 14 Dec 2018 01:11:17 -0800

The current text does not require you to set ECT(0) on your packets that you send but it does require you to send feedback if you can. This leaves the decision to use ECN to the sender. That's the only way it makes sense.

Further the text require you to use ECT(0) (and not ETC(1)) if you want to use ECN, which is what RFC8311 says.

-- 
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/issues/2156#issuecomment-447263022

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Dec 2018 04:47:26 -0800

@larseggert  did state the following on the mailing list on the 8th of November:

"Both the -14 ACK_ECN frame and any new unified frame will be mandatory to parse on RX for compliance. But there is no enforceable requirement to act on the content.

Likewise, on TX, it's not enforceable that a stack must obtain the ECN bits from the kernel and encode them. With -14, it would simply always encode ACK frames (and never encode ACK_ECN frames), and with any unified approach, it could simply always encode "nothing marked".

There is maybe a slight nudge towards doing ECN properly with a unified approach, since you need to encode something for ECN, and so you might as well do the right thing. But it remains fully possible to not support ECN, with either approach. (Unfortunately.)"

https://mailarchive.ietf.org/arch/msg/quic/7-VL8efXCDg4q-YWEDzrHG1Gia8

-- 
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/issues/2156#issuecomment-447315123

---

From: ianswett <[email-masked]>
Date: Fri, 14 Dec 2018 09:05:47 -0800

To echo @britram my memory is that peers MUST support the frame, but actually using ECN was a SHOULD since a MUST isn't enforceable anyway.

I think it's worth making this(or whatever we agree upon) a bit clearer, though.

-- 
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/issues/2156#issuecomment-447388306

---

From: janaiyengar <[email-masked]>
Date: Fri, 14 Dec 2018 15:46:04 -0800

I've always said that we need to have a notion of endpoints that "support ECN" and ones that don't. This does not need to be negotiated, but it reflects reality. Some impls will implement ECN support and some won't.

To the question of whether there is a good reason to not do it: Yes, implementation complexity for little gain. I'm not arguing for not implementing ECN support, I'm saying that there are good reasons for not doing it.

If we want to encourage ECN, we need to simply say that. And the text should reflect the reality that some endpoints will choose to still not support it.

-- 
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/issues/2156#issuecomment-447511912

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 16 Dec 2018 21:05:59 -0800

IIRC what @mirjak says aligns to what I remember as the outcome of Kista.

I think it makes sense to encourage receivers to send back ACK frames with ECN counters, because without that, a sender cannot use ECN.

Whether a sender should use ECN is a different issue, and for that I prefer not having a recommendation.

-- 
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/issues/2156#issuecomment-447723917

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 18 Dec 2018 10:18:55 +0000 (UTC)

I just commented that I think SHOULD in 3) is wrong, as if one send IP packets with QUIC packets in them and have ECT set, then one MUST treat CE marks on those packets as congestion events. Otherwise one is a non responsive to congestion and unfair to other ECT flows. And it is RECOVERY's task to define that response. 

-- 
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/issues/2156#issuecomment-448169942

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Dec 2018 23:25:12 +0000 (UTC)

Closed #2156 via 9d20ea501c0c72ffe593af6179ebbdad9d2abf87.

-- 
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/issues/2156#event-2034369245