Re: [tcpm] WGLC for draft-ietf-tcpm-accurate-ecn-23

[Markku Kojo <[e-mail]>]

Hi Richard, all,

Apologies for the delay with scenarios. It took way too long but 
there were a lot to describe with my limited cycles as you see below. So, 
my apologies for the very long text too. This relates also (if not 
mainly) to ECN++, but I did not even try to separate it as I don't know 
anymore what is intended to be specified where, sorry.

TL;DR;

There are a number of existing widely deployed and crucial TCP loss 
detection and recovery as well as congestion control mechanisms that 
either break or operate undesireably with Acks of Acks as proposed in 
this draft. If an existing mechanism does not break, it mainly behaves 
too aggressively and hurts others. Using seems to solve the issuea but 
without it Acks of Acks must be disabled in one way or the other.

It also seems that Acks of Acks are mostly unnecessary and do not help 
much in terms of providing more timely feedback. Therefore, I hope that 
wg would carefully consider whether it is reasonable to have a stds track
document with a behavior that in most cases injects additional packets to 
the network unnecessarily and thereby does not honor the well-known 
principle of "be conservative in what you send".


Please find a few scenarios related to the problems with Acks of Acks 
available at:

  https://www.cs.helsinki.fi/u/kojo/IETF/AccECN2023.pdf

Please see inline and below my replies and comments as well as 
description on the problems with Acks of Acks in the scenarios and in 
some other occassions as well.

On Mon, 27 Mar 2023, [e-mail] wrote:

> Hi Markku,
>
> First, the AccECN draft tries to keep both the sender's and the
> receiver's representation of the expirienced CE counter in sync.
>
> Once ECN++ is used, with pure ACKs being marked as ECT, there is a
> probability of these pure ACKs to be maked CE.
>
> In other words - without ECN++, pure ACKs are not ECT-marked, and thus
> would never increment the CE counter - which needs conveying.

This is all clear. Given that the ECT-marked pure Acks are present only in 
experiments (ECN++ or maybe some others), why does this stds track 
document even mention them and the need to send Acks of Acks which are 
not part of the stds track protocol but only valid with experiments 
like ECN++  Handling CE-marked pure Acks is clearly experimental and it 
seems too early and unmature to decide how to best convey feedback on 
them in a stds track protocol. Experimental protocol would be different 
but I don't want to open that discussion, wg has made its decision.

> Now, CE-on-ACK:
>
> As long as the side receiving the CE-marked ACK has any more data
> outstanding to be sent - the incremented ACE counter will be
> piggy-backed on this new data packet. Further, the text in the AccECN
> draft is also written in a way that this incremented ACE counter does
> *NOT* need immediate reflection, but rather may increase by at least 3.
>
> So, as long as either half-connection has more data to send, there is
> no risk of any ACK-on-ACK ping-pong, even when all the pure ACKs on one
> half-connection get CE marked.
> The only point in the evolution of a TCP session, where ACK-on-ACK could
> be expected is when
>
> Host A no longer has any data (new, or retransmissions) to transmit
> Host B no longer has any data (new, or retransmissions) to transmit
> The Path for *both* Half-Connections experience severe congestion
> (100% CE marking probability on the pure ACKs).

This all clear but sounds like a bit limited view of the possible 
scenarios. There are several variations of bidirectional data 
transmission where sending data alternates between the end points, e.g., 
with a typical request-reply type of application behaviour. Please see my 
discussion on my  Fig. 2 towards the end.

