Re: ECN in QUIC

[Spencer Dawkins at IETF <[e-mail]>]

FWIW,

On Wed, Jan 24, 2018 at 2:01 AM, Ingemar Johansson S <
[e-mail]> wrote:

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

We deprecated existing use of ECT(1) to allow experiments, which is great,
but (as AD) I'd be more comfortable if QUIC didn't slam some current idea
about L4S into QUICv1, which is targeted as a proposed standard. So, if the
working group is OK leaving that as future work, I'd be thrilled.

I'm always willing to be convinced that I'm wrong, of course. Many of you
have already had the pleasure of convincing me I was wrong on other topics
:D ...

Spencer

* 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] <+46%2073%20078%2032%2089>
>
> [e-mail]
>
> www.ericsson.com
>
>
>
> The world is full of magical things patiently
>
>     waiting for our wits to grow sharper
>
>                Bertrand Russell
> ==================================
>
>
>