Re: ECN in QUIC

[Ian Swett <[e-mail]>]

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/
>
>
>
>