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

[Bob Briscoe <[e-mail]>]

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:
>
> 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 Briscoehttp://bobbriscoe.net/
>
>
>
>
>
>             -- 
>
>             ________________________________________________________________
>
>             Bob Briscoehttp://bobbriscoe.net/
>
>
>
>
>         -- 
>
>         ________________________________________________________________
>
>         Bob Briscoehttp://bobbriscoe.net/
>
>
>
>     -- 
>
>     ________________________________________________________________
>
>     Bob Briscoehttp://bobbriscoe.net/
>
>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

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