> Since no new, or retransmitted data would be ready to piggy-back the
> changed ACE counters, I do not see how this rapidely dampening
> ACK-on-ACK scenario would have any impact on any of the mechansisms
> (Fast Retransmit doesn't trigger on the multiple idential ACK fields on
> data packets, when the receiver doesn't have data to send).

The dampening ping-pong effect is not a big concern but sending 
unwarranted dupAcks is. Please see Figure 1 of my example scenarios. It's 
a slight variation of the scenario that Bob pointed out on slide 6 here:

  https://datatracker.ietf.org/meeting/111/materials/slides-111-tcpm-accurate-ecn-01

It also corresponds pretty much to the scenario you described in your 
follow-up message that I try to cover here as well (sorry for not copying 
it here). The major difference is in that neither the scenario on the 
slide 6 nor the one in your follow-up description continued far enough to 
fully understand all problems the Acks of Acks create.

Now, let's look at my Fig 1 and assume no SACK nor Timestamps are in use, 
so the TCP senders employ NewReno.

A and B alternate in sending data. A starts with a window size of at 
least 18 MSS that is enough to trigger 9 cumulative Acks from B to A. The 
direction from B to A is (heavily) congested so that at least 9 pure Acks 
get CE marked and trigger at least 3 extra dupAcks from A to B that do not 
correspond to any data packet from B to A that have left the network as 
required by RFC 5681 (that is, this is a violation of the crucial 
requirement in RFC 5681 that is a prerequisite for correct operation 
of several stds track and other CC algos).

Once the first two dupAcks arrive at B they incorrectly fool Limited 
Transmit into sending two extra data packets even though no data packets 
have left the network (the justification for Limited Transmit to send new 
data packet relies on packet conservation principle and that a dupAck 
indicates a data packet has left the network as required in RFC 5681).
When the 3rd dupAck arrives at B, it triggers a false Fast Retransmit and 
fools B to enter Fast Recovery. The major problem of false Fast Retransmit 
is not the potential unnecessary reduction of cwnd that hurts the flow 
from B to A but the subsequent unnecessary retransmissions during Fast 
Recovery that hurt others by injecting unnecessary load into the network;
when the original Acks from A to B start flowing in, the TCP sender at B 
considers them as partial Acks and triggers an unnecessary rexmit for each 
original cumulative Ack, which flow in at the bottleneck line rate. 
Moreover, if there are more than 3 Acks of Acks (=dupAcks) each of them 
fool Fast Recovery into incorrectly increasing cwnd by one MSS and 
send out an extra new data segment, making B more aggresive than 
allowed (also due to violating "MUST NOT" in RFC 5681).

These Acks of Acks are problematic also in a slightly alternate scenario, 
where B first (before A) starts sending data (data pkts 1-100) but maybe 
to some extent simultaneously with A and B encounters a data packet 
loss and correctly enters loss recovery (Fast Recovery). In this case, 
once A starts receiving CE-marked pure Acks (Acks 22, 24,...) after the 
data packets from B, A will continue injecting extra dupAcks to B that 
will make it send more new packets during Fast Recovery than allowed, 
i.e., it causes harm to others by being too aggressive. If the path from 
B to A is highly congested such that B and other flows competing it have a 
relatively small cwnd of a few pkts only, then just a few Acks of Acks 
from A to B may result in B effectively not reacting to congestion at all 
during the fast recovery. Definitely something to avoid.


Timestamps:
===========

Let's next assume timestamps are in use. If I understand it correctly, the 
current proposal to avoid interpreting Acks of Acks as dupAcks is:

  "If timestamps are in use, and the incoming pure ACK
  echoes a timestamp older than the oldest unacknowledged
  data, it is not a duplicate."

If we look at my Fig 1 and assume that timestamps are in use and the 
timestamp value for each data packet is the same as its sequence number, 
that is, the timestamp for data 0 from B to A has TSval=0, etc.

Now, let's first assume pure Acks are not ECT (Acks of Acks denoted as red 
do not occur) and there is a normal case with a packet loss from B to A 
(data pkt 1 is dropped). My apologies for not drawing this separately.
When the data pkts 2, 3, and 4 from B to A arrive at A, they trigger 
dupAcks that carry Ack=1 and TSecr=0 as per RFC 7323. 
The echoed timestamp TSecr=0 is older than the timestamp value of the 
oldest unacknowledged data (data 1 that has TSval=1). These are 
definitely dupAcks but the proposed rule above would declare them 
not being dupAcks and hence prevent the normal dupAck-based loss 
detection from working!?

If we then assume pure Acks are ECT-marked in Fig 1, what would be the 
TSecr in the three first dupAcks? What is the rule to set TSecr in 
Acks that ack pure Acks and where is it specified? And, how would it 
prevent the Acks of Acks from being interpreted as dupAcks? I am 
probably missing something here. Please explain.

I didn't include a scenario of problems with Eifel detection because I 
am still not sure what is the TSecr value you "assume" is delivered with 
Acks of Acks? I also later noticed that the scenario I first had in mind 
was also possible without Acks of Acks if data packets are reordered 
similar to Acks of Acks in my scenario. So, probably it is only that Acks 
of Ack will make the problem to occur more often because small Acks are 
more likely to get reordered than larger data pkts, particularly if they 
are CE marked and operate in an L4S setting.


