Re: ECN in QUIC

[Colin Perkins <[e-mail]>]

> 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 <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]
> [e-mail] <mailto:[e-mail]>
> www.ericsson.com <x-msg://103/www.ericsson.com>
>  
> A mistake is to commit a misunderstanding
>                      Bob Dylan
> ==================================



-- 
Colin Perkins
https://csperkins.org/