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

Hi, Igor,

On Fri, Dec 1, 2017 at 7:04 AM, Lubashev, Igor <ilubashe@akamai.com> wrote:

> 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.
>

Speaking as the AD for TSVWG - I sent
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-experimentation/ to
the RFC Editor three days ago, along with
https://datatracker.ietf.org/doc/status-change-ecn-signaling-with-nonces-to-historic/.
These two actions mean that the original meaning of ECT(1) in RFC 3168 as
"same as ECT(0)" has been deprecated. I'm betting that some QUIC folk have
noticed that, and others may have not.

Asking as an individual - Ingemar was pretty careful in his note to
distinguish between packet groups marked with ECT(0) and packet groups
marked with ECT(1).  I'm reading "a bitmap" in your thought 1. and
wondering if you meant "two bitmaps".

I'm not the one doing the work on ECN experiments (that's being handled by
competent people), but my understanding is that we're likely to end up with
standards-track interpretations of ECT(1) that aren't the same as the
current interpretation of ECT(0), after an appropriate amount of
experimenting, so I'd think it's better to track them separately in QUIC,
from the beginning, if you're going to track them in QUIC.

Thanks,

Spencer, who is furiously trading hats while typing ....

>
> 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 [ingemar.s.johansson@ericsson.com]
> *Received:* Friday, 01 Dec 2017, 7:46AM
> *To:* Eggert, Lars [lars@netapp.com]
> *CC:* ecn-in-quic@ietf.org [ecn-in-quic@ietf.org]
> *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:lars@netapp.com]
> *Sent:* den 1 december 2017 11:23
> *To:* Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> *Cc:* ecn-in-quic@ietf.org
> *Subject:* Re: [Ecn-in-quic] ECN ACK, bytes or packets
>
>
>
> On 2017-12-1, at 11:02, Ingemar Johansson S <ingemar.s.johansson@ericsson.
> com> 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
>
>
>
> _______________________________________________
> Ecn-in-quic mailing list
> Ecn-in-quic@ietf.org
> https://www.ietf.org/mailman/listinfo/ecn-in-quic
>
>