Spurious RTO detection
======================

If we next look at the Fig 3 where Fig 3a) represents the normal behavior 
of F-RTO in a typical case which may result in spurious timeout that 
F-RTO is designed to detect. A and B alternate in sending data. B first 
sends several data packets (packets 2000 - 2000+n) that get all 
cumalatively acked. Then A continues by sending data (pkts 101 - 200) but 
due to (wireless) network conditions the acks get delayed such that A's 
RTO expires spuriously. A sets cwnd = 1, rexmits data pkt 101 and 
enters slow start. Because the RTO was spurious, the original ack (ack 
103) arrives and increases cwnd by 1. A sends two new data pkts (pkts 200 
and 201) as per F-RTO and waits until an ack arrives. The Ack that 
arrives next is the next original ack (ack 105). Beacuse this Ack also an 
acked new data, F-RTO declares RTO spurious, exits RTO recovery and 
continues by sending new data. Everything worked as designed.

In Fig 3b) we have the same setting but now pure Acks are marked ECT.
There is some congestion from A to B such that at least three of the 
cumulative Acks from A to B get CE-marked and trigger an extra dupAck from 
B to A even though no data pkt has left the network. This dupAck precedes 
the cumulative Acks from B to A and is delayed just like the cumulative 
Acks. A's RTO expires spuriously and it enters RTO recovery like in Fig 
3a) but now the first ack to arrive at A is the extra dupAck. Therefore, 
F-RTO incorrectly declares that the RTO was not spurious and continues 
RTO recovery by retransmitting unacknowledged data in slow start. When 
the original Acks start flowing in at the bottleneck rate, the TCP sender 
at A increases cwnd in slow start on each original Ack that arrives and 
unnecessarily retransmits the next segments at higher speed than before 
the RTO expired. Hence, it causes significant harm to the others by 
bursting out unnecessarily the whole window of data. These unnecessary 
rexmits are the major problem both with false Fast Retransmits as well as 
spurious RTOs, not the potentially unnecessary reduction of cwnd that 
harms the flow itself. That is also why the F-RTO and Eifel algos 
sepateted the spurious rexmit detection from the response to it; the 
detections itself is crucial as it avoids the unnecessary rexmits even if 
the sender decides not to implement the response that may revert the cwnd 
back to its previous value and thereby helps the flow itself.

> I suspect there may be a misunderstanding here, that there is a need to
> instantaneously send out a pure ACK right after receiving a CE-marked
> ACK. Which there is not - normal delayed ACK, and minimum ACE counter
> change heuristics are there to prevent this particular case.

That was not the case as you can now see.

> While we couldn't come up with any example of the ACK-on-CE-marked-ACK
> causing misbehavior (note that these AccECN Acks do carry changed
> information, the new, incremented ACE counter in order to keep both
> sides in sync there), the text suggesting for the sender not also
> implementing either SACK or Timestamps was added as a safety measure.

Because there is significant harm that Acks of Acks will cause to all 
algos that trust on that TCP implementations honor RFC 5681 and send a 
dupAck only when a data packet has left the network, it is crucial that 
Acks of Acks MUST NOT be generated when SACK is not in use.
This can be forced either by prohibiting ECT-marked pure Acks or 
by prohibiting Acking of pure Acks. Currently the draft says "SHOULD NOT 
send ECN-capable pure ACKs". Why "SHOULD NOT", instead of "MUST NOT"? 
What might be the valid reasons when pure Acks would be allowed to be 
ECT-marked, resulting in Acks of Acks and violation of RFC 5681 and all 
problems discussed above and more (which were not discussed, e.g., 
PipeAck calculation in RFC 7661 and calculating DeliveredData in PRR, 
etc.)?

The same holds even if timestamps are in use unless someone specifies and 
shows how timestamps can reliably be used to distinquish "fake" dupAcks 
(Acks of Acks) from real dupAcks without breaking any of the existing 
mechanisms that rely on timestamps.

When SACK is in use and pure Acks are marked ECT, it seems possible to 
distinguish "fake" dupAcks from real dupAcks. However, one must first 
specify how pure Acks are acknowledged. This seems to require 
modification to RFC 2018 (as I already explained in my reply to Bob but 
seemingly need to clarify as Bob didn't get the problem, pls see my new 
reply to Bob).


