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

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

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)?  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<mailto: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<mailto:ingemar.s.johansson@ericsson.com>]
Received: Friday, 01 Dec 2017, 7:46AM
To: Eggert, Lars [lars@netapp.com<mailto:lars@netapp.com>]
CC: ecn-in-quic@ietf.org<mailto:ecn-in-quic@ietf.org> [ecn-in-quic@ietf.org<mailto: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<mailto:lars@netapp.com>]
Sent: den 1 december 2017 11:23
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com<mailto:ingemar.s.johansson@ericsson.com>>
Cc: ecn-in-quic@ietf.org<mailto: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<mailto: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<mailto: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=>