Subject: Re: [quicwg/base-drafts] Text on ECN probing (#3585)

From: Magnus Westerlund <[email-masked]>
Date: Wed, 06 May 2020 01:40:08 -0700

So I think there might be a point to indicate the current state of affairs when it comes to black holing better. However, it doesn't really change the need for validation as the main issue to check for is actually that the receiver is capable of receiving the ECN bits which has a much higher risk of not being true. I would even argue that the reason for stop sending ECT after a sufficient number of packets that some should make it is to avoid getting an unfair advantage until you know that the code points are read and that you will get an CE mark if it occurs. So maybe the text should be changed to focus on this aspect? 

Even if the proposed PR is rejected there need to be a change to this sentence: 

"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."

There is a missing "only" or something else to indicate that you are sending ECN for a while then going back to not-ECT until validation has occurred. 

-- 
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/3585#issuecomment-624517296

---

From: mirjak <[email-masked]>
Date: Wed, 20 May 2020 05:34:44 -0700

@gloinul the validation mechanism itself is there to stop marking packets as ETC when you don't get feedback for any reason. So that's already covered in the text. For this part of the text the question is if you should set all packet as ETC until validation fails or if there are additional risk which justifies a more complicated scheme where only some of the packets in the validation phase are marked as ECT.

-- 
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/3585#issuecomment-631445224

---

From: Lucas Pardue <[email-masked]>
Date: Mon, 25 May 2020 07:42:03 -0700

MT's proposed editorial change in #3669 appears to clarify the intent of the current draft text. 

Perhaps additional context and discursive text (as proposed in Mirja's #3454) is more suited to the Applicability draft?

-- 
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/3585#issuecomment-633604014

---

From: mirjak <[email-masked]>
Date: Wed, 27 May 2020 05:30:25 -0700

#3669 does not address this issue. This was just a side comment that came up. I think the minimum would be to replace

"To reduce the chances of misinterpreting congestive loss as packets dropped by a
faulty network element..."

by

"If there is as a concern for a certain network that all ECT-marked packets might be dropped by a faulty network element and would therefore cause a performance drop, then..."

However, I would still prefer to give a bit more context than this (basically one more sentence as proposed). I don't think this fits in the applicability statement as I don't think there is any intention here to provide an interface to specify the ECN probing behaviour and therefore a "user" of QUIC, which is the audience for the applicability statement, would not know what to do about this information. If we want an interface and move this to applicability, I think the whole text should be moved there with some more discussion rather than giving a random recommendation in the base spec.

-- 
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/3585#issuecomment-634627412

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 27 May 2020 06:49:26 -0700

Thanks for the clarification, that makes sense.

As someone not familiar with ECN and just reading the specification, I'm struggling to see what the crux of the issue is. And I would hypothesise that this is a contributing factor to it getting stalled. 

As an inexperienced implementer I find the current text a bit weak but I'm not sure more context helps me.

If I were to distil it down I'd take the current text:

>   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.

and simply editorialize it to

> ECN-marked packets might be dropped by a faulty network element. To reduce the chances of confusing this with congestive loss of packets, an endpoint could set the ECT(0) codepoint for only the first ten outgoing packets on a path, or for a period of three RTTs, whichever occurs first.

-- 
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/3585#issuecomment-634673693

---

From: mirjak <[email-masked]>
Date: Wed, 27 May 2020 07:35:17 -0700

This doesn't address my point. Today there is little to no evidence that these faulty network elements still exists. So my recommendation would be to not add any complexity by implementing these schemes. The current text makes it look like this, however, is a common problem, which is not the case, and therefore indictes that this scheme is recommended to be implemented.

-- 
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/3585#issuecomment-634702506

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 27 May 2020 08:38:31 -0700

Implementations have a bunch of complexity trade-offs to make. Since the text is non-normative I don't feel obliged to implement this technique. And if I understand it correctly, if I did implement this and ran it on a network path where there were no bad elements, then nothing bad will happen?

-- 
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/3585#issuecomment-634747389

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 28 May 2020 23:14:03 -0700

@mirjak: I don't understand the pushback.  As @LPardue notes, if no faulty network elements exist, the mechanism should work just fine. 

I think the crux of the disagreement might be that the text suggests that the default stance is test and then use, where perhaps you are arguing for use and fall back. I honestly don't think it makes much of a difference, and in the absence of _overwhelming information_ we need to be taking the conservative stance on this spec.

-- 
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/3585#issuecomment-635781710

---

From: Lars Eggert <[email-masked]>
Date: Thu, 28 May 2020 23:20:21 -0700

I'm agreeing with the editors here. I think the PR is a useful modification, but we'd need to see stronger feedback from the WG to warrant making more changes to the current text.

-- 
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/3585#issuecomment-635783731

---

From: mirjak <[email-masked]>
Date: Fri, 29 May 2020 01:04:15 -0700

The difference is that I would like to decrease unnecessary barrier to use ECN. If people are too lazy to implement this and don't understand that it is not needed, they might just disable ECN instead. If not sure what you mean by overwhelming information but we have done extensive measurements over 5 years showing that this problem doesn't exists anymore. What else are you expecting?

-- 
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/3585#issuecomment-635826806

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 29 May 2020 01:33:45 -0700

So far I didnt really see this issuing being coined in terms of "guidance for conservative ECN use risks low uptake of the ECN feature". If that is the core issue, then an example of overwhelming information is to see support for addressing the issue from a number of QUIC implementations that do not support ECN, and have chosen to do so because of this guidance. 

Since the other text around ECN seems to require per-packet-space counts, and other parts of QUIC require RTT measurement, I'm finding it difficult to see how this is a burdensome thing to implement. But I can only speak to my implementation and experience. 

-- 
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/3585#issuecomment-635847287

---

From: Lars Eggert <[email-masked]>
Date: Fri, 29 May 2020 01:40:04 -0700

So last I counted there were only four stacks that even implemented the ACK-ECN frame type to _report_ ECN marks. So even very basic support for ECN is (still) missing in most stacks, esp. the ones that are likely going to see the largest deployments.

I don't think any text tweaks we could make here are going to move the needle on ECN support in QUIC. 

What will make a difference if a major stack implements it and reports a benefit. That will likely make other stacks follow.

-- 
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/3585#issuecomment-635850154

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 29 May 2020 15:58:25 -0700

Implementing this mechanism is trivial for someone implementing the rest of QUIC. It's not a lazy implementer that is causing the problem of lack of implementation, it's an unmotivated one. As @larseggert notes, in the absence of ACK-ECN, this doesn't even matter.

I am not hearing any of the implementers complaining about the complexity of the mechanism here, so I would argue that the mechanism is not an issue.

-- 
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/3585#issuecomment-636227803