[tcpm] ECN++: Whether to allow ECT/CE marking of pure ACKs and what response to recommend to feedback reporting that a pure ACK was CE marked.

[marcelo bagnulo braun <[e-mail]>]

Hi,

Regarding, draft-ietf-tcpm-generalized-ecn, we still have the open issue 
regarding whether to allow ECT/CE marking in pure acks and what response 
to reccomend if a pure ack encountered congestion.

After considering the discussion in the last meeting and in the ml, we 
propose the following text in the draft:

---------------------

For the experiments proposed here, the TCP implementation will set
ECT on pure ACKs.  It can ignore the requirement in section 6.1.4 of
RFC 3168 to set not-ECT on a pure ACK.

A host that sets ECT on pure ACKs SHOULD respond to the congestion 
signal resulting from pure ACKs being marked with the CE codepoint. The 
specific response will need to be defined as an update to each 
congestion control specification. Possible responses to congestion 
feedback include regulating the pure ACK rate (see AckCC [RFC5690])  or 
reducing the congestion window (CWND).

However, if the congestion response implemented reduces the CWND upon 
the report of CE marking of Pure ACKs, then the congestion control 
algorithm must also increase the CWND upon delivery of pure ACKs without 
a CE mark, to avoid a bias in the congestion control algorithm.

(We can also include some of the description of how to do this based on 
the text below for RFC3168 and AccECN in an appendix.)

---------------------

Some background about this proposal:

First of all, it's worth reminding that without ECN++, TCP currently is 
not required to detect loss of pure ACKs and is not required to react to 
them.
The current draft states that it is allowed to ECT/CE mark the pure ACKs 
and that:
"   A host that sets ECT on pure ACKs MUST reduce its congestion window
    in response to any congestion feedback, in order to regulate any data
    segments it might be sending amongst the pure ACKs.  It MAY also
    implement AckCC [RFC5690] to regulate the pure ACK rate, but this is
    not required. "

The feedback we received in the Prague meeting was:

- It is valuable to allow ECT/CE marking of pure ACK to avoid high drop 
rate when there is congestion. There is a strong case for ECN-capable 
pure ACKs as they are critical for connection performance.

- The sender of the pure acks must respond (somehow) to the congestion 
signal resulting from getting CE marks in pure ACKs. Recommending not to 
respond to a received congestion signal seem like a bad recommendation 
to make in general and setting a bad precedent.

There are two possible responses: reduce CWND (somehow) and/or ACK 
congestion control (ACK CC) (as defined in RFC5690).

- The feedback regarding ACK CC is that it is too complex and with too 
many corner cases to mandate its implementation, so we should not 
mandate it.

- Regarding reducing the CWND, there were several arguments against 
doing this. A very compelling argument is that since we do not increase 
the CWND when pure ACKs are successfully delivered, if we reduce the 
CWND when they are CE marked, then we have a strong bias towards 
reducing the CWND. In particular, in the case the one endpoint is only 
sending pure ACKs, the likely result is that the CWND will be 1 after a 
while.

It is possible to address this issue by allowing the increase of CWND in 
case there are no CE marks in the pure ACKs.

A possible approach for this would be the following:

- if ECN++ is being used with RFC3168 ECN, then we simply do what is 
done with data packets, i.e. if during a RTT no ECE is received, the 
sender increases its CWND and if the sender receives one or more ECE 
marks, then it reduces its CWND. The only difference is that we include 
pure ACKs as well.

- if ECN++ is used with AccECN, the situation is slightly more complex 
because the sender of the pure ACKs needs to keep track of the pure ACKs 
that got CE marked and those that didnt. But the sender of the pure ACKs 
knows how many pure ACKs it has sent. The other endpoint includes pure 
ACKs in the packet count of CE marked packets that is reported using 
AccECN, then the sender of the pure ACKs can figure out how many pure 
ACKs have been CE marked and how many were not. It then can feed this 
information to the congestion control algorithm.

(The limitation of this approach is that lost pure ACKs are accounted as 
delivered pure ACKs without any CE marks, meaning that in the case of 
severe congestion, when pure ACKs are being dropped, the congestion 
control algorithm will include those lost pure ACK packets as delivered 
and increase the CWND the corresponding share. Since pure ACKs are small 
packets, it is not clear how much of a problem is this. Similarly (but 
worse), with 3168 feedback, even if detecting CE on pure ACKs, if pure 
ACKs are lost and there's no CE on a pure ACK within an RTT, cwnd will 
continue to increase. However, in both cases, it is still better with 
ECN++, because without ECN++ there was no response to either dropped or 
CE-marked pure ACKs.)

It might be useful for the congestion response to be proportionate to an 
estimate of the bytes marked rather than packets marked, by adding an 
assumed header size on the wire to the size of every segment (otherwise 
pure ACKs would have zero size and not require any response). This would 
be up to the implementation.


Note that the response to the congestion signal is outside the scope of 
draft-ietf-generalized-ecn, because it depends on the specific CC, e.g. 
Reno, Cubic, Compound, etc)

That being said, we should include some guidance of what type of 
response is sensible, particularly for the standards track CC [RFC5681].

thoughts?

Bob & Marcelo