Subject: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Sun, 15 Jul 2018 20:54:31 +0000

Hi all,

While reading draft-ietf-tcpm-accurate-ecn-07, I noticed the following:

Section 1. Introduction

   It is likely (but not required) that the AccECN protocol will be
   implemented along with the following experimental additions to the
   TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
   [I-D.ietf-tcpm-generalized-ecn], which includes the ECN-capable SYN/
   ACK experiment [RFC5562]; and testing receiver non-compliance
   [I-D.moncaster-tcpm-rcv-cheat].

[ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Having said this, I observe that draft-moncaster-tcpm-rcv-cheat-03 was last updated in 2014. How "likely" is it that the AccECN protocol will be implemented along with a mechanism documented in an ID that has been written more than 10 years ago and not been updated for about 4 years? Are implementers indeed so interested in draft-moncaster-tcpm-rcv-cheat that an implementation is "likely"?

Section 2.1.  Capability Negotiation
   
   The TCP server sends the AccECN
   Option on the SYN/ACK and the client sends it on the first ACK to
   test whether the network path forwards the option correctly.

[ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.

Section 7.  Security Considerations

[ms] I wonder about the security implications of "confusing" classic ECN and AccECN feedback in (passive) network monitoring solutions, most notably if packet sampling is used and no per-connection state is applied. At least theoretically, passive monitoring of "classic ECN" TCP header flags could be used for network monitoring, e.g., to estimate congestion levels in a network, no? How would such a (hypothetical) passive monitoring solution be able to distinguish the standard ECN feedback from an ongoing AccECN experiment, in particular in a sampled packet stream w/o having access to the SYN negotiation? Would there be security or safety implications when experimenting with AccECN in networks using network monitoring solutions that only support ECN as standardized by the IETF?

Thanks

Michael (chair hat off)

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 16 Jul 2018 11:15:37 +0200

Hi Michael,

Am 15.07.2018 um 22:54 schrieb Scharf, Michael (Nokia - DE/Stuttgart):
 > [...]

For the safety aspect, if a middlebox meddles with the tcp header bits, 
and doesn't forward segments with specific ACE field codepoints, a 
reasonable response would be to resend the second or third 
retransmission with ECN disabled, and disable ECN for the remainder of 
the session. However, none of the large scale measurements conducted so 
far has found an indication of such a middlebox misbehavior to warrant 
text here. The regular AccECN negotiation will capture all known 
misbehaving middleboxes.

As to the passive monitoring - Mirja and Brian will certainly expand on 
this, but sampling ever so often should expose ACE field codepoints with 
high probability, which are unlikely or not possible with RFC3168 ECN 
(e.g. CWR + ECE is very unlikely - pure ACKs are not ECT marked in 
RFC3168, and bidirectional data exchange without stretches of pure acks 
is not common), anything with the former "NS" bit set has never been 
observed on the public internet to my knowledge. To summarize random 
sampling has at least a 5/8th chance to detect AccECN. However, as r.cep 
(section 3.2) is initialized to a value of 5 (101b), and many (short) 
flows probably rarely encounter a CE mark, the chance to detect, by 
random sampling, the presence of AccECN passively is even higher than 
this.  Short flow with up to 2 CE marks are immediately detectable, as 
the former "NS" bit remains set.

As to the passive monitoring of the congestion levels - the same problem 
of having only 1 bit signal per RTT applies here too, not? Also, you 
probably don't know where the congestion point (doing the CE marks) is 
from your vantage point, but looking at the TCP header flags to estimate 
the congestion levels is IMHO not the correct approach - for that, you'd 
want to evaluate the IP header "CE" marks, and AccECN does not change 
that at all...

If anything, AccECN should improve the passive monitoring of congestion 
*levels* (on asymetric paths) as now the monitoring point can track each 
CE in the reverse path; formerly, you could only use the stream of ECEs 
to estimate the connection receive window (spin bit), but not the extent 
of congestion in the network...

This "former use" of the ECE bit could be taken over by a different 
signal - see https://tools.ietf.org/html/draft-trammell-tsvwg-spin :)

Best regards,
   Richard

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Mon, 16 Jul 2018 17:48:17 +0000

Inline...

> -----Original Message-----
> From: Scheffenegger, Richard [mailto:[email-masked]]
> Sent: Monday, July 16, 2018 11:16 AM
> To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
> 
> Hi Michael,
> 
> 
> 
> > [ms] I wonder about the security implications of "confusing" classic ECN and
> AccECN feedback in (passive) network monitoring solutions, most notably if
> packet sampling is used and no per-connection state is applied. At least
> theoretically, passive monitoring of "classic ECN" TCP header flags could be
> used for network monitoring, e.g., to estimate congestion levels in a
> network, no? How would such a (hypothetical) passive monitoring solution
> be able to distinguish the standard ECN feedback from an ongoing AccECN
> experiment, in particular in a sampled packet stream w/o having access to
> the SYN negotiation? Would there be security or safety implications when
> experimenting with AccECN in networks using network monitoring solutions
> that only support ECN as standardized by the IETF?
> >
> 
> For the safety aspect, if a middlebox meddles with the tcp header bits, and
> doesn't forward segments with specific ACE field codepoints, a reasonable
> response would be to resend the second or third retransmission with ECN
> disabled, and disable ECN for the remainder of the session. However, none
> of the large scale measurements conducted so far has found an indication of
> such a middlebox misbehavior to warrant text here. The regular AccECN
> negotiation will capture all known misbehaving middleboxes.

This comment is not about middleboxes; it is about passive network monitoring for traffic engineering.

> As to the passive monitoring - Mirja and Brian will certainly expand on this,
> but sampling ever so often should expose ACE field codepoints with high
> probability, which are unlikely or not possible with RFC3168 ECN (e.g. CWR +
> ECE is very unlikely - pure ACKs are not ECT marked in RFC3168, and
> bidirectional data exchange without stretches of pure acks is not common),
> anything with the former "NS" bit set has never been observed on the public
> internet to my knowledge. To summarize random sampling has at least a
> 5/8th chance to detect AccECN. However, as r.cep (section 3.2) is initialized to
> a value of 5 (101b), and many (short) flows probably rarely encounter a CE
> mark, the chance to detect, by random sampling, the presence of AccECN
> passively is even higher than this.  Short flow with up to 2 CE marks are
> immediately detectable, as the former "NS" bit remains set.

To me, this sort of discussion belongs into the document.

> As to the passive monitoring of the congestion levels - the same problem of
> having only 1 bit signal per RTT applies here too, not? Also, you probably
> don't know where the congestion point (doing the CE marks) is from your
> vantage point, but looking at the TCP header flags to estimate the congestion
> levels is IMHO not the correct approach - for that, you'd want to evaluate the
> IP header "CE" marks, and AccECN does not change that at all...

Agreed, but it may not be easy to figure out if some passive monitoring solution still analyzes the standardized ECN bits in the TCP header.

Michael

> *levels* (on asymetric paths) as now the monitoring point can track each CE
> in the reverse path; formerly, you could only use the stream of ECEs to
> estimate the connection receive window (spin bit), but not the extent of
> congestion in the network...
> 
> This "former use" of the ECE bit could be taken over by a different signal -
> see https://tools.ietf.org/html/draft-trammell-tsvwg-spin :)
> 
> Best regards,
>    Richard
> 
> 
> 
>

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 16 Jul 2018 19:12:50 -0400

Michael,

> To: Scharf, Michael (Nokia - DE/Stuttgart)<[email-masked]>;
> [email-masked];[email-masked]
On 16/07/18 13:48, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>>> [ms] I wonder about the security implications of "confusing" classic ECN
>>> and AccECN feedback in (passive) network monitoring solutions,
>>>
[snip]
>> [RS] As to the passive monitoring - Mirja and Brian will certainly expand on this,
> [ms] To me, this sort of discussion belongs into the document.
>
[BB] Although it's interesting to consider whether passive monitoring 
would be able to detect a difference between one version of a protocol 
and another, I think any discussion of that belongs in a draft about 
passive monitoring, or in mailing list discussion (as here). Not in a 
protocol spec.

We can't be expected to have to ensure that new protocols can be 
distinguished from old protocols by monitoring systems that haven't been 
properly programmed to look for the protocol negotiation during the 
handshake. If such a monitoring system is controlling something critical 
and it's not monitoring correctly, that is surely a safety issue with 
the monitoring system, not with the new protocol.

Having just been talking to a colleague who set up the monitoring 
systems for a mobile operator, the first and most obvious thing they do 
is look for the flow starts.

Bob

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

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 16 Jul 2018 19:34:02 -0400

Michael,

> [ms] I have commented on this section before. And I still dislike the term "likely". To me, "likely" is speculation. A neutral phrasing would be "... it is possible..." or "... it is useful...". Ha…

I agree. For ECN++, I think something like your suggestion of "useful", 
or even RECOMMENDED is what is needed here. I think the testing receiver 
compliance one could be removed from the intro. It's mentioned under 
testing for unexpected interference and under integrity checking, which 
are sufficient.

Also, this makes me notice that the word "includes" is wrong. ECN++ 
intends to obsolete RFC5562, but I don't think we need to mention that 
here (cos it might change before ECN++ gets published).

CURRENT TEXT:

    It is likely (but not required) that the AccECN protocol will be
    implemented along with the following experimental additions to the
    TCP-ECN protocol: ECN-capable TCP control packets and retransmissions
    [I-D.ietf-tcpm-generalized-ecn 
<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#ref-I-D.ietf-tcpm-generalized-ecn>], which includes the ECN-capable SYN/
    ACK experiment [RFC5562 <https://tools.ietf.org/html/rfc5562>]; and testing receiver non-compliance
    [I-D.moncaster-tcpm-rcv-cheat 
<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#ref-I-D.moncaster-tcpm-rcv-cheat>].

PROPOSED TEXT:

    It is RECOMMENDED that the AccECN protocol is implemented along with
    the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#ref-I-D.ietf-tcpm-generalized-ecn>].

> [ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragra…
OK, we need to review section 2, to ensure it is consistent with changes 
that have been made in the normative section 3 since it was written.

In this particular case, we already promised to check (offlist with an 
implementer) that there was no text that contradicted the optionality of 
the option stated at the end of Section 3.2.6.

I have already started this with a list I prepared (also offlist) of 
which middlebox checking sections an implementer could ignore if they 
were only reading but not sending the TCP options.

Bob

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Tue, 17 Jul 2018 05:03:55 +0000

I disagree. I believe it would be possible to design a protocol spec that is more backward compatible with standardized ECN on the wire, which would not cause issue to (potentially) deployed passive monitoring systems that use packet sampling. Such passive monitoring systems could e.g. make wrong traffic engineering decisions because the TCP connection is not compliant to the ECN standards. Anomaly detection could also be triggered as the TCP header of packets deviates from the IETF standards. Due to the limited deployment of ECN, it is possible that this is not an important problem.

Yet, it is a design choice of the protocol that within a sampled packet stream standardized ECN cannot be distinguished from the proposed experiment, and that the experimental TCP header encoding on the wire is not backward compatible to the existing standards.

I believe a discussion on potential operational impact on potentially deployed systems belong into the document, e.g., along the lines of the text of Richard has written.

Michael

From: Bob Briscoe [mailto:[email-masked]]
Sent: Tuesday, July 17, 2018 1:13 AM
To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>; Scheffenegger, Richard <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

Michael,

-----Original Message-----

To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]><mailto:[email-masked]>;

[email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Michael,

[snip]

[BB] Although it's interesting to consider whether passive monitoring would be able to detect a difference between one version of a protocol and another, I think any discussion of that belongs in a draft about passive monitoring, or in mailing list discussion (as here). Not in a protocol spec.

We can't be expected to have to ensure that new protocols can be distinguished from old protocols by monitoring systems that haven't been properly programmed to look for the protocol negotiation during the handshake. If such a monitoring system is controlling something critical and it's not monitoring correctly, that is surely a safety issue with the monitoring system, not with the new protocol.

Having just been talking to a colleague who set up the monitoring systems for a mobile operator, the first and most obvious thing they do is look for the flow starts.

Bob

--

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Tue, 17 Jul 2018 05:05:17 +0000

This would for for me.

Thanks

Michael

From: Bob Briscoe [mailto:[email-masked]]
Sent: Tuesday, July 17, 2018 1:34 AM
To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

Michael,

Hi all,

Section 1. Introduction

I agree. For ECN++, I think something like your suggestion of "useful", or even RECOMMENDED is what is needed here. I think the testing receiver compliance one could be removed from the intro. It's mentioned under testing for unexpected interference and under integrity checking, which are sufficient.

Also, this makes me notice that the word "includes" is wrong. ECN++ intends to obsolete RFC5562, but I don't think we need to mention that here (cos it might change before ECN++ gets published).

CURRENT TEXT:

   [I-D.ietf-tcpm-generalized-ecn<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#ref-I-D.ietf-tcpm-generalized-ecn>], which includes the ECN-capable SYN/

   ACK experiment [RFC5562<https://tools.ietf.org/html/rfc5562>]; and testing receiver non-compliance

   [I-D.moncaster-tcpm-rcv-cheat<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#ref-I-D.moncaster-tcpm-rcv-cheat>].
PROPOSED TEXT:

   the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#ref-I-D.ietf-tcpm-generalized-ecn>].

[ms] According to Section 3.2.6, options are RECOMMENDED. While Section 2 is not normative, the whole Section 2 does not really describe well the actual requirements regarding options. This paragraph in Section 2.1 is one example for that. It would make sense to be more explicit in Section 2 to which extent options have to be supported.
OK, we need to review section 2, to ensure it is consistent with changes that have been made in the normative section 3 since it was written.

In this particular case, we already promised to check (offlist with an implementer) that there was no text that contradicted the optionality of the option stated at the end of Section 3.2.6.

I have already started this with a list I prepared (also offlist) of which middlebox checking sections an implementer could ignore if they were only reading but not sending the TCP options.

Bob

--

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 17 Jul 2018 08:42:30 -0400

Michael,

I've written the proposed edits into a local copy of draft-08, which 
we'll post after this IETF.

Wile writing the last point, I thought it best to add an extra sentence.

    the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#ref-I-D.ietf-tcpm-generalized-ecn>].
    [I-D.ietf-tcpm-generalized-ecn] is a proposed alternative to another
    experimental scheme [RFC5562] so there is no need to implement RFC
    5562 along with AccECN.

Bob

On 17/07/18 01:05, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
> This would for for me.
>
> Thanks
>
> Michael
>
> *From:*Bob Briscoe [mailto:[email-masked]]
> *Sent:* Tuesday, July 17, 2018 1:34 AM
> *To:* Scharf, Michael (Nokia - DE/Stuttgart) 
> <[email-masked]>; [email-masked]; 
> [email-masked]
> *Subject:* Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
>
> Michael,
>
> I agree. For ECN++, I think something like your suggestion of 
> "useful", or even RECOMMENDED is what is needed here. I think the 
> testing receiver compliance one could be removed from the intro. It's 
> mentioned under testing for unexpected interference and under 
> integrity checking, which are sufficient.
>
> OK, we need to review section 2, to ensure it is consistent with 
> changes that have been made in the normative section 3 since it was 
> written.
>
> implementer) that there was no text that contradicted the optionality 
> of the option stated at the end of Section 3.2.6.
>
> Bob Briscoehttp://bobbriscoe.net/

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Tue, 17 Jul 2018 12:57:01 +0000

I would prefer the first, shorter wording.

For instance, it would be possible that TCPM decides to obsolete RFC 5562. I’d suggest to keep the status and future use of RFC 5562 in combination with ECN++ outside of this document.

What might be in scope of the AccECN spec would be a hypothetical use of AccECN in combination with RFC 5562. But I would be fine with just omitting that. Alternatively, a more statement not related to the status would be “a combination of AccECN with RFC 5562 is outside the scope of this document”.

Actually, I am also not sure if this paragraph is a good example for RECOMMENDED in a capital letters. To me, the following would be sufficient:

   It is recommended that the AccECN protocol is implemented along with

Michael

From: Bob Briscoe [mailto:[email-masked]]
Sent: Tuesday, July 17, 2018 2:43 PM
To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

Michael,

I've written the proposed edits into a local copy of draft-08, which we'll post after this IETF.

   5562 along with AccECN.

Bob

Thanks

Michael

From: Bob Briscoe [mailto:[email-masked]]
Sent: Tuesday, July 17, 2018 1:34 AM
To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

Michael,

Hi all,

Section 1. Introduction

CURRENT TEXT:

Bob

--

--

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 17 Jul 2018 15:58:19 +0200

Hi,

I agree, the RECOMMENDED would belong to the actual mechanisms which 
would make use of the increased fidelity of the feedback mechanism.

The feedback mechanism can be implemented to provide both signals - one 
that is compatible with the legacy use of ECN, and one with high 
accuracy. These are implementation details though. However, AccECN would 
be functionally backwards compatible with 3168 and therefor work with 
all algorithms using ECN signals.

Adding the out-of-scope statement seems like a good approach to me.

Regards,
   Richard

Am 17.07.2018 um 14:57 schrieb Scharf, Michael (Nokia - DE/Stuttgart):
> For instance, it would be possible that TCPM decides to obsolete RFC 
> 5562. I’d suggest to keep the status and future use of RFC 5562 in 
> combination with ECN++ outside of this document.
> 
> What might be in scope of the AccECN spec would be a hypothetical use of 
> AccECN in combination with RFC 5562. But I would be fine with just 
> omitting that. Alternatively, a more statement not related to the status 
> would be “a combination of AccECN with RFC 5562 is outside the scope of 
> this document”.
> 
> Actually, I am also not sure if this paragraph is a good example for 
> RECOMMENDED in a capital letters. To me, the following would be sufficient:
> 
> *Sent:* Tuesday, July 17, 2018 2:43 PM
> *To:* Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>; 
>     <[email-masked]> <mailto:[email-masked]>;
>     [email-masked]
>     <mailto:[email-masked]>; [email-masked]
>     <mailto:[email-masked]>
>     testing receiver compliance one could be removed from the intro.
>     It's mentioned under testing for unexpected interference and under
>     intends to obsolete RFC5562, but I don't think we need to mention
>     that here (cos it might change before ECN++ gets published).
> 
>     CURRENT TEXT:
> 
>     In this particular case, we already promised to check (offlist with
>     an implementer) that there was no text that contradicted the
>     optionality of the option stated at the end of Section 3.2.6.
> 
>     which middlebox checking sections an implementer could ignore if
>     they were only reading but not sending the TCP options.
> 
> 
> 
> 
>     Bob
> 
> 
> 
> 
>     -- 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 17 Jul 2018 16:28:05 -0400

Michael,

OK RECOMMENDED -> recommended.
That's good, otherwise I think ECN++ would have become a normative 
reference.

> Alternatively, a more statement not related to the status would be “a 
> combination of AccECN with RFC 5562 is outside the scope of this 
> document”.
Someone who had never even thought about combining AccECN with RFC5562 
might think we mean "AccECN could also be combined with RFC5562, but 
this isn't the place to talk about it?"

How about:

    It is recommended that the AccECN protocol is implemented alongside

    the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#ref-I-D.ietf-tcpm-generalized-ecn>].
    Therefore, this specification does not discuss implementing AccECN
    alongside the earlier experimental alternative to ECN++ in [RFC5562].

Bob

On 17/07/18 08:57, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> What might be in scope of the AccECN spec would be a hypothetical use 
> of AccECN in combination with RFC 5562. But I would be fine with just 
> omitting that. Alternatively, a more statement not related to the 
> status would be “a combination of AccECN with RFC 5562 is outside the 
> scope of this document”.
>
>     Also, this makes me notice that the word "includes" is wrong.
>     ECN++ intends to obsolete RFC5562, but I don't think we need to
>     mention that here (cos it might change before ECN++ gets published).
>
>     CURRENT TEXT:
>
>     changes that have been made in the normative section 3 since it
>     was written.
>
>     In this particular case, we already promised to check (offlist
>     with an implementer) that there was no text that contradicted the
>     I have already started this with a list I prepared (also offlist)
>     of which middlebox checking sections an implementer could ignore
>     if they were only reading but not sending the TCP options.
>
>
>
>
>     Bob
>
>
>
>
>     -- 
>

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Tue, 17 Jul 2018 21:01:58 +0000

This wording would imply that ECN++ and RFC 5562 are indeed “alternatives”. That is IMHO not fully correct, ECN++ seems to have a broader scope.

I think something along the lines of …

   This specification does not discuss implementing AccECN

   alongside the experimental protocol [RFC5562].

… does the job.

Michael

From: Bob Briscoe [mailto:[email-masked]]
Sent: Tuesday, July 17, 2018 10:28 PM
To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

Michael,

OK RECOMMENDED -> recommended.
That's good, otherwise I think ECN++ would have become a normative reference.

Alternatively, a more statement not related to the status would be “a combination of AccECN with RFC 5562 is outside the scope of this document”.
Someone who had never even thought about combining AccECN with RFC5562 might think we mean "AccECN could also be combined with RFC5562, but this isn't the place to talk about it?"

How about:

Bob

Michael

Michael,

   5562 along with AccECN.

Bob

Thanks

Michael

Michael,

Hi all,

Section 1. Introduction

CURRENT TEXT:

Bob

--

--

--

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 18 Jul 2018 06:14:29 -0400

Michael,

That regains the problem I said I was trying remove, of risking implying 
"AccECN could also be combined with RFC5562, but this isn't the place to 
talk about it?", by not explaining that ECN++ subsumes the function of 
RFC5562. How about:

    the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#ref-I-D.ietf-tcpm-generalized-ecn>].
    This specification does not discuss implementing AccECN alongside
    [RFC5562], which was an earlier experimental protocol with narrower
    scope than ECN++.

Bob

On 17/07/18 17:01, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
>
> This wording would imply that ECN++ and RFC 5562 are indeed 
> “alternatives”. That is IMHO not fully correct, ECN++ seems to have a 
> broader scope.
>
> …does the job.
> *Sent:* Tuesday, July 17, 2018 10:28 PM
>     Alternatively, a more statement not related to the status would be
>     “a combination of AccECN with RFC 5562 is outside the scope of
>     this document”.
>
>     For instance, it would be possible that TCPM decides to obsolete
>     RFC 5562. I’d suggest to keep the status and future use of RFC
>     5562 in combination with ECN++ outside of this document.
>
>     What might be in scope of the AccECN spec would be a hypothetical
>     use of AccECN in combination with RFC 5562. But I would be fine
>     with just omitting that. Alternatively, a more statement not
>     related to the status would be “a combination of AccECN with RFC
>     5562 is outside the scope of this document”.
>
>     Actually, I am also not sure if this paragraph is a good example
>     for RECOMMENDED in a capital letters. To me, the following would
>     be sufficient:
>
>         "useful", or even RECOMMENDED is what is needed here. I think
>         the testing receiver compliance one could be removed from the
>         intro. It's mentioned under testing for unexpected
>         interference and under integrity checking, which are sufficient.
>
>         ECN++ intends to obsolete RFC5562, but I don't think we need
>         to mention that here (cos it might change before ECN++ gets
>         published).
>
>         CURRENT TEXT:
>
>         OK, we need to review section 2, to ensure it is consistent
>         with changes that have been made in the normative section 3
>         since it was written.
>
>         with an implementer) that there was no text that contradicted
>         the optionality of the option stated at the end of Section 3.2.6.
>
>         I have already started this with a list I prepared (also
>         offlist) of which middlebox checking sections an implementer
>         could ignore if they were only reading but not sending the TCP
>         options.
>
>
>
>
>         Bob
>
>
>
>
>
>         -- 
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 18 Jul 2018 06:17:56 -0400

Michael,

Sorry, I meant to add back in 'Therefore':

    the experimental ECN++ protocol [I-D.ietf-tcpm-generalized-ecn 
<https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-07#ref-I-D.ietf-tcpm-generalized-ecn>].
    Therefore, this specification does not discuss implementing AccECN alongside
    [RFC5562], which was an earlier experimental protocol with narrower
    scope than ECN++.

Bob

On 18/07/18 06:14, Bob Briscoe wrote:
> Michael,
>
> That regains the problem I said I was trying remove, of risking 
> implying "AccECN could also be combined with RFC5562, but this isn't 
> the place to talk about it?", by not explaining that ECN++ subsumes 
> the function of RFC5562. How about:
>
>>     Alternatively, a more statement not related to the status would
>>     be “a combination of AccECN with RFC 5562 is outside the scope of
>>     this document”.
>>
>> Someone who had never even thought about combining AccECN with 
>> RFC5562 might think we mean "AccECN could also be combined with 
>> RFC5562, but this isn't the place to talk about it?"
>>
>> How about:
>>
>>         In this particular case, we already promised to check
>>         (offlist with an implementer) that there was no text that
>>         contradicted the optionality of the option stated at the end
>>         of Section 3.2.6.
>>
>>         could ignore if they were only reading but not sending the
>>         TCP options.
>>
>>
>>
>>
>>         Bob
>>
>>
>>
>>
>>
>>         -- 
>>

---

From: "Scharf, Michael (Nokia - DE/Stuttgart)" <[email-masked]>
Date: Wed, 18 Jul 2018 13:12:04 +0000

The following wording might work for me:

   [RFC5562], which is an earlier experimental protocol.

As far as I know, the experiment of RFC 5562 has not been officially finished so far, i.e., use of past tense might not be appropriate.

(Personally, I could imagine that TCPM decides to finish the experiment of RFC 5562, but that question does not belong into this I-D.)

Michael

From: Bob Briscoe [mailto:[email-masked]]
Sent: Wednesday, July 18, 2018 12:18 PM
To: Scharf, Michael (Nokia - DE/Stuttgart) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

Michael,

   scope than ECN++.

Bob

That regains the problem I said I was trying remove, of risking implying "AccECN could also be combined with RFC5562, but this isn't the place to talk about it?", by not explaining that ECN++ subsumes the function of RFC5562. How about:

   scope than ECN++.

Bob

… does the job.

Michael

Michael,

How about:

Bob

Michael

Michael,

   5562 along with AccECN.

Bob

Thanks

Michael

Michael,

Hi all,

Section 1. Introduction

CURRENT TEXT:

Bob

--

--

--

--

--

---

From: Bob Briscoe <[email-masked]>
Date: Sat, 21 Jul 2018 12:23:27 +0100

Michael,

There is no past tense in my suggested wording, and no implication that 
5562 is obsolete. Nonetheless, I think you mean that I am saying RFC5562 
is an older experiment than ECN++. Yes, I suggested we say it that way, 
'cos that's a present fact. if anyone wants to read that as meaning that 
ECN++ is aiming to improve on 5562, that's fine 'cos that is also a fact.

I didn't want the AccECN draft to say that ECN++ /does/ improve on 5562, 
because that's a judgement, not a fact.

Bob

PS. Nonetheless, you will see that the ECN++ draft says "Obsoletes: 5562 
(if approved) " in the header block, and it provides very solid 
reasoning for why within the text. So the WG /is/ discussing that 
question, but you are right that it is not discussing that question in 
the context of the AccECN draft.

On 18/07/18 14:12, Scharf, Michael (Nokia - DE/Stuttgart) wrote:
> As far as I know, the experiment of RFC 5562 has not been officially 
> finished so far, i.e., use of past tense might not be appropriate.
>
> (Personally, I could imagine that TCPM decides to finish the 
> experiment of RFC 5562, but that question does not belong into this I-D.)
>
> Michael
>
> *Sent:* Wednesday, July 18, 2018 12:18 PM
>     implying "AccECN could also be combined with RFC5562, but this
>     isn't the place to talk about it?", by not explaining that ECN++
>     subsumes the function of RFC5562. How about:
>
>         “alternatives”. That is IMHO not fully correct, ECN++ seems to
>         have a broader scope.
>
>             Alternatively, a more statement not related to the status
>             would be “a combination of AccECN with RFC 5562 is outside
>             the scope of this document”.
>
>         RFC5562 might think we mean "AccECN could also be combined
>         with RFC5562, but this isn't the place to talk about it?"
>
>         How about:
>
>             For instance, it would be possible that TCPM decides to
>             obsolete RFC 5562. I’d suggest to keep the status and
>             future use of RFC 5562 in combination with ECN++ outside
>             of this document.
>
>             What might be in scope of the AccECN spec would be a
>             hypothetical use of AccECN in combination with RFC 5562.
>             But I would be fine with just omitting that.
>             Alternatively, a more statement not related to the status
>             would be “a combination of AccECN with RFC 5562 is outside
>             the scope of this document”.
>
>             Actually, I am also not sure if this paragraph is a good
>             example for RECOMMENDED in a capital letters. To me, the
>             following would be sufficient:
>
>             <mailto:[email-masked]>;
>             [email-masked] <mailto:[email-masked]>
>             I've written the proposed edits into a local copy of
>             draft-08, which we'll post after this IETF.
>
>                 <mailto:[email-masked]>;
>                 [email-masked] <mailto:[email-masked]>
>                 I agree. For ECN++, I think something like your
>                 suggestion of "useful", or even RECOMMENDED is what is
>                 needed here. I think the testing receiver compliance
>                 one could be removed from the intro. It's mentioned
>                 under testing for unexpected interference and under
>                 Also, this makes me notice that the word "includes" is
>                 wrong. ECN++ intends to obsolete RFC5562, but I don't
>                 think we need to mention that here (cos it might
>                 change before ECN++ gets published).
>
>                 CURRENT TEXT:
>
>                 OK, we need to review section 2, to ensure it is
>                 consistent with changes that have been made in the
>                 normative section 3 since it was written.
>
>                 (offlist with an implementer) that there was no text
>                 that contradicted the optionality of the option stated
>                 at the end of Section 3.2.6.
>
>                 I have already started this with a list I prepared
>                 (also offlist) of which middlebox checking sections an
>                 implementer could ignore if they were only reading but
>                 not sending the TCP options.
>
>
>
>
>                 Bob
>
>
>
>
>
>
>                 -- 
>