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

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 1 Dec 2017 10:02:07 +0000

Hi

At the ECN-QUIC side meeting it was discussed whether byte or packets counters are to prefer, but I don't think that we came to any conclusion.
In any case I have a few thoughts around this

+ Byte counter for CE but only packet counter for ECT(1) and ECT(0):
Now with draft-ietf-tsvwg-ecn-experimentation in its final stages, I don't see the benefit with counting number of bytes that are ECT(0) and ECT(1) marked as I think that this information is only used to check that packets are correctly marked/remarked. This would limit the size of the ECT(0) and ECT(1) fields quite small

+ Delta values: It was argued that ACKs are ACKed , this means that one can report deltas and thus potentially save some overhead. Reading section 8.14 in the quic transport draft I believe that I have convinced myself that this is indeed possible.

+ 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)

Comments are welcome
/Ingemar

==================================
Ingemar Johansson  M.Sc.
Master Researcher

Ericsson Research
Network Protocols & E2E Performance
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]<mailto:[email-masked]>
www.ericsson.com

The world is full of magical things patiently
    waiting for our wits to grow sharper
               Bertrand Russell
==================================

---

From: "Eggert, Lars" <[email-masked]>
Date: Fri, 1 Dec 2017 10:23:27 +0000

On 2017-12-1, at 11:02, Ingemar Johansson S <[email-masked]> wrote:
>   + 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

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://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.8.1>

Lars

---

From: Ingemar Johansson S <[email-masked]>
Date: Fri, 1 Dec 2017 12:45:44 +0000

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:[email-masked]]
Sent: den 1 december 2017 11:23
To: Ingemar Johansson S <[email-masked]>
Cc: [email-masked]
Subject: Re: [Ecn-in-quic] ECN ACK, bytes or packets

On 2017-12-1, at 11:02, Ingemar Johansson S <[email-masked]<mailto:[email-masked]>> wrote:

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

Lars

---

From: "Lubashev, Igor" <[email-masked]>
Date: Fri, 1 Dec 2017 13:04:03 +0000

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 [[email-masked]]
Received: Friday, 01 Dec 2017, 7:46AM
To: Eggert, Lars [[email-masked]]
CC: [email-masked] [[email-masked]]
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

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

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 1 Dec 2017 09:53:38 -0600

Hi, Igor,

On Fri, Dec 1, 2017 at 7:04 AM, Lubashev, Igor <[email-masked]> 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
>
> *From:* Ingemar Johansson S [[email-masked]]
> *Received:* Friday, 01 Dec 2017, 7:46AM
> *To:* Eggert, Lars [[email-masked]]
> *CC:* [email-masked] [[email-masked]]
> *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:[email-masked]]
> *Sent:* den 1 december 2017 11:23
> *To:* Ingemar Johansson S <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Ecn-in-quic] ECN ACK, bytes or packets
>
>
>
>   + 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
>
>   + 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecn-in-quic
>
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Fri, 1 Dec 2017 17:23:47 +0000

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:[email-masked]]
Sent: Friday, December 01, 2017 10:54 AM
To: Lubashev, Igor <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Ecn-in-quic] ECN ACK, bytes or packets

Hi, Igor,

On Fri, Dec 1, 2017 at 7:04 AM, Lubashev, Igor <[email-masked]<mailto:[email-masked]>> 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.

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,

- Igor

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

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

Lars

_______________________________________________
Ecn-in-quic mailing list
[email-masked]<mailto:[email-masked]>
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=>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 1 Dec 2017 11:57:17 -0600

Hi, Igor,

> 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)”.
>
>
>
> (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).
>
>
>
> 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:[email-masked]]
> *Sent:* Friday, December 01, 2017 10:54 AM
> *To:* Lubashev, Igor <[email-masked]>
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
>
> 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=>.
> <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=>
>
>
>

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 4 Dec 2017 08:22:57 +0000

Hi