Are Acks of Acks useful?
========================

Last, let's consider whether acking pure acks is useful, and if so, when. 
As an important principle when deciding whether to inject packets into 
the network one should use the robustness principle: ""be conservative in 
what you send ...". That is, one should carefully consider whether the 
packets are really needed; are they useful, and if so, when, or are 
they possibly unnecessary, and if so, when.

We can start with the example given in the AccECN draft (-24), Sec 
5.2.2.5.1:

  "In a unidirectional data scenario from host A to B where both hosts
  support AccECN, if the Data Receiver (B) has chosen to use ECN-
  capable pure ACKs [I-D.ietf-tcpm-generalized-ecn] and enough of these
  ACKs become CE-marked, then the 'Increment-Triggered ACKs' rule
  ensures that the Data Sender (A) gives B sufficient feedback about
  this congestion. Normally, the Data Sender (A) can piggyback that
  feedback on its data. But if A stops sending data, the second part of
  the 'Increment-Triggered ACKs' rule ensures that A emits a pure ACK
  for at least every third CE-marked incoming ACK over the subsequent
  round trip."

The above describes unidirectional data scenario, which is quite typical 
and claims that this ensures sufficient feedback [on CE-marked ACKs]. 
Sure, it does. But is this necessary?  Obviously, in this case the 
feedback can be used only for Ack CC because B is not sending anything.
However, B cannot apply Ack CC until A sends new data, so it is enough 
that the feedback is delivered with next data segment(s) and sending it 
separately in Acks of Acks earlier is absolutely unnecessary, 
just resulting in additional packet load in the network.

The draft continues:

  "... in this case it is mandatory for A to emit ACKs of ACKs because they
   feed back new congestion state (useful in case B starts sending)."

As explained above, clearly it is not mandatory for A to emit ACKs of 
ACKs. But, as the draft correctly says, it is useful [only] in case B 
starts sending, but not always (e.g., if the TCP conncetion in half-open, 
B never can start sending).

Even if B starts sending, it is not necessarily useful (or practical).
Let's now look at the Fig 2 of my scenarios, where apps on A and B use 
very common request-reply type of communication: in this case A sends 
very short requests (maybe a few bytes only) and B replies with long 
replies. And this is continuous, interactive communication with quite 
strict delay requirements such that it is important that A is able to 
send the next request immediately after the previous reply from B. B has 
increased its cwnd such that it may send all packets of reply in one RTT
(B is application limited, but RFC 7661 or RFC 5681 would allow it to 
continue with the same cwnd from RTT to another as long as there is no 
congestion from B to A).

A sends the request (data 100) and B replies with n data segments, 
resulting in approx. n/2 cumulative Acks. The path from A to B is 
congested (by other traffic) such that many Acks get CE-marked, resulting 
in up to n/6 Acks of Acks that preceed the next round of data from B to A.
This is continuous meaning that up to 16+% of packets from B to A are Acks 
of Acks if the path from A to B remains congested, which is possible if 
there is a large number of competing flows (even if they react to 
congestion). The figure is missing the later rounds of possible ping-pong 
Acks of Acks that may add to the Ack os Ack of the next round(s). Having 
these later, dampening ping-pong Acks requires, of course, that path from 
B to A is also congested. For simplicity, let's also assume that Acks of 
Acks are somehow prevented from being interpreted as dupAcks, that is, 
they do a not trigger false Fast Retransmits (and are not illustriated in 
the Fig even though they would cause additional problems also in this 
scenario if interpreted as dupAcks).

Now, let's consider usefulness of the Acks of Acks carrying congestion 
feedback. When A receives the feedback it may apply either Ack CC to 
reduce cumulative ack rate or decrease cwnd to reduce the data rate from 
A to B. If A uses the feedback for Ack CC purposes only (e.g., it learns 
via AccECN option that ack pkts only are contributing to the congestion), 
sending separate Acks of Acks is quite unnecessary as the feedback can be 
timely delivered with the data packets from B to A. If A decides to react 
by reducing its data rate, the early feedback with Acks of Acks might be 
useful. However, it might also result in undesired effects, maybe because 
A cannot distinguish whether it is its Ack or data that is contributing to 
the congestion when AckECN option is not in use. If A decides to reduce 
its data rate and cwnd = 1 MSS, the only way to do it is to delay the 
next data pkt which would result in undesired delay in delivering the 
next delay-sensitive request even though the data rate from A to B was 
not contributing to the congestion (much) at all. So, if Ack congestion 
is automatically reflected back to A (the data receiver) but data vs. Ack 
congestion is not separated, A as a data sender may have a hard 
dilemma to solve. Furthermore, if A is sending such small reguests (<= 
1 MSS) and is practically application limited, its cwnd is likely to be 
larger than 1 MSS. If it decides to reduce cwnd due to Acks of Acks 
reporting (Ack) congestion, its is likely to have a null effect. That 
is, it seems that Ack congestion is best reacted by Ack CC reducing 
(cummulative) Ack rate only.

