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

[Markku Kojo <[e-mail]>]

Dear all,

I have reviewed the doc. I didn't pass through all the details 
that I believe are in good shape. The doc reads well and is very thorough 
in most part. It is useful and good to have it published.

However, there are a few of issues I am concerned about:

1. IANA considerations on allocating/using ECN flags.

The design of the ECN negotiation and particularly how it takes into 
account potential any future ECN alternatives is the correct approach 
and very much appreciated.

However, it is not made explicit in the draft. Instead, the draft hides 
this important information in the appendix B and discusses elsewhere in 
the draft, including the Sec 6 on IANA consideration, on the allocation 
of the AE flag in such a way that it is easily intrepeted as if the AC 
flag is solely for AccECN use (now and in the future).

I'd suggest that the draft and the IANA assignment makes it explicit 
what the design actually does: it allocates (reassigns) the bit 7 of the 
TCP header flags to extend the use of the existing ECE and CWR flags in a 
backwards compatible way. That is, it specifies a three-bit TCP ECN Field 
out of the AE, ECE, and CWR flags and assigns the codepoint 111 to 
AccECN for negotiating ECN Capability in its initial SYN of 3whs. For 
backwards compability codepoint 011 is kept for negotiating Classic ECN 
in the initial SYN (and 000 for Not-ECN Capability) . After the initial 
SYN, the use of the TCP ECN Field depends solely on the variant of ECN 
Capability negotiated, i.e., the TCP ECN Field is overloaded to complete 
the 3whs as well as to provide ECN feedback during the TCP connection.

Consequently, the IANA assignment is best modified to reflect this by 
introducing a three-bit TCP ECN Field and allocating codepoints 000 
(non-ECN-setup SYN), 011 (RFC 3168 ECN-setup SYN), 111 (AccECN ECN-setup 
SYN) for the ECN-Capability negotiation in the initial SYN segment.

I'd also suggest renaming the AE flag to EE (Extended ECN) to better 
cover also any ECN alternative beyond Classic ECN and not to be tied by 
name to AccECN only.

IMHO, this would make it all much clearer for everyone as well as easier 
to allocate new codepoints (by IANA) to any future ECN variant 
negotiation.

====

2. The requirement for AccECN servers to interpret all ECN codepoints 
other than 000, 011, and 111 in the initial SYN same as 111, i.e., 
requesting AccECN.

The draft reads in Sec. 3.1.3:

  If a TCP server that implements AccECN receives a SYN with the three
  TCP header flags (AE, CWR and ECE) set to any combination other than
  000, 011 or 111, it MUST negotiate the use of AccECN as if they had
  been set to 111.

Is this really what it meant to say, or was the intention to say:

  If a TCP server that implements AccECN receives a SYN with the three
  TCP header flags (AE, CWR and ECE) set to any combination other than
  000, 011 or 111 *and does not understand such a combination*, it MUST
  negotiate the use of AccECN as if they had been set to 111.

If not, then this sounds like too restrictive as in this case any future 
alternative spec that uses any of the other flag combinations and also 
supports AccECN would unnecessarily need to update this spec to allow 
negotiating other than AccECN behaviour.

In addition, the crucial pieces from Appendix B explaining the 
availability of the unused five codepoints for (any) future use is useful 
to include in the Sec 3.1.3.

====

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.

====

4. Updates 3168:

Make it clear that this does not obsolete/replace nor does require anyone 
who may want to implement Classic ECN to implement the updates in this 
doc. That is, this draft updates RFC 3168 solely to allow implementing 
AccECN specified in this doc.


Nits:

"flag available for use by the AccECN experiment instead."

- Experiment is leftover from the time when targetting Experimental?
   There are a few other such occurances. Might want to
   consider deleting.

"RST packet"  -> "RST segment"
"SYN packett" -> "SYN segment"

- there are a number of such intanses. If you want to use packet instead 
of segment, then it might be better to make this explicit early in the 
draft similar to RFC 3168 does:

  "In a mild abuse of terminology, in this document we refer to `TCP
  packets' instead of `TCP segments'.


Hope this is helpful.

Best regards,

/Markku