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

["Scharf, Michael (Nokia - DE/Stuttgart)" <[e-mail]>]

The following wording might work for me:

   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

   [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:[e-mail]]
Sent: Wednesday, July 18, 2018 12:18 PM
To: Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

Michael,

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

   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

   [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:

   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>].

   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.

I think something along the lines of …


   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>].

   This specification does not discuss implementing AccECN

   alongside the experimental protocol [RFC5562].

… does the job.

Michael



From: Bob Briscoe [mailto:[e-mail]]
Sent: Tuesday, July 17, 2018 10:28 PM
To: Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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:

   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:
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

   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>].

Michael

From: Bob Briscoe [mailto:[e-mail]]
Sent: Tuesday, July 17, 2018 2:43 PM
To: Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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.

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

   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>].

   [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:[e-mail]]
Sent: Tuesday, July 17, 2018 1:34 AM
To: Scharf, Michael (Nokia - DE/Stuttgart) <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn

Michael,
On 15/07/18 16:54, Scharf, Michael (Nokia - DE/Stuttgart) wrote:

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"?

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>].












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.
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







--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/





--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/




--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/



--

________________________________________________________________

Bob Briscoe                               http://bobbriscoe.net/