Re: ECN in QUIC

[Ian Swett <[e-mail]>]

I think there are good reasons to keep frames smaller and simpler in
general.  But in this particular case, I think there are strong arguments
for putting ECN in the ACK frames.  I suspect this would have come up as
soon as someone implemented ECN in QUIC.

On Wed, Sep 20, 2017 at 9:27 AM, Ingemar Johansson S <
[e-mail]> wrote:

> Thanks Ian for the prompt response.
>
> I must admit that I have perhaps overlooked possible combos of loss and
> ECN, the price you pay for working too much with simulators. Your arguments
> are very strong indeed.
>
>
>
> In the SCReAM congestion control (RMCAT work) the ECN and loss info comes
> in the same feedback and the handling of loss and ECN is straightforward
> there. Personally I would prefer ECN in the ACK frames and the earlier
> drafts suggested formats for that, I however got the impression that there
> is a certain resistance against additional things in the ACK frame ?.
>
>
>
> /Ingemar
>
>
>
> *From:* Ian Swett [mailto:[e-mail]]
> *Sent:* den 20 september 2017 14:41
> *To:* Ingemar Johansson S <[e-mail]>
> *Cc:* Colin Perkins <[e-mail]>; Magnus Westerlund <
> [e-mail]>; Bob Briscoe ([e-mail]) <
> [e-mail]>; Praveen Balasubramanian <[e-mail]>;
> Eggert, Lars ([e-mail]) <[e-mail]>; marcelo bagnulo braun <
> [e-mail]>; Mirja Kühlewind <[e-mail]>;
> Piers O'Hanlon <[e-mail]>; QUIC IETF mailing list <
> [e-mail]>; De Schepper, Koen (Nokia - BE/Antwerp) <
> [e-mail]>
>
> *Subject:* Re: ECN in QUIC
>
>
>
>
>
> On Wed, Sep 20, 2017 at 4:39 AM, Ingemar Johansson S <
> [e-mail]> wrote:
>
> Hi
>
>
>
> And sorry for the sloth-ish response (you should see me type  a text
> message..).
>
> To summarize the two main questions
>
>
>
>    1. ECN in ACK frame or in a separate frame : Given the recent
>    discussion on the list and fear that the ACK frame is already enough
>    complex, it seems unwise to try to cram in additional info in the ACK
>    frames. So my personal feeling is that we should use a separate frame type
>    for ECN , but this frame type must be a MUST to implement and support !
>    Comments are very welcome.
>
> I was neutral on this before, but I started thinking about implementing
> this, and separating the frames makes it more complex, and potentially
> really, really difficult to get the implementation correct.  As an example,
> if the frames were accidentally sent in two separate packets, I would count
> the packet as acked, and potentially increase the congestion window and
> other state variables.  I might even send an extra packet based on this
> information.  Then in the next packet I'd realize that packet had an ECN
> marking, and actually should have been treated as lost from a congestion
> controller perspective.  In order to do this correctly, I'd have to undo a
> bunch of things.  My experience with undo is that it's terribly error
> prone, and I would never recommend it.
>
>
>
> Alternately, the ack could get lost, and the next packet would convey ECN
> marking information for packets that hadn't been acknowledged yet.  Which
> is just weird.
>
>
>
> If we require support for ECN, then the implementation has a certain extra
> level of complexity.  As illustrated above, putting it in one frame is
> actually simpler overall if the congestion controller needs to use all the
> information at once to be implemented correctly.  This same logic applies
> to timestamps as well, in my opinion.
>
>
>
>
>    1.
>    2. As regards to the level of detail : There are pros and cons with
>    both alternatives (marked bytes or detailed indication). I would like to
>    hear the opinions from others as well on this matter .
>
>
>
> /Ingemar
>
>
>
> *From:* Colin Perkins [mailto:[e-mail]]
> *Sent:* den 16 augusti 2017 12:53
> *To:* Ingemar Johansson S <[e-mail]>
> *Cc:* QUIC IETF mailing list <[e-mail]>; Magnus Westerlund <
> [e-mail]>; Bob Briscoe ([e-mail]) <
> [e-mail]>; Praveen Balasubramanian <[e-mail]>;
> Eggert, Lars ([e-mail]) <[e-mail]>; marcelo bagnulo braun <
> [e-mail]>; Mirja Kühlewind <[e-mail]>;
> Piers O'Hanlon <[e-mail]>; De Schepper, Koen (Nokia -
> BE/Antwerp) <[e-mail]>
> *Subject:* Re: ECN in QUIC
>
>
>
>
>
> On 16 Aug 2017, at 10:33, Ingemar Johansson S <
> [e-mail]> wrote:
>
>
>
> Hi
>
>
>
> Finally back from vacation, and very grateful for the support to continue
> the work to add ECN in QUIC.
>
> Just to recap.. there were two main topics raised at the meeting
>
>
>
> 1) ECN info in ACK frame or in dedicated frame : There were concerns about
> adding extra complexity in an already potentially complex ACK frame, one
> can have differing opinions about the complexity but can understand the
> concerns. As far as I am concerned, a separate frame type for ECN is
> possible, possibly one need to add information about the amount of not-ECT
> marked packets as well to keep the signaling robust, this needs further
> investigation though. One concern with a separate ECN frame is that it
> becomes a not-implemented or optional feature, is there any reason to be
> worried about this ?
>
>
>
> 2) More detailed ECN information : Earlier versions of the ECN in QUIC
> draft (seehttps://tools.ietf.org/id/draft-johansson-quic-ecn-01.txt )
> provided with examples. We (Myself, Koen, Mirja and Praveen) discussed this
> and we could not come up with any use case where it is beneficial to know
> exactly how each packet is ECN marked. I know that this kind of detailed
> ECN information is suggested for the generic feedback for RMCAT and I
> personally have a problem to see the gain with the detailed ECN information
> also here. Input from others is very welcome here.
>
>
>
> For the RMCAT format, we wanted per-packet loss and timing information,
> and it was as easy to feedback per-packet ECN information along with it as
> to design something different.
>
>
>
> A benefit of per-packet ECN marking could be to allow a congestion
> controller that reacted differently to bursts of consecutive ECN marks than
> it did to isolated ECN marks, given the same fraction of marked packets
> (i.e., that reacted to ECN marking events rather than ECN marking rate,
> like how TCP responds to loss events). I don’t think we have such a thing,
> but certainly in the context of RMCAT where we’re experimenting with novel
> congestion control schemes for traffic that has very different
> characteristics to traditional bulk flows, it might be plausible.
> Per-packet marking information is also useful for troubleshooting.
>
>
>
> Certainly we need to know number of NotECT, ECT(0), ECT(1), and ECN-CE
> marks since the last report, but I guess that’s already possible.
>
>
>
> Cheers,
>
> Colin
>
>
>
>
>
>
>
>
>
> There are a consequences with detailed ECN marking information.
>
> a) necessary to correlate with the list of transmitted packets, this
> increases amount of code on sender side, not sure of that is a large
> concern as lookup is anyway needed to process incoming ACKs
>
> b) necessary to embed ECN information in ACK frame ?, at least this was my
> conclusion when I devised the detailed ECN marking info in the 01 version
> of the draft.
>
>
>
> Comments are welcome
>
> /Ingemar
>
>
>
>
>
>
>
> ==================================
>
> Ingemar Johansson  M.Sc.
>
> Master Researcher
>
>
>
> Ericsson AB
>
> Wireless Access Networks
>
> Labratoriegränd 11
>
> 971 28, Luleå, Sweden
>
> Phone [phone]
>
> SMS/MMS [phone] <+46%2073%20078%2032%2089>
>
> [e-mail]
>
> www.ericsson.com
>
>
>
> A mistake is to commit a misunderstanding
>                      Bob Dylan
> ==================================
>
>
>
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>
>