One additional example where reflecting Ack congestion blindly in Ack of 
Acks is quite unnecessary is when there is a hole in the sequence space.
Assume A is sending data to B and a pkt gets dropped. This results in B 
doubling its ack rate for one RTT once it starts injecting dupAcks due to 
arriving out-of-order data. Now, if path from B to A is already congested 
or becomes congested due to increased ack rate, some (or many) of the 
dupAcks get CE-marked. That results in congestion feedback in Acks of 
Acks from A to B but B should not react to this added congestion feedback, 
because a pkt was lost and A will react by decreasing its data rate that 
will decrease future ack rate. In addition, the dupAcks were delivered 
only temporarily at the double rate and B will automatically stop 
injecting dupAcks and thereby first halves its Ack rate in one RTT and 
then returns back to sending cumulative acks with a reduced rate from 
what it was sending before the pkt drop was detected. Hence, also in 
this case Acks of Acks reporting congestion feedback are completely 
unnecessary.

Considering what I said above, in case one needs Acks of Acks, wouldn't it 
be much more effective to dampen ping-pongs, if one specifies that Ack of 
an Ack reporting CE on a pure Ack can only be sent if the pure Ack 
advanced SND.UNA, i.e., only count and report marked bytes/pkts in 
cumulative Acks. I don't find any reason to report CE-marked dupAcks (like 
in the previous exampel above) because the pkt load they represent is 
temporary extra load that has dissapeared by the time the feedback 
arrives at the other end. So, they are not subject to be CC reacted as 
the system has already reacted and removed that part of load. Or maybe I 
am missing something?

So, the only case in which I can identify Acks of Acks potentially being 
useful is a slightly modified scenario of my Fig 2 where A sends 
a larger request, i.e., a number of data pkts, instead of just one.
Even in this case the Acks of Acks tend to arrive too late and can 
be used only for controlling data rate in the next round when the 
congestion information might already be stale. Hence, maybe the only 
scenario where Acks of Acks may be useful is when the interaction between 
A and B is not delay sensitive and A waits for a while after the data 
segments of the reply from B have arrived before it starts sending its 
next request? Otherwise, Acks of Acks seem to serve Ack congestion control 
only which is an open issues and definitely not mature for stds track at 
this time.

To summarise:
=============

It seems that Acks of Acks are mostly unnecessary and do not help much in 
terms of providing more timely feedback. Therefore, it would be useful to 
carefully consider whether it is reasonable to nail down in a stds track 
document a behavior (blindly Acking Acks for CE feedback) that in most 
cases seems injecting additional packets to the network unnecessarily.

What specifically strikes me is that currently the draft mandates this 
behavior with a MUST in Sec 3.2.2.5.1, Increment-Triggered ACKs:

  "An AccECN Data Receiver MUST emit an ACK if 'n' CE marks have arrived
  since the previous ACK."

Why cannot this be SHOULD?

This later part of the rule seems to serve ack congestion control only as 
discussed above:

  "If there is no newly delivered data to acknowledge, 'n' SHOULD be 3 and
  MUST be no less than 3. In either case, 'n' MUST be no greater than 7"

If specified like this and one wants to enable ECT-marked pure Acks, it 
mandates always conveying feedback on Ack congestion in Acks of Acks.
Also, when the data sender decides to do Ack CC just by reducing its data 
rate, which requires no feedback to data receiver. Instead, any feedback 
is likely to be mistreated and ack rate gets double controlled.

If the first MUST in Increment-Triggered ACKs rule is made SHOULD, then 
one could omit the later part of the rule. This would require 
reformulating the rule, I believe.

