Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt

[Jonathan Morton <[e-mail]>]

> On 12 Jul, 2019, at 8:18 pm, Black, David <[e-mail]> wrote:
> 
> As an alternative to this single-bit proposal, please take a look at draft-ietf-tcpm-accurate-ecn (https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/) and consider how that functionality might (or might not) be usable with SCE. 

We did look into this, but found some shortcomings that simple reuse of the NS bit (or assigning one of the other spare TCP header bits adjacent to NS) neatly overcomes.

First is that much of AccECN is focused on providing accurate feedback of CE marks, which is not very relevant to SCE since the existing ECE/CWR mechanism from RFC-3168 works well.  For this purpose the NS bit is also consumed, forming a 3-bit field that straddles a byte boundary and is thus awkward to parse.

A simple transformation of this field into one that counts SCE marks doesn't work, because feedback of CE marks is then lost.  Retaining the original response to purely CE-based congestion feedback is a crucial part of SCE's design for incremental deployment.

To get feedback of ECT(1) which carries the SCE information, the full length of the AccECN TCP Option must be used, inflating the volume of the ack stream - and concerns have been raised about TCP Options in discussions here.  A similar concern made one of our other ideas (replacing TCP Timestamps with a slight larger option that would absorb the NOP padding currently used) less desirable, though that also avoided the ack-inflation problem.

We therefore tried to explore ideas that posed minimum risk of confusing firewalls or increasing software complexity.  We considered that reusing a bit that had previously been assigned to an ECT(1) related mechanism would be safest, and subsequently found that it could convey all the information needed with sufficient reliability.

I agree that this draft could be improved to explain the above choice and give more detail on the expected semantics.  I'll work with Rod to sort that out.

 - Jonathan Morton