RE: ECN in QUIC

["Lubashev, Igor" <[e-mail]>]

You are right - it was not easy to catch everything. I came with an impression that the main objection to counters was not connection migration but incompatibility with the future multi-path. Even though multi-path is not in scope for v1, people were afraid of the total incompatibility of the scheme. Am I the only one with that impression?

- Igor

-----Original Message-----
From: Ingemar Johansson S [[e-mail]]
Received: Wednesday, 24 Jan 2018, 3:01AM
To: QUIC WG [[e-mail]]
Subject: ECN in QUIC

Hi

A few impressions on the ECN in QUIC discussions. The audio was so-so, frequent interruptions and LARGE differences in audio level + badly implemented ears ?, so sometimes I missed the details and possibly kick in open doors.

*  Feedback format. I understand that the proposed proposal based on ECT(0), ECT(1) and CE counters does not play well with connection migration. I believe, but I am not 100% sure that I understand the problem. I understand that there are two concerns (perhaps more?):
  1. Counters are reset, this means that there will be a potentially very large (negative?) difference in CE marked packets. I believe that this can be detected as false congestion signal and ignored by the congestion signal.
  2. Difficulties to detect ECN bleaching. It is tricky to understand if packets along the new path are bleached based on the ECT counters. This can be a more complicated case.
In any case it was suggested to indicate the ECN bits for the packets in the ACK frame. Such a format was actually outlined in earlier proposal (see page 6, Figure 3 in https://tools.ietf.org/html/draft-johansson-quic-ecn-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Djohansson-2Dquic-2Decn-2D01&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=xVzIA9f7WjK8CVIQ3B-v9ZNl-Uf8HCY4nYPb0fMRO-4&s=S9aqc8UIGaTDX3ZMs1VTyWiLSSG01ndFhhr_Zg01H1Y&e=> ). It is Ok with me to change to a format similar to this if the group prefers that.

* Congestion control for ECT(1), L4S : My feeling is that it is for now OK to leave this as future work. That does not mean that there are absolutely no ideas on how to implement this, for short RTT environments DCTCP style congestion control is quite OK. Furthermore I and recently worked on a L4S congestion control that is based on BBR, the results look quite promising and the changes to the BBR algorithm are quite minimal. I am willing to present this at ICCRG in London if there is any interest in this.
* ECN in QUIC v1 or later : I would very much prefer that ECN support goes into v1. On the technical side it makes it possible to experiment with ECN, potentially on a larger scale. On the political side it helps to make the "chicken and egg" problem become history.

/Ingemar
==================================
Ingemar Johansson  M.Sc.
Master Researcher

Ericsson Research
Network Protocols & E2E Performance
Labratoriegr?nd 11
971 28, Lule?, Sweden
Phone [phone]
SMS/MMS [phone]
[e-mail]<mailto:[e-mail]>
www.ericsson.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ericsson.com&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=xVzIA9f7WjK8CVIQ3B-v9ZNl-Uf8HCY4nYPb0fMRO-4&s=tySiMlgTyIT8IJmaKYS-yMYBNj0YUw_M246hX4szKZ4&e=>

The world is full of magical things patiently
    waiting for our wits to grow sharper
               Bertrand Russell
==================================