Re: ECN in QUIC

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

hi Ian, all,

delurking momentarily to say...

> On 20 Sep 2017, at 14:41, Ian Swett <[e-mail]> wrote:
> 
> 
> 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
>> 
>> 	• 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.

What Ian said. This is a tradeoff between complexity in frame structure (and therefore frame parsing) and complexity in handling congestion control dynamics in an environment in which we'll be receiving both loss and explicit congestion control signaling. Careful design of the frame structure and decent testing can mitigate the risk that the former will cause problems. The latter is a scary swamp filled with nightmares no matter what you do.

Cheers,

Brian

> 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.
> 
> 	• 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]
> 
> [e-mail]
> 
> www.ericsson.com
> 
> 
> 
> A mistake is to commit a misunderstanding
>                      Bob Dylan
> ==================================
> 
> 
> 
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
> 
> 
>