Re: [Ecn-in-quic] ECN ACK, bytes or packets

["Lubashev, Igor" <[e-mail]>]

I was thinking of doing my own cut at a draft, but I keep not finding a sufficiently large block of time for it. :-( So here are some thoughts I had.

1. We should neither report bytes nor packets for CE. Instead, we should have a frame ACK-WITH-CE which is just like ACK frame but also includes a bitmap to indicate which packet groups being ACKed had CE markers and which did not. That frame would only be used if any packets had CE makings.

2. For each new path, we emit a new frame bash to that path that confirms that ECN makings were present in the first packet from that path. That could be in the same packet as the "path probe". If suddenly we receive a packet with ECN bleached from a path that used to have ECN makings, we emit a frame to that effect.

It does not look like much of anything else is needed. The byte counts are not needed on the wire, since the endpoints know packet sizes they sent, so simply by knowing which packets had CE makings, they can compute bytes, if they desire. Also, the end points may wish to know when they can reply on ECN feedback and when not (ECN bits are reaching the other endpoint reliably or not). I doubt that we need to report that 37% of ECN packets are being bleached -- this is a highly unlikely situation and can be treated as a single bit "ECN is not reliable here" piece of information.

- Igor

-----Original Message-----
From: Ingemar Johansson S [[e-mail]]
Received: Friday, 01 Dec 2017, 7:46AM
To: Eggert, Lars [[e-mail]]
CC: [e-mail] [[e-mail]]
Subject: Re: [Ecn-in-quic] ECN ACK, bytes or packets

Hi
Yes, my intention was to highlight the use of variable-length integer encoding. Obviously it was not that clear ?
/Ingemar

From: Eggert, Lars [mailto:[e-mail]]
Sent: den 1 december 2017 11:23
To: Ingemar Johansson S <[e-mail]>
Cc: [e-mail]
Subject: Re: [Ecn-in-quic] ECN ACK, bytes or packets

On 2017-12-1, at 11:02, Ingemar Johansson S <[e-mail]<mailto:[e-mail]>> wrote:
+ If the two tweaks above are possible then we would end up with something like
  + 1 byte for ECT(0), with the special 2 bit encoding we are then able to encode a delta of [0...63] ECT(0] marked packets
  + 1 byte for ECT(1), same encoding as above.
  + 2 or 4 bytes for CE, the most likely encoding that makes it possible to encode a delta of [0..16383] CE marked bytes or [0...2*30-1], the latter is more likely used with large MTU sizes and in some cases also when packets are densely marked (L4S)

We are going to varint encoding almost everywhere in QUIC; see https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.8.1<https://urldefense.proofpoint.com/v2/url?u=https-3A__quicwg.github.io_base-2Ddrafts_draft-2Dietf-2Dquic-2Dtransport.html-23rfc.section.8.1&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=d15wMtMOmTxCnIazi4Jr0lWZR5Sz177mQ0wArW6A8nQ&s=aEFjIdCcgpaiWFkXrFryTqGXWCXKM5bvupRpY1ffvaU&e=>

Lars