Subject: [tcpm] Comments on draft-ietf-tcpm-accurate-ecn-14

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 12 Mar 2021 11:50:42 +0000

Abstract:
/Given TCP header
    space is scarce, this allocates a reserved header bit, that was
    previously used for the ECN-Nonce which has now been declared
    historic. /
- English: /which/that/ /that/which/ perhaps??
- However, I wonder if this is necessary in the abstract, surely a 
reader of the abstract in future would only need to know:
/This allocates a reserved header bit, previously used for the ECN-Nonce./

I also do wonder if the abstract still rather complicated (aka long)?
——
Section 2.5:
/According to [RFC3168] the Data Sender is meant to
    set control packets to Not-ECT.  However, mechanisms in certain
    private networks (e.g. data centres) set control packets to be ECN
    capable because they are precisely the packets that performance
    depends on most./
- I think /set/ is rather odd.
- Can we talk about the /ECN IP field/ being set (as used later) ?
——
Two questions in the same sentence on p16, starting /So, without these 
rules/:
/could end up/
- this seems possibly one of those phrases that confuses non-native 
speakers?

/using difference feedback modes/
- is that word really difference not different?

——

Section 3.2
/3.3.2.  Requirements for TCP Normalizers/

I like the introduction of subheadings within 3.2, because it helps 
people find the part of the spec they need to see - especially important 
when the implementer only needs to understand one aspect in detail, 
however, I wonder if this second part needs a separate heading:
/A middlebox claiming to be transparent/
… really only for normalisers? - I expected this to be relevant to any 
“transparent” middlebox”
- would it be better with a separate subsection for this important point?
—
I have re-read /3.3.3. Requirements for TCP ACK Filtering/ in -14, and 
although I am not yet sure of the speculation that using ECN in future 
is sufficient to regulate the ratio of ACKs to Data, I believe the text 
is correct in its interpretation of RFC3449, and that the present design 
is anyway robust to ACK mitigation methods.
——
/Once DCTCP offload hardware supports AccECN/
… I’m not sure this para is perfected yet, because it is directed at 
DCTCP. I’d like to consider a reordering that is more like:

/The above process has been designed to enable a continuing
  incremental deployment path - to more highly dynamic congestion
  control.  Once offload hardware supports AccECN, it will be
able to coalesce efficiently for any sequence of marks, instead of
  relying for efficiency on the long marking sequences from step
  marking.  In the next stage, marking can evolve from a step to
a ramp function.  That in turn will allow host congestion control
algorithms to respond faster to dynamics, while being backwards
compatible with existing host algorithms./
… i.e., do we really have to directly discuss DCTCP here, doesn’t it in 
general refer to AccECN rather?
——

Security Considerations:

The “downgrade attack” regarding a receiver deciding/accidentally 
omitting an option in the Security Considerations seems incorrect to me.
To me, the text is written in a way that sounds like it impacts the 
“security” of the connection. I do not agree with that interpretation. 
To me, this is a performance reduction, and the degrade does not impact 
the ability to communicate or security properties. I suggest some 
rewording here.
——
Security Considerations:

There’s now also a Security Considerations include a ToDo, that I do not 
yet understand, look forward to this!
——

Best wishes,

Gorry

(P.S. I will send one more specific question in a separate email).

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 12 Mar 2021 11:58:37 +0000

I have questions on the sender fallback in use of ECT(?) - not because I 
do not agree with the method, I think the approach is good. However, the 
method here is something that impacts the sender CC method, not the 
feedback method. Maybe this was discussed before - if so remind me - my 
questions relate to this:

/Once a Data Sender has entered AccECN mode it SHOULD check whether
    all feedback received for the first three or four rounds indicated
    that every packet it sent was CE-marked.  If so, for the remainder of
    the connection, the Data Sender SHOULD NOT send ECN-capable packets,
    but it MUST continue to feed back any ECN markings on arriving 
packets./

