Subject: FW: New Version Notification for draft-johansson-quic-ecn-01.txt

From: Ingemar Johansson S <[email-masked]>
Date: Wed, 22 Feb 2017 17:22:13 +0000

Hi

I just uploaded a new version of the ECN in QUIC draft. The main change a description of the ECN negotiation.

/Ingemar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: den 22 februari 2017 08:56
To: Ingemar Johansson S <[email-masked]>
Subject: New Version Notification for draft-johansson-quic-ecn-01.txt

A new version of I-D, draft-johansson-quic-ecn-01.txt has been successfully submitted by Ingemar Johansson and posted to the IETF repository.

Name:		draft-johansson-quic-ecn
Revision:	01
Title:		ECN support in QUIC
Document date:	2017-02-21
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-johansson-quic-ecn-01.txt 
Status:         https://datatracker.ietf.org/doc/draft-johansson-quic-ecn/
Htmlized:       https://tools.ietf.org/html/draft-johansson-quic-ecn-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-johansson-quic-ecn-01

Abstract:
   This memo outlines the ECN support in QUIC.  The intention is that
   most of the material ends up updating other new or existing QUIC
   protocol specifications, thus it may be possible that this draft does
   not warrant a working group status.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Feb 2017 15:55:26 -0500

This is the entirety of the introduction:

   ECN support in transport protocols is a fundamental feature that
   should be included in the QUIC specification as a mandatory element.
   The benefits of ECN is described in [I-D.ietf-aqm-ecn-benefits].  The
   ECN support should be implemented to support both present and future
   ECN, the latter is outlined in [I-D.ietf-tsvwg-ecn-experimentation],
   of particular interest is the ability to discriminate between classic
   ECN and L4S ECN by means of differentiation between the use of the
   ECT(0) and ECT(1) code points.  This draft does however not delve
   into the details of the congestion control implementation.

I have absolutely no idea what ECN is. I am opposed to the WG spending any
time on ECN until it can be explained in terms that do not reference yet
more jargon.

On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S <
[email-masked]> wrote:

> A new version of I-D, draft-johansson-quic-ecn-01.txt has been
> successfully submitted by Ingemar Johansson and posted to the IETF
> repository.
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
>
> The IETF Secretariat
>
>

---

From: Roland Zink <[email-masked]>
Date: Thu, 23 Feb 2017 00:24:53 +0100

ECN is Explicit Congestion Notification which I think already explains 
what it tries to achieve. For more information Wikipedia has something 
at https://en.wikipedia.org/wiki/Explicit_Congestion_Notification.

Regards,

Roland

Am 22.02.2017 um 21:55 schrieb Phillip Hallam-Baker:
> I have absolutely no idea what ECN is. I am opposed to the WG spending 
> any time on ECN until it can be explained in terms that do not 
> reference yet more jargon.
>
>
>
> On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi
>
>     I just uploaded a new version of the ECN in QUIC draft. The main
>     change a description of the ECN negotiation.
>
>     /Ingemar
>
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     To: Ingemar Johansson S <[email-masked]
>     <mailto:[email-masked]>>
>     URL:
>     https://www.ietf.org/internet-drafts/draft-johansson-quic-ecn-01.txt
>     <https://www.ietf.org/internet-drafts/draft-johansson-quic-ecn-01.txt>
>     <https://datatracker.ietf.org/doc/draft-johansson-quic-ecn/>
>     <https://tools.ietf.org/html/draft-johansson-quic-ecn-01>
>     Diff:
>     https://www.ietf.org/rfcdiff?url2=draft-johansson-quic-ecn-01
>     <https://www.ietf.org/rfcdiff?url2=draft-johansson-quic-ecn-01>
>
>     Abstract:
>     tools.ietf.org <http://tools.ietf.org>.
>
>     The IETF Secretariat
>
>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 22 Feb 2017 15:37:06 -0800

> time on ECN until it can be explained in terms that do not reference yet

Happy to help. ECN is defined in RFC 3168
<https://tools.ietf.org/html/rfc3168>, and is an explicit signal from the a
network switch or router about congestion at a link, so that endpoints can
use this signal instead of loss for detecting and reacting to congestion.
The benefits of doing this are documented int he I-D that is linked in the
abstract. ECN has been a pretty significant thing in transport for about
two decades, but has had an uphill battle since ECN requires support in the
network and at endpoints.

