Re: ECN in QUIC

["Brian Trammell (IETF)" <[e-mail]>]

> On 20 Sep 2017, at 16:30, Gorry Fairhurst <[e-mail]> wrote:
> 
> On 20/09/2017, 15:21, Frank Kastenholz wrote:
>> Hi
>> 
>> I wonder if the ACK can be kept simple by including only the ECN information from the most recently received packet, or maybe N (where N is fairly small) most recently received packets? This would reduce the amount of information to be carried as well as the complexity of including it.
>> 
>> I confess that I am not familiar with the various congestion control algorithms ... but I would imagine that more recent ECN information would be more useful than older ECN info. No?
> No - there are two styles of ECN CC. The more recent requires accurate feedback of the ECN marks - think of this more as understanding the "rate of marking from the bottleneck" and in some case "was this (test) packet marked". This requires per-packet ECN info - at least one bit per received packet, and preferably 2 bits.

I'll also note that AccECN (draft-ietf-tcpm-accurate-ecn) would seem to be far easier to add to QUIC than to TCP. In the TCP case, it needs to reallocate a flag bit and add an option, both of which need to be defensively specified against path interference, *all* of which simply go away when the information is carried in encrypted QUIC ACK frames.

AccECN also shows the way to handle the recency of information issues raised above: the counters echoed are all the least significant N bits of a cumulative counter, which is both recent and robust against ACK loss.

Cheers,

Brian

> Gorry
> 
>> 
>> Frank Kastenholz
>> 
>> On Wed, Sep 20, 2017 at 9:27 AM, Ingemar Johansson S <[e-mail] <mailto:[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]
>>    <mailto:[e-mail]>]
>>    *Sent:* den 20 september 2017 14:41
>>    *To:* Ingemar Johansson S <[e-mail]
>>    <mailto:[e-mail]>>
>>    *Cc:* Colin Perkins <[e-mail]
>>    <mailto:[e-mail]>>; Magnus Westerlund
>>    <[e-mail]
>>    <mailto:[e-mail]>>; Bob Briscoe
>>    ([e-mail] <mailto:[e-mail]>)
>>    <[e-mail] <mailto:[e-mail]>>;
>>    Praveen Balasubramanian <[e-mail]
>>    <mailto:[e-mail]>>; Eggert, Lars ([e-mail]
>>    <mailto:[e-mail]>) <[e-mail]
>>    <mailto:[e-mail]>>; marcelo bagnulo braun
>>    <[e-mail] <mailto:[e-mail]>>; Mirja Kühlewind
>>    <[e-mail]
>>    <mailto:[e-mail]>>; Piers O'Hanlon
>>    <[e-mail] <mailto:[e-mail]>>;
>>    QUIC IETF mailing list <[e-mail] <mailto:[e-mail]>>; De
>>    Schepper, Koen (Nokia - BE/Antwerp)
>>    <[e-mail]
>>    <mailto:[e-mail]>>
>> 
>> 
>>    *Subject:* Re: ECN in QUIC
>> 
>>    On Wed, Sep 20, 2017 at 4:39 AM, Ingemar Johansson S
>>    <[e-mail]
>>    <mailto:[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]
>>        <mailto:[e-mail]>]
>>        *Sent:* den 16 augusti 2017 12:53
>>        *To:* Ingemar Johansson S <[e-mail]
>>        <mailto:[e-mail]>>
>>        *Cc:* QUIC IETF mailing list <[e-mail]
>>        <mailto:[e-mail]>>; Magnus Westerlund
>>        <[e-mail]
>>        <mailto:[e-mail]>>; Bob Briscoe
>>        ([e-mail] <mailto:[e-mail]>)
>>        <[e-mail] <mailto:[e-mail]>>;
>>        Praveen Balasubramanian <[e-mail]
>>        <mailto:[e-mail]>>; Eggert, Lars ([e-mail]
>>        <mailto:[e-mail]>) <[e-mail]
>>        <mailto:[e-mail]>>; marcelo bagnulo braun
>>        <[e-mail] <mailto:[e-mail]>>; Mirja
>>        Kühlewind <[e-mail]
>>        <mailto:[e-mail]>>; Piers O'Hanlon
>>        <[e-mail]
>>        <mailto:[e-mail]>>; De Schepper, Koen (Nokia
>>        - BE/Antwerp) <[e-mail]
>>        <mailto:[e-mail]>>
>>        *Subject:* Re: ECN in QUIC
>> 
>>            On 16 Aug 2017, at 10:33, Ingemar Johansson S
>>            <[e-mail]
>>            <mailto:[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
>>            <https://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] <tel:+46%2073%20078%2032%2089>
>> 
>>            [e-mail]
>>            <mailto:[e-mail]>
>> 
>>            www.ericsson.com <http://www.ericsson.com>
>> 
>>            A mistake is to commit a misunderstanding
>>                                 Bob Dylan
>>            ==================================
>> 
>> 
>> 
>>        --         Colin Perkins
>>        https://csperkins.org/
>> 
>> 
>> 
>> 
>> --
>> Thanks
>> Frank Kastenholz
>> 
>