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

["De Schepper, Koen (Nokia - BE/Antwerp)" <[e-mail]>]

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

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

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:[e-mail]]
Sent: den 1 december 2017 18:24
To: Spencer Dawkins at IETF <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Ingemar Johansson S <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: 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:[e-mail]]
Sent: Friday, December 01, 2017 10:54 AM
To: Lubashev, Igor <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Ecn-in-quic] ECN ACK, bytes or packets

Hi, Igor,

On Fri, Dec 1, 2017 at 7:04 AM, Lubashev, Igor <[e-mail]<mailto:[e-mail]>> 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 [[e-mail]<mailto:[e-mail]>]
Received: Friday, 01 Dec 2017, 7:46AM
To: Eggert, Lars [[e-mail]<mailto:[e-mail]>]
CC: [e-mail]<mailto:[e-mail]> [[e-mail]<mailto:[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]<mailto:[e-mail]>]
Sent: den 1 december 2017 11:23
To: Ingemar Johansson S <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[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


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