There have been many efforts to try and deploy it in network devices and at
endpoints for about as long as RFC 3168 has existed. ECN has been deployed
in bits at routers and in endpoints, but due to long-standing bugs in older
home-routers and wifi boxes, and issues around use of these bits in the IP
header, it was generally not turned on anywhere. This seems to be changing
now, especially as bufferbloat becomes an increasingly visible issue. Brian
Trammell (IAB) and Mirja Kuehlewind (Transport AD) have been actively doing
measurement about the current deployment state of ECN; here's a blog post
by Brian
<https://mami-project.eu/index.php/2016/06/13/70-of-popular-web-sites-support-ecn/>
from
last summer saying that a large number of webservers do support ECN.
There's support for ECN built into TCP (see Section 3.2 and 4.3 of the TCP
Roadmap RFC <https://trac.tools.ietf.org/html/rfc7414>), there's been a ton
of work around re-using ECN signaling for richer congestion information.

Since TCP and SCTP have support for ECN, and the future may see ECN
deployment increase yet, it's expected that QUIC would have equivalent
mechanisms to support use of ECN. This work is very much in scope, as part
of the congestion control aspect of QUIC.

Hope this helps,
- jana

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Feb 2017 21:43:22 -0500

Not being sarcastic. I am a security guy, not a transport guy. It is over
25 years since I did work at this level in the stack and the Internet
didn't reach where I was at the time so the terms I am familiar with are
different. What has meaning for you may not have meaning to me. I am
familiar with the concept of congestion control but the acronyms mean
nothing to me.

The output of a WG is documents. The draft isn't going to become an RFC
with that introduction so it is going to have to be fixed some time. Might
as well fix it now before it is read by all the other parts of the IETF
rather than after they have all scrambled to work out what it is about.

QUIC is essentially a replacement for TCP in all but one respect. TCP was
only implemented by kernel level hackers and the document only had to be
understood by a small set of people. QUIC is not going to be so limited in
scope and the documents had better make sense to the wider audience.

On Wed, Feb 22, 2017 at 7:30 PM, Mike Bishop <[email-masked]>
wrote:

> I read PHB’s comment as a typically-sarcastic way of saying that the
> Introduction of this draft assumes quite a bit of knowledge that is perhaps
> best spelled out with some relevant informative references.  That is, after
> all, the point of an introduction.
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Jana Iyengar
> *Sent:* Wednesday, February 22, 2017 3:37 PM
> *To:* Phillip Hallam-Baker <[email-masked]>
> *Cc:* [email-masked]' ([email-masked]) <[email-masked]>;
> Bob Briscoe ([email-masked]) <[email-masked]>; Ingemar
> Johansson S <[email-masked]>;
> [email-masked]; marcelo bagnulo braun <[email-masked]>;
> Piers O'Hanlon <[email-masked]>; IETF QUIC WG <[email-masked]>;
> De Schepper, Koen (Nokia - BE) <[email-masked]>
> *Subject:* Re: FW: New Version Notification for
> draft-johansson-quic-ecn-01.txt
>
>
>
> <https://tools.ietf.org/html/rfc3168>, and is an explicit signal from the
> a network switch or router about congestion at a link, so that endpoints
> can use this signal instead of loss for detecting and reacting to
> congestion. The benefits of doing this are documented int he I-D that is
> linked in the abstract. ECN has been a pretty significant thing in
> transport for about two decades, but has had an uphill battle since ECN
> requires support in the network and at endpoints.
>
>
>
> There have been many efforts to try and deploy it in network devices and
> at endpoints for about as long as RFC 3168 has existed. ECN has been
> deployed in bits at routers and in endpoints, but due to long-standing bugs
> in older home-routers and wifi boxes, and issues around use of these bits
> in the IP header, it was generally not turned on anywhere. This seems to be
> changing now, especially as bufferbloat becomes an increasingly visible
> issue. Brian Trammell (IAB) and Mirja Kuehlewind (Transport AD) have been
> actively doing measurement about the current deployment state of ECN;
> here's a blog post by Brian
> <https://mami-project.eu/index.php/2016/06/13/70-of-popular-web-sites-support-ecn/> from
> Roadmap RFC <https://trac.tools.ietf.org/html/rfc7414>), there's been a
> ton of work around re-using ECN signaling for richer congestion information.
>
>
>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 22 Feb 2017 18:47:05 -0800