(i) I’m pretty sure this is safe to wait for /the remainder of the 
connection/. Is this possibly unnecessarily restrictive - without 
explaining why, in that some connections are long-lived and do 
experience path changes?

- At least I would like some text about path changes to path that would 
support AccECN, and what happens.

(ii) This isn’t really about AccECN at all, it’s about guidance on the 
use of ECT(?) by a TCP sender's CC .

I think this is intended here *only* is to apply to TCP senders, and I 
think that needs to be made clear? - Although it might also be valuable 
(non-normative?) advice for other transports that also have a similar 
way of reporting CE?

- To me is something that needs to be more explicit, and probably in a 
separate sub-section or something?

Gorry

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 12 Mar 2021 12:14:23 +0000

Gorry,

We added this 'cos we were told it is common practice in production 
ECN-capable stacks.

I think it would be hard (and inefficient) to check continuously, 
because changing to or from a long run of CE marks once in progress is 
perfectly valid behaviour for a good path.

Perhaps those who have implemented this could comment?

Bob

On 12/03/2021 11:58, Gorry Fairhurst wrote:
> I have questions on the sender fallback in use of ECT(?) - not because 
> I do not agree with the method, I think the approach is good. However, 
> the method here is something that impacts the sender CC method, not 
> the feedback method. Maybe this was discussed before - if so remind me 
> - my questions relate to this:
>
> - At least I would like some text about path changes to path that 
> would support AccECN, and what happens.
>
> think that needs to be made clear? - Although it might also be 
> valuable (non-normative?) advice for other transports that also have a 
> similar way of reporting CE?
>
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 12 Mar 2021 12:23:53 +0000

Thanks, see below:

> We added this 'cos we were told it is common practice in production 
That's fine, and can be usefully noted - but then I'll say again - this 
is about how *ECN* is used, not specifically an accurate ECN issue!
> perfectly valid behaviour for a good path.
I agree that it would seem bad to check continuously, but maybe on a 
path change detected (however that might be determined)?
> Perhaps those who have implemented this could comment?
That would be great,....
Gorry

>> I have questions on the sender fallback in use of ECT(?) - not 
>> because I do not agree with the method, I think the approach is good. 
>> However, the method here is something that impacts the sender CC 
>> method, not the feedback method. Maybe this was discussed before - if 
>> so remind me - my questions relate to this:
>>
>> (ii) This isn’t really about AccECN at all, it’s about guidance on 
>> the use of ECT(?) by a TCP sender's CC .
>>
>> I think this is intended here *only* is to apply to TCP senders, and 
>> I think that needs to be made clear? - Although it might also be 
>> valuable (non-normative?) advice for other transports that also have 
>> a similar way of reporting CE?
>>
>> - To me is something that needs to be more explicit, and probably in 
>> a separate sub-section or something?
>>
>> Gorry
>>
>>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 16 Mar 2021 17:25:48 +0100

Hi Bob,

I do agree with Gorry that this is actually not about how to provide feedback but about how to use ECN and I think we were always aiming to separate the two. 

Maybe we can change to not normative and say something like disabling after a small fixed number fo CE marked packets is the easiest way to address this problem but there might be other, smarter, more flexible approaches…?

Mirja

