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

Bob Briscoe <ietf@bobbriscoe.net> Wed, 18 July 2018 10:14 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6C8131132; Wed, 18 Jul 2018 03:14:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbvxd4BzkZwL; Wed, 18 Jul 2018 03:14:35 -0700 (PDT)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3766F130F37; Wed, 18 Jul 2018 03:14:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7lCxbr/OT+6WJC4YgIJLt/Fc+fBQrdIcfstbQ+JEkjU=; b=ZXajp1VF15SDCgMMtSRs8qS7K C0A7hGFHIC/AlayYiLK0B0Idldy2Q6RlAXY0B2teUCfCfwI2q+/+OiJc55AXJkdws83RShgkiH69j cuwBYlmAIWs23LLX3I9TJWlBzu3RMRhUUnSPkls+KJfhRDcccaONI38q/5KiS23CJY3P6H33KAhGC wmJpArSqz9erlyj0Md7VNEToLZ3kRLxwnME1nl0mYfecROmT15v5Un3OAvs388fXtaM6CcGeC5U4L 9ivM+S0UYNW5EZAUmOGEvAsTN95F6ulHTAWF4eKXAlZAv7cHOPSlZGolzOpZ7FRn51/mlk6oy5RB4 WRP2FYj7Q==;
Received: from mtrlpq426kw-lp140-01-65-94-232-118.dsl.bell.ca ([65.94.232.118]:59948 helo=[192.168.2.57]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <ietf@bobbriscoe.net>) id 1ffjTb-00068V-4p; Wed, 18 Jul 2018 11:14:31 +0100
To: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>, "draft-ietf-tcpm-accurate-ecn@ietf.org" <draft-ietf-tcpm-accurate-ecn@ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
References: <AM2PR07MB086725AB3E0DFF2CFFAAE07A935E0@AM2PR07MB0867.eurprd07.prod.outlook.com> <9cc642a7-10e9-3adb-2c49-4a52da9d206c@bobbriscoe.net> <VI1PR07MB0880170EF06C9CE1C63A464C935C0@VI1PR07MB0880.eurprd07.prod.outlook.com> <b9125c5a-d774-8d16-aec5-6712bd4bdb2f@bobbriscoe.net> <VI1PR07MB088038B7B4E017DCCF4F2718935C0@VI1PR07MB0880.eurprd07.prod.outlook.com> <c79e6b9f-c270-64b6-c6c0-1250b0c04fc6@bobbriscoe.net> <VI1PR07MB088008BBCA30D8391D31E302935C0@VI1PR07MB0880.eurprd07.prod.outlook.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <fad5a5f9-b861-fc32-85e3-142212fb0113@bobbriscoe.net>
Date: Wed, 18 Jul 2018 06:14:29 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <VI1PR07MB088008BBCA30D8391D31E302935C0@VI1PR07MB0880.eurprd07.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------B477C5D3CA80A8455F168BA7"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/BOkIwMSSPlIjhLUoBjZcYGCNO_8>
Subject: Re: [tcpm] Further comments on draft-ietf-tcpm-accurate-ecn
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jul 2018 10:14:41 -0000

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:ietf@bobbriscoe.net]
> *Sent:* Tuesday, July 17, 2018 10:28 PM
> *To:* Scharf, Michael (Nokia - DE/Stuttgart) 
> <michael.scharf@nokia.com>om>; draft-ietf-tcpm-accurate-ecn@ietf.org; 
> tcpm@ietf.org
> *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:ietf@bobbriscoe.net]
>     *Sent:* Tuesday, July 17, 2018 2:43 PM
>     *To:* Scharf, Michael (Nokia - DE/Stuttgart)
>     <michael.scharf@nokia.com> <mailto:michael.scharf@nokia.com>;
>     draft-ietf-tcpm-accurate-ecn@ietf.org
>     <mailto:draft-ietf-tcpm-accurate-ecn@ietf.org>; tcpm@ietf.org
>     <mailto:tcpm@ietf.org>
>     *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:ietf@bobbriscoe.net]
>         *Sent:* Tuesday, July 17, 2018 1:34 AM
>         *To:* Scharf, Michael (Nokia - DE/Stuttgart)
>         <michael.scharf@nokia.com> <mailto:michael.scharf@nokia.com>;
>         draft-ietf-tcpm-accurate-ecn@ietf.org
>         <mailto:draft-ietf-tcpm-accurate-ecn@ietf.org>; tcpm@ietf.org
>         <mailto:tcpm@ietf.org>
>         *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 Briscoe                               http://bobbriscoe.net/