Why? An implementor may want to benefit from ECT-marked Acks but avoid 
sending unnecessary Acks of Acks.
That is, a valid reason for omitting SHOULD would be to separate Ack CC 
from data CC such that CE-marked data pkts would be reported as per this 
draft but the data sender could benefit from CE-marked Ack info and 
decide to apply Ack CC and report it separately or not report it at all 
to the other end. The latter would allow the data sender to control ack 
flow by controlling its data sending rate, reguiring no communication 
with the other end. In the former case, the data sender could use some 
other means to report Ack congestion to or control Ack congestion with 
the data receiver (e.g., Ack Rate option).

I am not claiming that this would be somehow better approach but given 
that Ack CC is still open research or at least experimental, I think we 
should not nail down and restrict how to do it in this stds track 
document to be.

> But if we have not considered a particular corner case, please let us
> discuss that!

AFAIK, none of the cases I described is a corner case but likely to occur 
often in very typical application use cases.

Best regards,

/Markku

> Best regards,
>  Richard
>
>
> Am 26.03.2023 um 16:52 schrieb Markku Kojo:
>> 
>> 3. Acking pure acks. Current text is on the correct track but badly
>> incomplete.
>> 
>> The feature of acking Pure Acks in AccECN is introduced kinda as a
>> sidenote in Sec 3.2.2.5.1 when discussing potential side-effects of
>> ECN-marked pure ACKs that may trigger further ACKs. This is not quite
>> appropriate because this would be a fundamental change to TCP that does
>> not ack pure Acks. And there is no normative spec that says taht Pure
>> Acks (with CE) MAY/SHOULD/MUST be acked. This also involves numerous
>> caveats that has not been fully recognized (see below).
>> 
>> The draft says:
>> 
>> "Therefore, a host in AccECN mode that is sending ECN-capable pure ACKs
>> SHOULD add one of the following additional checks when it tests whether
>> an incoming pure ACK is a duplicate:
>> 
>> -If SACK has been negotatiated for the connection, but there is no
>>   SACK option on the incoming pure ACK, it is not a duplicate;"
>> 
>> [MK]: Cite RFC 6675 which already states this. But the actual problem of
>> using this rule is that there is no normative spec available how a
>> SACK-enabled receiver is supposed to ack a Pure Ack. The draft makes an
>> well-educated assumption but in fact an implementator cannot implement
>> this without a normative specthat is cited here to tell how to ack.
>> 
>> "-If timestamps are in use, and the incoming pure ACK echoes a
>>    timestamp older than the oldest unacknowledged data, it is not a
>>    duplicate.
>> 
>> In the unlikely event that neither SACK nor timestamps are in use, or if
>> the implementation has opted not to include either of the above two
>> checks, it SHOULD NOT send ECN-capable pure ACKs. If it does, it could
>> lead to false detection of duplicate ACKs, causing spurious
>> retransmission(s) with a resulting unnecessary reduction in congestion
>> window; but only in certain circumstances."
>> 
>> [MK]: False Fast Retransmits are not the only problem although it alone
>> necessitates MUST NOT, not just SHOULD NOT. Each extra dupack is subject
>> to trigger an extra data segment in a numerous heuristics that are based
>> on the packet conservation principle and will confuse these algorithms,
>> including Limited Transmit, Fast Recovery, PRR, etc.
>> For this very reason RFC 5681 prevents (MUST NOT) a data receiver from
>> acking more than once per incoming data packet. Ackinf Pure ACKs was not
>> known by that time but this rule extends to cover acking of Pure AKCs
>> because the consequence is the same.
>> 
>> In addition, acking Pure Acks will break F-RTO and potentially also
>> other algos. Even with Timestamps we are not on the safe side as this
>> would also break Eifel detection.
>> 
>> So, I hesitate a lot to introduce any algo for acking Pure acks in a
>> standards track spec as unmature.
>> 
>> In general, I don't see any benefit for Acking Pure acks for ack
>> congestion control purposes because such feedback has no effect until
>> the sender send data again. That is, postponing the feedback until there
>> is data again has the same effect when used for controlling ack rate.
>> Moreover, I find draft-ietf-tcpm-ack-rate-request much beter suited for
>> this purpose.
>> 
>> For the case where CE on Pure ACKs are mixed with data from the same
>> sender, it is not at all clear how the sender should respond, or whether
>> the ack CC should be handled separate from data CC. IMO, these are
>> clearly research questions, definitely not ready for standards track.
>> 
>