RE: ECN in QUIC

[Ingemar Johansson S <[e-mail]>]

Hi
Detailed info about which packets are ECN marked can be useful but are not stricktly necessary. One alternative, that is presented in the ECN-QUIC draft is to count number of marked bytes. 
That said, some like the detailed packet-level information type better. I have not yet been convinced that that this level of detail is necessary though. 

/Ingemar

> -----Original Message-----
> From: Gorry Fairhurst [mailto:[e-mail]]
> Sent: den 20 september 2017 16:30
> To: Frank Kastenholz <[e-mail]>
> Cc: Ingemar Johansson S <[e-mail]>; Magnus
> Westerlund <[e-mail]>; Bob Briscoe
> ([e-mail]) <[e-mail]>; Praveen
> Balasubramanian <[e-mail]>; Ian Swett
> <[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]>; Colin
> Perkins <[e-mail]>; De Schepper, Koen (Nokia - BE/Antwerp)
> <[e-mail]>
> Subject: Re: ECN in QUIC
> 
> 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.
> 
> 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
> >