Agreed on the general sentiment. I think we have a good thing here by
having folks from various areas in the same wg, in at least that we can
make the documents much more readable and understandable than other
documents in any of the three areas.

On Wed, Feb 22, 2017 at 6:43 PM, Phillip Hallam-Baker <[email-masked]

> On Wed, Feb 22, 2017 at 7:30 PM, Mike Bishop <[email-masked]
> > wrote:
>
>> [email-masked]; marcelo bagnulo braun <
>> [email-masked]>; Piers O'Hanlon <[email-masked]>; IETF
>> QUIC WG <[email-masked]>; De Schepper, Koen (Nokia - BE) <
>> [email-masked]>
>> any time on ECN until it can be explained in terms that do not reference
>> yet more jargon.
>>
>>
>>
>> <https://tools.ietf.org/html/rfc3168>, and is an explicit signal from
>> the a network switch or router about congestion at a link, so that
>> endpoints can use this signal instead of loss for detecting and reacting to

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 23 Feb 2017 07:58:49 +0100

below...

El 23/02/17 a las 03:43, Phillip Hallam-Baker escribió:
>
> The output of a WG is documents. The draft isn't going to become an 
> RFC with that introduction so it is going to have to be fixed some time.
Not really

The abstract of the document reads:

IMHO, the current use of the ECN concepts and terminology in the 
document is ok for a document that is for internal consumption of a TSV 
area WG.