> On 12. Mar 2021, at 13:23, Gorry Fairhurst <[email-masked]> wrote:
> 
> Thanks, see below:
> 
>> We added this 'cos we were told it is common practice in production ECN-capable stacks.
> That's fine, and can be usefully noted - but then I'll say again - this is about how *ECN* is used, not specifically an accurate ECN issue!
>> 
>> I think it would be hard (and inefficient) to check continuously, because changing to or from a long run of CE marks once in progress is perfectly valid behaviour for a good path.
>> 
> I agree that it would seem bad to check continuously, but maybe on a path change detected (however that might be determined)?
>>> I have questions on the sender fallback in use of ECT(?) - not because I do not agree with the method, I think the approach is good. However, the method here is something that impacts the sender CC method, not the feedback method. Maybe this was discussed before - if so remind me - my questions relate to this:
>>> 
>>>    but it MUST continue to feed back any ECN markings on arriving packets./
>>> 
>>> (i) I’m pretty sure this is safe to wait for /the remainder of the connection/. Is this possibly unnecessarily restrictive - without explaining why, in that some connections are long-lived and do experience path changes?
>>> 
>>> - At least I would like some text about path changes to path that would support AccECN, and what happens.
>>> 
>>> (ii) This isn’t really about AccECN at all, it’s about guidance on the use of ECT(?) by a TCP sender's CC .
>>> 
>>> I think this is intended here *only* is to apply to TCP senders, and I think that needs to be made clear? - Although it might also be valuable (non-normative?) advice for other transports that also have a similar way of reporting CE?
>>> 
>>> - To me is something that needs to be more explicit, and probably in a separate sub-section or something?
>>> 
>>> Gorry
>>> 
>>>

---

From: Gorry Fairhurst <[email-masked]>
Date: Sun, 21 Mar 2021 02:41:40 +0000

> Maybe we can change to not normative and say something like disabling after a small fixed number fo CE marked packets is the easiest way to address this problem but there might be other, smarter, m…

Yes - that was what I noted.

It would be possible to conjecture other ways to do this, although I am 
not sure this is helpful. Perhaps the draft could instead say this "this 
can be done by ..." and explain the method that is being used. That 
leaves the possibility for a later spec to define a standard sender 
method, or an alternative, but in the meantime it provides guidance on 
what might be a useful practical approach.

Gorry

---

From: Bob Briscoe <[email-masked]>
Date: Sun, 21 Mar 2021 18:32:44 +0000

Mirja, Gorry,

Point taken about mission creep from ECN feedback to setting the IP-ECN 
field in packets as a data sender.

The question is, where would fall-back behaviour like this be defined?
It's not congestion response, so it would not be relevant in each CC 
definition.
It's about mangling detection and fall-back. So it really belongs in 
RFC3168, or an update to RFC3168.
AccECN is now intended to update RFC3168, but its scope is not meant to 
cover fall-back.

I guess this ought to be recorded somewhere as a necessary item for an 
RFC3168bis. I don't think the IETF has a process for such a ToDo list, 
or does it?

As far as the AccECN draft is concerned, shouldn't I just delete this 
para? Rather than include something in AccECN that is out of scope, and 
then weaken it to non-normative, which could be misinterpreted as being 
unimportant, rather than out of scope.

Bob

On 21/03/2021 02:41, Gorry Fairhurst wrote:
>> I do agree with Gorry that this is actually not about how to provide 
>> feedback but about how to use ECN and I think we were always aiming 
>> to separate the two.
>>
>> Maybe we can change to not normative and say something like disabling 
>> after a small fixed number fo CE marked packets is the easiest way to 
>> address this problem but there might be other, smarter, more flexible 
>> approaches…?
>>
>> Mirja
>
> It would be possible to conjecture other ways to do this, although I 
> am not sure this is helpful. Perhaps the draft could instead say this 
> "this can be done by ..." and explain the method that is being used. 
> That leaves the possibility for a later spec to define a standard 
> sender method, or an alternative, but in the meantime it provides 
> guidance on what might be a useful practical approach.
>
> Gorry
>
>>
>>
>>> That's fine, and can be usefully noted - but then I'll say again - 
>>> this is about how *ECN* is used, not specifically an accurate ECN 
>>> issue!
>>>> because changing to or from a long run of CE marks once in progress 
>>>> is perfectly valid behaviour for a good path.
>>>>
>>>>> because I do not agree with the method, I think the approach is 
>>>>> good. However, the method here is something that impacts the 
>>>>> sender CC method, not the feedback method. Maybe this was 
>>>>> discussed before - if so remind me - my questions relate to this:
>>>>>
>>>>> I think this is intended here *only* is to apply to TCP senders, 
>>>>> and I think that needs to be made clear? - Although it might also 
>>>>> be valuable (non-normative?) advice for other transports that also 
>>>>> have a similar way of reporting CE?
>>>>>

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 22 Mar 2021 12:00:23 +0100

