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

Hi, Igor,

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

> Thanks for the links to draft-ietf-tsvwg-ecn-experimentation, Spencer.
>

Thanks for the note and the questions.

> Reading the draft, I still see only the endpoints setting ECT(0|1)
> codepoints and ECN-supporting routers (network elements) potentially
> changing that ECT(0|1) to CE codepoint.
>
>
>
> Would an endpoint need any more feedback than “your ECT(0) and/or ECT(1)
> are getting through unbleached” (on this path)?
>

In my reply, I said, "I'm not the one doing the work on ECN experiments
(that's being handled by competent people)", so I'll let competent people
think about this :-)

Spencer

> If the sender marks all outgoing packets with ECT(0|1), there is no need
> to have a feedback on ECT(0|1) per packet (i.e.. bitmap).  It seems
> sufficient to only report: “first packet on this path had ECT(0|1)”.  Also,
> as a failsafe, I’d have a single report (sent once per connection per
> path): “Although the first packet on this path had ECT(0|1), I just
> received a packet ‘number #’ on this path with a non-ECT codepoint (i.e.
> this path is not reliable for ECN)”.
>
>
>
> Underlying assumptions for the above:
>
> (a) nothing “out there” will change ECT(0) → ECT(1) or ECT(1) → ECT(0).
>
> (b) Network elements either bleach both ECT(0) and ECT(1), or they do not
> bleach. If this assumption is incorrect, and we want to support endpoints
> that can decide to switch between ECT(0) and ECT(1) mid-connection, then a
> message “Reset ECN state for this path” would do the trick (the message
> would request the receiver to treat this packet as the first packet on the
> path).
>
>
>
> If there is a need for anything more complex (and more chatty) regarding
> ECT(0|1), what could it be?
>
>
>
>
>
> The bitmap in ACK_WITH_ECN frames that I had in mind was only for a
> feedback on packet groups with CE codepoints.
>
>
>
>    - Igor
>
>
>
>
>
>
>
> *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]
> *Sent:* Friday, December 01, 2017 10:54 AM
> *To:* Lubashev, Igor <ilubashe@akamai.com>
> *Cc:* lars@netapp.com; ingemar.s.johansson@ericsson.com;
> ecn-in-quic@ietf.org
>
> *Subject:* 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/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtsvwg-2Decn-2Dexperimentation_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=xg1zr0jOLWTjj-cSPLK_51Ha7SwkDwwx_qFhsVBRP70&s=SQGrmuSoLTXmMHbRi8L7-8M48zCS3eGPXaX4Qk-W-Ig&e=>
> to the RFC Editor three days ago, along with https://datatracker.ietf.
> org/doc/status-change-ecn-signaling-with-nonces-to-historic/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_status-2Dchange-2Decn-2Dsignaling-2Dwith-2Dnonces-2Dto-2Dhistoric_&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=xg1zr0jOLWTjj-cSPLK_51Ha7SwkDwwx_qFhsVBRP70&s=8mUV443N6WWYtpfO5wDDpQjmKrwatdoebuVlcC2puzs&e=>.
> 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
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ecn-2Din-2Dquic&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=xg1zr0jOLWTjj-cSPLK_51Ha7SwkDwwx_qFhsVBRP70&s=X-ccQS2eWjWH-dTJk_qB0YzYsWfI5O8spUkfnJW7jOo&e=>
>
>
>