The bytes (or packets) counter or a bitmap that indicates which packets are marked e.g. CE topic was discussed earlier
https://github.com/quicwg/base-drafts/issues/805 and I interpret that discussion to be in favor of a counter even though no agreement was reached.
We need to settle this matter in a near future. The alternatives are

  1.  Bitmap that indicates CE marked packets
  2.  Counter for CE marked packets, mostly 1 octet. Variable-length integer encoding.
  3.  Counter for CE marked bytes, mostly, 1 or 2 octets, sometimes 4 octets. Variable-length integer encoding.
The counters indicate the delta increase

Regarding the necessity to count ECT(0) and ECT(1) packets, my take here is that it is a good to have to be able to monitor for possible odd and forbidden re-markings that makes ECN unreliable as a congestion signal. The cost is (mostly) one octet for ECT(0) and one octet for ECT(1).
It is of course possible to implement a single report per connection per path, It would save two bytes ACK+ECN overhead but I wonder if it makes the specification more complex ?.

/Ingemar

From: Lubashev, Igor [mailto:[email-masked]]
Sent: den 1 december 2017 18:24
To: Spencer Dawkins at IETF <[email-masked]>
Cc: [email-masked]; Ingemar Johansson S <[email-masked]>; [email-masked]
Subject: RE: [Ecn-in-quic] ECN ACK, bytes or packets

  *   Igor

From: Spencer Dawkins at IETF [mailto:[email-masked]]
Sent: Friday, December 01, 2017 10:54 AM
To: Lubashev, Igor <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecn-in-quic] ECN ACK, bytes or packets

Hi, Igor,

Thanks,

- Igor

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

Lars

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 8 Dec 2017 12:23:16 +0000

Ingemar,
Sorry for the silence up to now. I have been looking at the quic draft in the mean time because I think the solution depends on this.
What I understood today is that ACKs for packets are send and partially resend for a moving range (with gaps) of packet sequence numbers. What we want to avoid is that the receiver has to play a game of Mastermind to reproduce the running counters... So I'm still not sure if we can use a delta counter that maps to the acked packets. I think an independent delta that is send once for the new delta can be sent, that needs to be acked, but I'm not sure if the retransmit scheme/scenarios is not going to be too complex. Also how to reproduce the not-ecn packets/bytes that maps to the other counters is also a potential painpoint.
Did anyone do some scenarios on these ideas already? Unless someone says I have a solution for all your worries I need to go through some detailed scenarios to convince myself.
Related to the packet / byte question, my intuition says keep them all the same. As we have a packet sequence number, we could also work with packet counters that map to this... for me getting very simply the probability is enough. I agree we should think further and having a generic flexible mechanisms is preferred, so packet counters are a good consensus. As the network should mark all packets with the same probability, counting marked packets should not be worse than counting bytes. I think it will also remove the ambiguity of whether only data bytes, or header bytes, or whatever need to be taken into account. If a sender needs to know how many data bytes were marked, he can reapply the calculated probability on whatever bytes he want to take into account (by a simple multiplication of bytes*p).
I also did some changes to the wiki description. I prefer the name capability "check", as "negotiation" sounds too complex for what it is. I think the structure could be to define a generic ecn-echo functionality in the receiver, which is the only receiver side functionality I think is needed. Then a first sender functionality which uses the receiver ecn-echo is the ecn capability check. I think we could also describe how an ecn based congestion control may make use of the generic ecn-echo to facilitate ecn experiments.
Regards,
Koen.

From: Ecn-in-quic [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
Sent: Monday, December 4, 2017 9:23 AM
To: Lubashev, Igor <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecn-in-quic] ECN ACK, bytes or packets

Hi

/Ingemar

From: Lubashev, Igor [mailto:[email-masked]]
Sent: den 1 december 2017 18:24
To: Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Ingemar Johansson S <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Ecn-in-quic] ECN ACK, bytes or packets

  *   Igor

Hi, Igor,

Thanks,

- Igor

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

Lars

---

From: "De Schepper, Koen (Nokia - BE/Antwerp)" <[email-masked]>
Date: Fri, 8 Dec 2017 15:39:16 +0000

Hi all,