We could start a 3168bis doc ;-)

Or start a separate draft for validation. QUIC has already some text on this:

https://www.ietf.org/archive/id/draft-ietf-quic-transport-34.html#name-ecn-validation

See also 

https://www.ietf.org/archive/id/draft-ietf-quic-transport-34.html#ecn-alg

However, this is actually not really QUIC or TCP specific and could go into tsvwg.

For the AccECN, I think it would still be good to at least mention that validation is needed. I would even say that it recommended to be implemented some smarter together with AccECN, given the simple if-SYN-is-CE-marked test doesn’t work anymore if SYN can be ECT marked. Or maybe this is something to say in the ECN++ draft...?

Mirja

> On 21. Mar 2021, at 19:32, Bob Briscoe <[email-masked]> wrote:
> 
> Mirja, Gorry,
> 
> Point taken about mission creep from ECN feedback to setting the IP-ECN field in packets as a data sender.
> 
> It's not congestion response, so it would not be relevant in each CC definition.
> It's about mangling detection and fall-back. So it really belongs in RFC3168, or an update to RFC3168.
> AccECN is now intended to update RFC3168, but its scope is not meant to cover fall-back.
> 
> I guess this ought to be recorded somewhere as a necessary item for an RFC3168bis. I don't think the IETF has a process for such a ToDo list, or does it?
> 
> As far as the AccECN draft is concerned, shouldn't I just delete this para? Rather than include something in AccECN that is out of scope, and then weaken it to non-normative, which could be misinterpreted as being unimportant, rather than out of scope.
> 
> 
> Bob
> 
>> It would be possible to conjecture other ways to do this, although I am not sure this is helpful. Perhaps the draft could instead say this "this can be done by ..." and explain the method that is being used. That leaves the possibility for a later spec to define a standard sender method, or an alternative, but in the meantime it provides guidance on what might be a useful practical approach.
>> 
>> Gorry
>> 
>>> 
>>>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 22 Mar 2021 12:04:38 +0000

Gorry,

Thank you for this additional review.

> /This allocates a reserved header bit, previously used for the 

[BB] Done, except I've said:
"previously assigned to the ECN-Nonce" rather than "used by", since it's 
unclear how much actual use it got.

I also thought the following would be better, now that this updates 
RFC3168:
s/ECN is specified for TCP in such a way that only one feedback signal 
can be transmitted per Round-Trip Time (RTT)./
  /ECN was originally specified for TCP in such a way that only one 
feedback signal can be transmitted per Round-Trip Time (RTT)./

> I also do wonder if the abstract still rather complicated (aka long)?

[BB] It's 202 words. I'd rather leave it as it is if your objection 
isn't particularly strong.

> - Can we talk about the /ECN IP field/ being set (as used later) ?

[BB] I don't think 'set' is odd. IMO, it seems like the most natural 
word to use. Do you have a preferred alternative?

But I agree it's useful to distinguish the IP-ECN field from TCP ECN 
flags. Indeed, I've run through the whole of section 2, and clarified 
where it is talking about the IP-ECN field.

> - this seems possibly one of those phrases that confuses non-native 

[BB] I'm not sure what you think the problem is.
Possibly the two 'withouts'?
I tried this:

Original:
/So, without these rules, the two peers could end up using different 
feedback modes without knowing it./
Option 1:
/So, without these rules, the two peers could end up using different 
feedback modes unknowingly./
Option 2:
/So, in the absence of these rules, the two peers could end up using 
different feedback modes without knowing it./

A US-English speaker might use 'absent these rules', but I think the 
longer British English above is equally understood in the US. Can 
someone confirm that?

