Explicit Congestion Notification (ECN)

[ianswett]

ECN is not currently mentioned in the recovery draft, but it should be included.

More importantly, the transport draft has no ability for the peer to communicate ECN marks back to the sender. I suspect, like ECN, the use of this in the transport would be negotiable in the QUIC handshake.

In practice, there most userspace network stacks also cannot see if those marks are set when packets are read.

[IngJohEricsson]

The specific items that are needed are (perhaps more ?)

• ECN echo in protocol, preferrably as a mandatory to implement part, RFC7560 can provide with valuable input in the design
• ECN negotiation, the work on updated ECN semanticts in TSVWG should be addressed (L4S support)
• Fallback for in various failure cases, and RFC6679 and draft-kuehlewind-tcpm-ecn-fallback-01 may provide input
• Address user space limitation, collect best current practice to read/write ECN bits for different OS.
• Align meaning of ECN-CE marking of ECT(0) and ECT(1) traffic with TSVWG

[martinduke]

I endorse mandatory ECN support in QUIC.

I see that there's now an internet-draft on this subject:
(https://tools.ietf.org/html/draft-johansson-quic-ecn-00)

It's debatable if it's better to put the ECE/CWR bits in the ACK frame (as the draft suggests) or in some newly-liberated public flags.

As an added feature/bug, depending on your perspective, service providers interested in enforcing fairness or bandwidth limits could use ECN bits as fairly clean way to do this. With TCP, a common flow-control tool is the receive window, but that is not available here.

[IngJohEricsson]

Hi Thanks for the comment. As regards to the ECE/CWR bits, I would believe that we have a reasonably good agreement that for QUIC it is best to echo the ECN bits as is. There are three variants in the draft and there is not conclusion which is the best alternative (or if there should be something else) /Ingemar From: martinduke [mailto:notifications@github.com] Sent: den 8 februari 2017 20:12 To: quicwg/base-drafts <base-drafts@noreply.github.com> Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; Comment <comment@noreply.github.com> Subject: Re: [quicwg/base-drafts] Explicit Congestion Notification (ECN) (#68) I endorse mandatory ECN support in QUIC. I see that there's now an internet-draft on this subject: (https://tools.ietf.org/html/draft-johansson-quic-ecn-00) It's debatable if it's better to put the ECE/CWR bits in the ACK frame (as the draft suggests) or in some newly-liberated public flags. As an added feature/bug, depending on your perspective, service providers interested in enforcing fairness or bandwidth limits could use ECN bits as fairly clean way to do this. With TCP, a common flow-control tool is the receive window, but that is not available here. — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#68 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AKOdGKXZqkAOJaDwg7HfdI3U7RkJrBkkks5rahN9gaJpZM4LDU7v>.

[britram]

Another +1 to mandatory ECN support in QUIC (as mentioned in #632), largely as defined in the current individual draft, with ECN echo in the ACK frame; though I'd maybe call the mechanism in section 2.1 "ECN capability sensing" as opposed to "negotiation".

[martinthomson]

I'm going to close this as a duplicate of #632. We're trying to reduce the number of issues. While not strictly a duplicate, this issue is a direct request for a particular change, whereas #632 is more phrased as an issue. We prefer issues that are more like #632 than this one.

[IngJohEricsson]

Hi Thanks, and your suggestion to rename section 2.1 makes much sense /Ingemar From: Brian Trammell [mailto:notifications@github.com] Sent: den 20 juni 2017 10:33 To: quicwg/base-drafts <base-drafts@noreply.github.com> Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; Comment <comment@noreply.github.com> Subject: Re: [quicwg/base-drafts] Explicit Congestion Notification (ECN) (#68) Another +1 to mandatory ECN support in QUIC (as mentioned in #632<#632>), largely as defined in the current individual draft<https://tools.ietf.org/html/draft-johansson-quic-ecn-04>, with ECN echo in the ACK frame; though I'd maybe call the mechanism in section 2.1 "ECN capability sensing" as opposed to "negotiation". — You are receiving this because you commented. Reply to this email directly, view it on GitHub<#68 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AKOdGP88Pj7O6PpTOQAGn3_yV0FM6gpvks5sF4OmgaJpZM4LDU7v>.