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

From: Mike Bishop <[email-masked]>
Date: Thu, 23 Feb 2017 00:30:35 +0000

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

On Wed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Baker <[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.

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.

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

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

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>]
Sent: den 22 februari 2017 08:56
To: Ingemar Johansson S <[email-masked]<mailto:[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<http://tools.ietf.org>.

The IETF Secretariat

---

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

QUIC, by being cross-area, makes it difficult for folks to review all docs,
since it's uncommon for folks to know everything about all aspects of TLS,
transport, and HTTP/2. This does make it an opportunity to write drafts
that are clearer to a wider audience. In this case, I think a reference to
RFC 3168 and a couple of sentences ought to be adequate.

That said, I'll note that this cross-area work will require everyone to
wear their humility hats more frequently. If you are frustrated, it's
perhaps because you're encountering an area that was foreign to you until
now. ECN is not outside-think for anyone who's been working on transport
protocols for more than a day. I'd ask about something you don't understand
first, and then consider declaring that the wg should not work on it.

Prepare to be frustrated more often.

On Wed, Feb 22, 2017 at 5:33 PM, Phillip Hallam-Baker <[email-masked]
> wrote:

> Not sarcastic at all. Just frustrated. Reading a draft should not require
> recourse to Wikipedia.
>
> 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
>>
>>
>>
>> On Wed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Baker <
>> [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.
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S <
>> [email-masked]> wrote:
>>
>> Hi
>>
>> From: [email-masked] [mailto:[email-masked]]
>> To: Ingemar Johansson S <[email-masked]>
>> 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: Ingemar Johansson S <[email-masked]>
Date: Thu, 23 Feb 2017 07:38:02 +0000

Hi

I can add a more comprehensive text that describes ECN a bit and an expansion of the acronyms, that sounds very reasonable.
I don’t however want to add a complete ECN crash-course into the document  as this text already exist elsewhere in TSVWG, ICCRG  and AQM WG documents.

Regards
/Ingemar

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: den 23 februari 2017 03:52
To: Jana Iyengar <[email-masked]>
Cc: Mike Bishop <[email-masked]>; [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

On Wed, Feb 22, 2017 at 9:38 PM, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:
QUIC, by being cross-area, makes it difficult for folks to review all docs, since it's uncommon for folks to know everything about all aspects of TLS, transport, and HTTP/2. This does make it an opportunity to write drafts that are clearer to a wider audience. In this case, I think a reference to RFC 3168 and a couple of sentences ought to be adequate.

That said, I'll note that this cross-area work will require everyone to wear their humility hats more frequently. If you are frustrated, it's perhaps because you're encountering an area that was foreign to you until now. ECN is not outside-think for anyone who's been working on transport protocols for more than a day. I'd ask about something you don't understand first, and then consider declaring that the wg should not work on it.

Authors should not require readers to become supplicants or wear 'humility hats'.

​If you use an acronym, you always expand it on the first reference. If you are using a defined term you always cite the reference.​ If ECN was the only unbound acronym in the introduction, I might have let it go. Only it continues.

​"​ ECN and L4S ECN by means of differentiation between the use of the
   ECT(0) and ECT(1) code points.  "

​There are two reasons that I don't accept work of that kind. The first is that it makes no sense to me and if I have to start working through lots of other documents to work out what the author means, it is far more likely than not that we will end up with different understandings of what is being said.

On Wed, Feb 22, 2017 at 5:33 PM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:
Not sarcastic at all. Just frustrated. Reading a draft should not require recourse to Wikipedia.

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
Sent: Wednesday, February 22, 2017 3:37 PM
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]>>
Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt

Hope this helps,
- jana

/Ingemar

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

Abstract:

The IETF Secretariat

---

From: Mike Bishop <[email-masked]>
Date: Thu, 9 Mar 2017 16:03:29 +0000

A quick overview of what it is and why it matters plus informational references to how it works seems like a reasonable combination.

From: QUIC [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
Sent: Wednesday, February 22, 2017 11:38 PM
To: Phillip Hallam-Baker <[email-masked]>; Jana Iyengar <[email-masked]>
Cc: [email-masked]' ([email-masked]) <[email-masked]>; Mike Bishop <[email-masked]>; Bob Briscoe ([email-masked]) <[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

Hi

Regards
/Ingemar

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: den 23 februari 2017 03:52
To: Jana Iyengar <[email-masked]<mailto:[email-masked]>>
Cc: Mike Bishop <[email-masked]<mailto:[email-masked]>>; [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]>>
Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt

Hope this helps,
- jana

/Ingemar

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

Abstract:

The IETF Secretariat