I tried unwittingly instead of unknowingly, but I think that is a bit 
obscure for non-native English speakers.

I've gone for Option 2, but pls suggest something else, if you'd prefer it.

> - is that word really difference not different?

[BB] Thx - different was meant.

> people find the part of the spec they need to see - especially 
> important when the implementer only needs to understand one aspect in 
> detail, however, I wonder if this second part needs a separate heading:

[BB] Just before your review, I had proposed to my co-authors that we 
should change this para. Now, from your comments, I see that the scope 
of the whole section needs clarifying. The idea was that a set of TCP 
headers that complies with the RFCs can either
a) remain completely unchanged (e.g. transparent performance enhancement)
b) be 'normalized' to a narrower interpretation of the RFCs, which might 
not always be up to date (e.g. an intrusion detection system).

I'd rather draw this fine line within a single section, because it's too 
difficult for two section headings to describe the difference well 
enough. I've also removed some gratuitous criticism of middleboxes, 
which won't encourage middlebox vendors to comply. Here's the whole 
rewritten subsection (I avoided a full diff which was too hard to follow):

+3.3.2.  Requirements for Transparent Middleboxes and TCP Normalizers

     Another large class of middleboxes intervenes to some degree at the
     transport layer, but attempts to be transparent (invisible) to the
     end-to-end connection.  A subset of this class of middleboxes
     attempts to `normalize' the TCP wire protocol by checking that all
+   values in header fields comply with a rather narrow interpretation
+   of the TCP specifications that is also not always up to date.

+   A middlebox that is not normalizing the TCP protocol and does not
+   itself act as a back-to-back pair of TCP endpoints (i.e. a middlebox
+   that intends to be transparent or invisible at the transport layer) ought to
     forward the AccECN TCP Option unaltered, whether or not the length
     value matches one of those specified inSection 3.2.3  <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.3>, and whether or
     not the initial values of the byte-counter fields
+   match those inSection 3.2.1  <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.1>.  This is because blocking apparently
+   invalid values prevents the standardized set of values being
     extended in future (given outdated normalizers would block updated
     hosts from using the extended AccECN standard).

+   A TCP normalizer is likely to block or alter an AccECN TCP Option
+   if the length value or the initial values of its byte-counter fields
+   do not match one of those specified inSection 3.2.3  <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.3>  orSection 3.2.1  <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.1>.
+                                                  However, to comply with
+   the present AccECN specification, a middlebox MUST NOT change
+   the ACE field; or those fields of the AccECN Option that are currently
+   specified inSection 3.2.3  <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.3>; or any AccECN field covered by integrity
+   protection (e.g. [RFC5925  <https://datatracker.ietf.org/doc/html/rfc5925>]).

Note that I've changed the 'MUST' to 'ought to', because this is really 
clarification advice (although the line between advice and protocol 
interop is blurred with middleboxes). I can revert to MUST if the WG 
would prefer.

> is sufficient to regulate the ratio of ACKs to Data, I believe the 
> text is correct in its interpretation of RFC3449, and that the present 
> design is anyway robust to ACK mitigation methods.
> ——
> … i.e., do we really have to directly discuss DCTCP here, doesn’t it 
> in general refer to AccECN rather?

[BB] You're right, thank you. Done.

> To me, this is a performance reduction, and the degrade does not 
> impact the ability to communicate or security properties. I suggest 
> some rewording here.

Current:

    No known way can yet be contrived to take advantage of
    this downgrade attack, but it is mentioned here in case someone else
    can contrive one.

Proposed:

    No known way can yet be contrived for a receiver to take advantage of
    this behaviour, which seems to always degrade its own performance.
    However, the concern is mentioned here for completeness.

> ——
> Security Considerations:
>
> There’s now also a Security Considerations include a ToDo, that I do 
> not yet understand, look forward to this!

I propose to clarify and cut down the existing text, and to replace the 
"{ToDo}" with the two new sentences below:

Current:

    InSection 3.2.3  <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.3>  a Data Sender is allowed to ignore an unrecognized
    TCP AccECN Option length and read as many whole 3-octet fields from
    it as possible up to a maximum of 3, treating the remainder as
    padding.  This opens up a potential covert channel of up to 29B (40 -
    (2+3*3))B. {ToDo...}

Proposed:

    InSection 3.2.3  <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn-14#section-3.2.3>  a Data Sender is allowed to ignore an unrecognized
    TCP AccECN Option length and treat extra octets as padding.  This is
    noted here in case it could be used as a covert channel. The size is
    up to 29 B (40 - (2+3*3)) per packet. However, it is really an overt
    channel (not hidden) and it is no different to the use of unknown
    TCP options with unknown option lengths in general. Therefore, where
    such a channel is of concern, it can already be adequately mitigated
    by regular TCP normalizer technology (see Section 3.3.2).

This also requires the final para to be updated

Current:

    The AccECN protocol is not believed to introduce any new privacy
    concerns, because it merely counts and feeds back signals at the
    transport layer that had already been visible at the IP layer.

Proposed:

    The AccECN protocol is not believed to introduce any new privacy
    concerns, because it merely counts and feeds back signals at the
    transport layer that had already been visible at the IP layer. A
    covert channel can be used to compromise privacy. However, as
    explained above, undefined TCP options generally open up such
    channels and common techniques are available to close them off.

I shall also shift this para up one, so that is comes straight after the 
previous discussion of covert channels.

> Gorry

[BB] As always, thank you very much for your continued diligence.

Bob

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 22 Mar 2021 12:23:04 +0000

Thanks,

These confirmed my understanding, and you appear to have resolutions to 
the issues, a few comments in-line:

On 22/03/2021 12:04, Bob Briscoe wrote:
> "previously assigned to the ECN-Nonce" rather than "used by", since 
> it's unclear how much actual use it got.
>
GF: Looks good to me.
> isn't particularly strong.
GF: RFC-Ed or AD can decide, not me.
> word to use. Do you have a preferred alternative?
GF: I was thinking more:
/set the ECN field of control packets to Not-ECT/
> where it is talking about the IP-ECN field.
GF: Sounds good.
>> ——
>> Two questions in the same sentence on p16, starting /So, without 
>> these rules/:
>> /could end up/
GF: I was thinking 2, but perhaps:
/could end up/could choose to use/
>> … really only for normalisers? - I expected this to be relevant to 
>> any “transparent” middlebox”
> b) be 'normalized' to a narrower interpretation of the RFCs, which 
> might not always be up to date (e.g. an intrusion detection system).
>
> I'd rather draw this fine line within a single section, because it's 
> too difficult for two section headings to describe the difference well 
> Note that I've changed the 'MUST' to 'ought to', because this is 
> really clarification advice (although the line between advice and 
> protocol interop is blurred with middleboxes). I can revert to MUST if 
> the WG would prefer.
>
GF: I like the new text.
>> —
>> I have re-read /3.3.3. Requirements for TCP ACK Filtering/ in -14, 
>> and although I am not yet sure of the speculation that using ECN in 
>> future is sufficient to regulate the ratio of ACKs to Data, I believe 
>> the text is correct in its interpretation of RFC3449, and that the 
>> present design is anyway robust to ACK mitigation methods.
>> ——
>> “security” of the connection. I do not agree with that 
>> interpretation. To me, this is a performance reduction, and the 
>> degrade does not impact the ability to communicate or security 
>> properties. I suggest some rewording here.
>
> Current:
GF: I don't see issues with that, thanks.
> I propose to clarify and cut down the existing text, and to replace 
> the "{ToDo}" with the two new sentences below:
>
> Current:
> I shall also shift this para up one, so that is comes straight after 
> the previous discussion of covert channels.
>
>
GF: This addresses this point.
> Bob Briscoehttp://bobbriscoe.net/

Gorry