> Might as well fix it now before it is read by all the other parts of 
> the IETF rather than after they have all scrambled to work out what it 
> is about.
>
> QUIC is essentially a replacement for TCP in all but one respect. TCP 
> was only implemented by kernel level hackers and the document only had 
> to be understood by a small set of people. QUIC is not going to be so 
> limited in scope and the documents had better make sense to the wider 
> audience.
>
>
> On Wed, Feb 22, 2017 at 7:30 PM, Mike Bishop 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>     I read PHB’s comment as a typically-sarcastic way of saying that
>     the Introduction of this draft assumes quite a bit of knowledge
>     that is perhaps best spelled out with some relevant informative
>     references.  That is, after all, the point of an introduction.
>
>     *From:* QUIC [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Jana Iyengar
>     *To:* Phillip Hallam-Baker <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* [email-masked] <mailto:[email-masked]>'
>     ([email-masked] <mailto:[email-masked]>)
>     <[email-masked] <mailto:[email-masked]>>; Bob Briscoe
>     ([email-masked] <mailto:[email-masked]>)
>     <[email-masked] <mailto:[email-masked]>>; Ingemar
>     Johansson S <[email-masked]
>     <mailto:[email-masked]>>;
>     [email-masked]
>     <mailto:[email-masked]>; marcelo bagnulo braun
>     <[email-masked] <mailto:[email-masked]>>; Piers O'Hanlon
>     <[email-masked] <mailto:[email-masked]>>;
>     IETF QUIC WG <[email-masked] <mailto:[email-masked]>>; De Schepper,
>     Koen (Nokia - BE) <[email-masked]
>     <mailto:[email-masked]>>
>     On Wed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Baker
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         I have absolutely no idea what ECN is. I am opposed to the WG
>         spending any time on ECN until it can be explained in terms
>         that do not reference yet more jargon.
>
>     <https://tools.ietf.org/html/rfc3168>, and is an explicit signal
>     from the a network switch or router about congestion at a link, so
>     that endpoints can use this signal instead of loss for detecting
>     and reacting to congestion. The benefits of doing this are
>     documented int he I-D that is linked in the abstract. ECN has been
>     a pretty significant thing in transport for about two decades, but
>     has had an uphill battle since ECN requires support in the network
>     and at endpoints.
>
>     There have been many efforts to try and deploy it in network
>     devices and at endpoints for about as long as RFC 3168 has
>     existed. ECN has been deployed in bits at routers and in
>     endpoints, but due to long-standing bugs in older home-routers and
>     wifi boxes, and issues around use of these bits in the IP header,
>     it was generally not turned on anywhere. This seems to be changing
>     now, especially as bufferbloat becomes an increasingly visible
>     issue. Brian Trammell (IAB) and Mirja Kuehlewind (Transport AD)
>     have been actively doing measurement about the current deployment
>     state of ECN; here's a blog post by Brian
>     last summer saying that a large number of webservers do support
>     ECN. There's support for ECN built into TCP (see Section 3.2 and
>     4.3 of the TCP Roadmap RFC
>     <https://trac.tools.ietf.org/html/rfc7414>), there's been a ton of
>     work around re-using ECN signaling for richer congestion information.
>
>     Since TCP and SCTP have support for ECN, and the future may see
>     ECN deployment increase yet, it's expected that QUIC would have
>     equivalent mechanisms to support use of ECN. This work is very
>     much in scope, as part of the congestion control aspect of QUIC.
>
>     Hope this helps,
>
>     - jana
>
>             I just uploaded a new version of the ECN in QUIC draft.
>             The main change a description of the ECN negotiation.
>
>             /Ingemar
>
>             A new version of I-D, draft-johansson-quic-ecn-01.txt has
>             been successfully submitted by Ingemar Johansson and
>             posted to the IETF repository.
>
>             Status:
>             https://datatracker.ietf.org/doc/draft-johansson-quic-ecn/
>             Htmlized:
>             https://tools.ietf.org/html/draft-johansson-quic-ecn-01
>             Please note that it may take a couple of minutes from the
>             time of submission until the htmlized version and diff are
>             available at tools.ietf.org <http://tools.ietf.org>.
>
>             The IETF Secretariat
>
>

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 23 Feb 2017 18:09:42 +0900

> document is ok for a document that is for internal consumption of a TSV

It would be nevertheless extremely helpful if that acronym would be 
expanded once, e.g. early in the introduction. Using "Explicit 
Congestion Notification" in the title would be even better, there are 
already many good examples for this:

https://tools.ietf.org/html/rfc6679
https://tools.ietf.org/html/rfc7560
https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn-00
https://tools.ietf.org/html/draft-ietf-aqm-ecn-benefits-08
https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-00
and to some extent https://tools.ietf.org/html/rfc6789

"Explicit Congestion Notification" is pretty much self-explaining, but 
"ENC" isn't even on a list like http://acronyms.thefreedictionary.com/ENC.

>> the IETF rather than after they have all scrambled to work out what it

Yes, please.

Regards,   Martin.

---

From: Mirja Kühlewind <[email-masked]>
Date: Thu, 23 Feb 2017 10:35:03 +0100

This is a completely useless discussion but at this point I really strongly 
disagree. This is a DRAFT; it not ready for publication and in this case it 
also will never be published as RFC (as you assume wrongly). This document is 
discussing different options how to integrate ECN in 
draft-ietf-quic-transport. If you don't know what ECN is, this draft is 
probably not directed at you. If you want to learn what ECN, it's easy to 
find RFC3168 or wikipedia on the Internet. However, the fundamental point 
here is that I rather see a non-perfect draft as a basis for discussion that 
everybody who is interested can look at, then having private 
side-discussions. Putting the bar higher on what a -00 or -01 or whatever 
version of a draft should be is wrong!

On 23.02.2017 03:43, Phillip Hallam-Baker wrote:
> Not being sarcastic. I am a security guy, not a transport guy. It is over 25
> years since I did work at this level in the stack and the Internet didn't
> reach where I was at the time so the terms I am familiar with are different.
> What has meaning for you may not have meaning to me. I am familiar with the
> concept of congestion control but the acronyms mean nothing to me.
>
> The output of a WG is documents. The draft isn't going to become an RFC with
> that introduction so it is going to have to be fixed some time. Might as well
> fix it now before it is read by all the other parts of the IETF rather than
> after they have all scrambled to work out what it is about.
>
> <mailto:[email-masked]>> wrote:
>
>     Introduction of this draft assumes quite a bit of knowledge that is
>     perhaps best spelled out with some relevant informative references.  That
>     is, after all, the point of an introduction.____
>
>     __ __
>
>     ([email-masked] <mailto:[email-masked]>) <[email-masked]
>     <mailto:[email-masked]>>; Ingemar Johansson S
>     [email-masked] <mailto:[email-masked]>;
>     marcelo bagnulo braun <[email-masked] <mailto:[email-masked]>>;
>     Piers O'Hanlon <[email-masked]
>     <mailto:[email-masked]>>; IETF QUIC WG <[email-masked]
>     <mailto:[email-masked]>>; De Schepper, Koen (Nokia - BE)
>     <[email-masked]
>     draft-johansson-quic-ecn-01.txt____
>
>     __ __
>
>     <[email-masked] <mailto:[email-masked]>> wrote:____
>
>         This is the entirety of the introduction:  ____
>
>         __ __
>
>            ECN support in transport protocols is a fundamental feature that____
>
>            should be included in the QUIC specification as a mandatory
>         element.____
>
>            The benefits of ECN is described in [I-D.ietf-aqm-ecn-benefits].
>         The____
>
>            ECN support should be implemented to support both present and
>         future____
>
>            ECN, the latter is outlined in
>         [I-D.ietf-tsvwg-ecn-experimentation],____
>
>            of particular interest is the ability to discriminate between
>         classic____
>
>            ECN and L4S ECN by means of differentiation between the use of the____
>
>            ECT(0) and ECT(1) code points.  This draft does however not delve____
>
>            into the details of the congestion control implementation.____
>
>         __ __
>
>         spending any time on ECN until it can be explained in terms that do
>         not reference yet more jargon.____
>
>     __ __
>
>     requires support in the network and at endpoints. ____
>
>     __ __
>
>     deployed in bits at routers and in endpoints, but due to long-standing
>     bugs in older home-routers and wifi boxes, and issues around use of these
>     bits in the IP header, it was generally not turned on anywhere. This
>     seems to be changing now, especially as bufferbloat becomes an
>     increasingly visible issue. Brian Trammell (IAB) and Mirja Kuehlewind
>     (Transport AD) have been actively doing measurement about the current
>     deployment state of ECN; here's a blog post by Brian
>     There's support for ECN built into TCP (see Section 3.2 and 4.3 of the
>     TCP Roadmap RFC <https://trac.tools.ietf.org/html/rfc7414>), there's been
>     a ton of work around re-using ECN signaling for richer congestion
>     information.____
>
>     __ __
>
>     mechanisms to support use of ECN. This work is very much in scope, as
>     part of the congestion control aspect of QUIC.____
>
>     __ __
>
>     Hope this helps,____
>
>     - jana____
>
>     __ __
>
>         __ __
>
>         __ __
>
>         <mailto:[email-masked]>> wrote:____
>
>             Hi
>
>             successfully submitted by Ingemar Johansson and posted to the
>             IETF repository.
>
>             The IETF Secretariat____
>         __ __
>     __ __

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Feb 2017 10:07:27 -0500

On Thu, Feb 23, 2017 at 4:35 AM, Mirja Kühlewind <
[email-masked]> wrote:

> This is a completely useless discussion but at this point I really
> strongly disagree. This is a DRAFT; it not ready for publication and in
> this case it also will never be published as RFC (as you assume wrongly).

​Drafts are for discussion. If the draft is written to limit discussion to
a small clique then something is wrong.​

> This document is discussing different options how to integrate ECN in
> draft-ietf-quic-transport. If you don't know what ECN is,

​Oh I know what Explicit Congestion Notification is. But ECN on its own
means nothing to me because I work in so many areas.​
​
To me, ECN means Electronic Communications Network and is a place where
stocks and options are being traded. It also means Emergency Communications
Network which is another issue we deal with in IETF.
​

this draft is probably not directed at you.

​That was my bigger problem with this particular group. This was not the
first draft that was rather obviously only written for consideration by a
closed circle. If you want to discuss things in closed circles then the
IETF probably isn't for you.

Having waded through the first set of drafts and found them worse than
useless, my tolerance level was not high when I began reading yet another
draft that rather obviously assumed that this is all a private discussion
and nobody who isn't a member of the club is welcome.

However, the latest protocol draft does look like something I can implement
from.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 23 Feb 2017 16:39:29 -0800

On 2/23/2017 1:09 AM, Martin J. Dürst wrote:
> "ENC" isn't even on a list like 
> http://acronyms.thefreedictionary.com/ENC.

Yes, please. I understand where Mirja comes from, and I also understand 
what ECN means in this context, but Philip has a good point. QUIC 
straddles several layers of our stack, from transport to application 
through security. Three letters acronyms are way more ambiguous than you 
may think, even inside the IETF. For example, I guess you all know that 
FEC means Forward Error Correction, right? But if you have to use MPLS, 
FEC means Forwarding Equivalence Class. So, please, just be 
conservative. Use the full spelling of the acronyms in the title, 
abstract and introduction of documents!

-- Christian Huitema

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 24 Feb 2017 08:14:32 +0000

Hi
Fair enough, I will improve the draft in the next release.

Regards
/Ingemar

> From: Christian Huitema [mailto:[email-masked]]
> Sent: den 24 februari 2017 01:39
> To: [email-masked]
> Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-
> 01.txt
> 
> 
> 
> what ECN means in this context, but Philip has a good point. QUIC straddles
> several layers of our stack, from transport to application through security.
> Three letters acronyms are way more ambiguous than you may think, even
> inside the IETF. For example, I guess you all know that FEC means Forward
> Error Correction, right? But if you have to use MPLS, FEC means Forwarding
> Equivalence Class. So, please, just be conservative. Use the full spelling of
> the acronyms in the title, abstract and introduction of documents!
> 
> -- Christian Huitema
>

---

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 24 Feb 2017 14:20:21 +0100

I don’t think that submitting a public draft and starting a discussion on a public mailing list can be seen as "written for consideration by a closed circle“.

> Am 23.02.2017 um 16:07 schrieb Phillip Hallam-Baker <[email-masked]>:
> 
> On Thu, Feb 23, 2017 at 4:35 AM, Mirja Kühlewind <[email-masked]> wrote:
> This is a completely useless discussion but at this point I really strongly disagree. This is a DRAFT; it not ready for publication and in this case it also will never be published as RFC (as you assume wrongly).
> 
> ​Drafts are for discussion. If the draft is written to limit discussion to a small clique then something is wrong.​
> 
>  
> This document is discussing different options how to integrate ECN in draft-ietf-quic-transport. If you don't know what ECN is,
> 
> ​Oh I know what Explicit Congestion Notification is. But ECN on its own means nothing to me because I work in so many areas.​
> ​
> To me, ECN means Electronic Communications Network and is a place where stocks and options are being traded. It also means Emergency Communications Network which is another issue we deal with in IETF. 
> ​
> 
> ​That was my bigger problem with this particular group. This was not the first draft that was rather obviously only written for consideration by a closed circle. If you want to discuss things in closed circles then the IETF probably isn't for you.
> 
> Having waded through the first set of drafts and found them worse than useless, my tolerance level was not high when I began reading yet another draft that rather obviously assumed that this is all a private discussion and nobody who isn't a member of the club is welcome.
> 
> However, the latest protocol draft does look like something I can implement from.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 24 Feb 2017 11:39:35 -0600

On 02/23/2017 06:39 PM, Christian Huitema wrote:
>
>
> Yes, please. I understand where Mirja comes from, and I also
> understand what ECN means in this context, but Philip has a good
> point. QUIC straddles several layers of our stack, from transport to
> application through security. Three letters acronyms are way more
> ambiguous than you may think, even inside the IETF. For example, I
> guess you all know that FEC means Forward Error Correction, right? But
> if you have to use MPLS, FEC means Forwarding Equivalence Class. So,
> please, just be conservative. Use the full spelling of the acronyms in
> the title, abstract and introduction of documents!

I'll also throw a mention out there of
https://www.rfc-editor.org/materials/abbrev.expansion.txt which has a
lot of acronym expansions.  It also marks a limited subset as not
needing expansion in RFCs due to being well-known (ECN is not one such).

-Ben