Some (wild/rough) ideas that could help in reducing overhead (assuming we send packet counters for ecn-echo):

  *   We can omit one counter, because we can derive it from the ACKed packet sequence numbers minus other counters, right? If we have to choose, we want to suppress the counter which increments/changes most, as that one results in most overhead. As we don’t know upfront which one it is (because we want to be generic and support any future scheme, and even for the current known use, it might be not-ECT or ECT(x) or even CE), we should allow the sender to select the counter(s) he want to suppress (once) during a point in the connection. How exactly to do this in a save way (which and how many counters are echoed in a packet) is to be discussed (via selection of different frame types, or …). So initially all counters should be returned, and there should be a suppress/select message to disable a/some counter(s).

  *   As an alternative to delta counters, can we use running counters with an additional “decrement offset” sender command, to reduce (kind of acknowledge) an amount for the counters? It is intended as an offset on top of which the counters need to be reported. This allows to keep the variable length counters small. A sender can detect that the counter is applied when it is reduced accordingly (so it should be large enough to avoid roll-overs during several RTTs). The advantage of an offset is that it can be retransmitted without ambiguity or double execution. Maybe this idea could also be used for other counters in the quic protocol (like the packet sequence number)? I guess this command could be an optional extension/optimization in a next QUIC version too.

Further thoughts are needed to make sure we can safely apply these optimizations (if benefits are bigger than risk/complexity). I assume other safety issues are present in current QUIC messaging, and the QUIC specialists on this list have experience how best and safest handle such schemes.

Regards,
Koen.

From: Ecn-in-quic [mailto:[email-masked]] On Behalf Of De Schepper, Koen (Nokia - BE/Antwerp)
Sent: Friday, December 8, 2017 1:23 PM
To: Ingemar Johansson S <[email-masked]>; Lubashev, Igor <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Ecn-in-quic] ECN ACK, bytes or packets

Ingemar,

From: Ecn-in-quic [mailto:[email-masked]] On Behalf Of Ingemar Johansson S
Sent: Monday, December 4, 2017 9:23 AM
To: Lubashev, Igor <[email-masked]<mailto:[email-masked]>>; Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Ecn-in-quic] ECN ACK, bytes or packets

Hi

/Ingemar

  *   Igor

Hi, Igor,

Thanks,

- Igor

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

Lars

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 11 Dec 2017 14:52:12 +0000

Hi

And thanks for the response.
Assuming that it is sufficient with packet counters I believe that it should be a sufficiently low packet overhead with counters for ECT(0),ECT(1) and CE. These will be mostly 1 byte each encoded as variable length integers.
Regarding the delta values or running counters, I still feel that if should be possible to use delta values. I tried to summarize it in the ECN Wiki as shown below, would this work ?
“ACK frames are not retransmitted QUIC packetization and reliability<https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#rfc.section.9>. This means that the ECT(0), ECT(1) and CE deltas for each transmitted ACK frame should be stored until the ACK frame is ACKed. If an ACK frame is deemed lost, then the delta values should be added to the delta values of the next ACK frame to be transmitted”

If running counters are needed, I think that it should be possible to use longer formats for the counters only when the counters are about to wrap around the 6bit, 14bit and 30bit boundary. For instance if he least 6 significant bits wrap around, then the 2 octet counter is used for a couple of ACK frames, if the 14 LSB wrap around then the 4 octet counter is used for couple of ACKs. This way the counters will be mostly 1 octet, rarely 2 octets, and very very rarely 4 octets.

/Ingemar

From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto:[email-masked]]
Sent: den 8 december 2017 16:39
To: De Schepper, Koen (Nokia - BE/Antwerp) <[email-masked]>; Ingemar Johansson S <[email-masked]>; Lubashev, Igor <[email-masked]>; Spencer Dawkins at IETF <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Ecn-in-quic] ECN ACK, bytes or packets

Hi all,

Regards,
Koen.

To: Ingemar Johansson S <[email-masked]<mailto:[email-masked]>>; Lubashev, Igor <[email-masked]<mailto:[email-masked]>>; Spencer Dawkins at IETF <[email-masked]<mailto:[email-masked]>>

Ingemar,

Hi

/Ingemar

  *   Igor

Hi, Igor,

Thanks,

- Igor

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

Lars