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

[Bob Briscoe <[e-mail]>]

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]>; [e-mail]; 
>> [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 Briscoe                               http://bobbriscoe.net/