Re: ECN in QUIC

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

> On 24 Jan 2018, at 23:53, Lubashev, Igor <[e-mail]> wrote:
> 
> I think I like a per-packet bitmap.  If you are ACKing 30 packets, it is only 8 bytes.  The advantage of per-packet bitmap is that you do not need to split ACK Blocks – savings right there.

I'll also note that in the current Internet case (no L4S or DCTCP, sporadic deployment of CE-marking routers), there are opportunities for large savings with the bitmap approach through trivially simple compression (maybe even as simple as a special representation for "all of these packets were 0/ECT0/ECT1").

Cheers,

Brian

> 	• Igor
> 
> From: Christian Huitema [mailto:[e-mail]]
> Sent: Wednesday, January 24, 2018 4:38 PM
> To: Ingemar Johansson S <[e-mail]>; Lubashev, Igor <[e-mail]>; QUIC WG <[e-mail]>
> Cc: Bob Briscoe ([e-mail]) <[e-mail]>; [e-mail]
> Subject: Re: ECN in QUIC
> 
> 
> 
> 
> On 1/24/2018 10:51 AM, Ingemar Johansson S wrote:
> Hi
> 
> Comment on “CE is not going to be a very common occurrence”.
> While that may be true for (almost) drop equivalent ECN (a.k.a. classic), it does unfortunately not hold at all for L4S. Typical values of ECN marking ratio with L4S is in the order of 10 to 50%. In addition the CE marks can be spread randomly (for instance with phantom queues).
> This means that the ACK blocks in the suggested format below can become very short, in the worst case representing only one packet per ACK block if we have an alternating ECT-CE-ECT-CE… pattern in the received packets.
> Yes.
> 
> 
> So my take is that if an ECN bit pattern is really necessary then it is better to have it as an bitmap that represents all packets that are listed in the ACK block. If one make an assumption that an ACK frame contains two ACK blocks that ACKs 5 and 7 packets then the ECN block will become (5+7)*2 = 24bits , i.e. 3 octets.
> Yes, we have to take that into account in the design.
> 
> 
> But with that said I am still not convinced that the packet counter approach is flawed (I’m am happy to be enlightened 😊) .
> Taking multipath as an example : Isn’t it the case that two connections are setup, each with its own congestion control context (I omit coupled CC for the moment). If that is the case then I don’t see any problem with the packet counters.
> 
> We are heading towards a single packet sequence number space shared by multiple paths. That means that we need precise per packet feedback. If a packet was marked with CE, you want to know on which path, and the way to know that is to find the "path" tag in the saved copy of the packet. You cant do that with counters.
> 
> 
> As regards to connection migration. One possible matter is that it can become tricky to detect ECN bleaching or ECN bit access problems in OS immediately , however during the course of 1 RTT or even less, this should be possible to detect as e.g. ECN bleaching will result in that the neither on the ECT(0),ECT(1) and CE counters increase. But I am fully aware that I may miss things here.
> 
> Again, there is no problem if we have precise per packet feedback, because we can find out which packets were bleached.
> 
> -- Christian Huitema
>