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

"Scheffenegger, Richard" <rs.ietf@gmx.at> Tue, 17 July 2018 13:59 UTC

Return-Path: <rs.ietf@gmx.at>
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 E25B7130FC4; Tue, 17 Jul 2018 06:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 PF9n03Rp8FUi; Tue, 17 Jul 2018 06:59:11 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32F2130F9D; Tue, 17 Jul 2018 06:59:05 -0700 (PDT)
Received: from [10.249.64.239] ([217.70.210.5]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LbuIK-1gM99t086G-00jMIs; Tue, 17 Jul 2018 15:58:21 +0200
To: "Scharf, Michael (Nokia - DE/Stuttgart)" <michael.scharf@nokia.com>, Bob Briscoe <ietf@bobbriscoe.net>, "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>
From: "Scheffenegger, Richard" <rs.ietf@gmx.at>
Message-ID: <b6874547-ea68-00ea-244f-4690ccbfaa15@gmx.at>
Date: Tue, 17 Jul 2018 15:58:19 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <VI1PR07MB088038B7B4E017DCCF4F2718935C0@VI1PR07MB0880.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K1:NzguQZxbcBwu+rR9VKDvJ8ylhm37QqpaZPZW8bbpQoOpUEQ0htp XwoJRGpMljTbdn9ush/Zj3ZRr7Xyh2okdcX2a0OI9hEm8FoD8SCPIp/J/EpPrOZwfmj2qqe Trtc75B2rVaJtK5d719Qbk/iURA0xM4uKZ2yYd3BSMKS0sJYWHBFXlbI2qKjBqRFJPqQk6V ohG0f2h3KbzENd9Q6VssQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:7VmrMuvd0r0=:UJsuLJdUtjrXuaGEG+s3Hk QLRWkaxHQ/xWNosE8yPBv8IzYnfDLxqAIjiE0eppTDuQaGDv9dnBXauMhKkIyPf3sZvHInj7O +t3TWI28F2ly+6RJEG8QX9065efBv4QVhg82dRccx+fInOKJxPxjlXlYI44SYGCjd+0j5QI4c zcZQZ2CSAGjDfYlp0F03VlCiQ6HruAm3ucpd59mFUDX4E7XgadQPMqAC2AVC0QBL1nMQsOGDo PTRl+BRS8eMP7gAPu1Yav8Oj9olJkKifLHlh68yLkSyczGTKeXwBk0C/H07aDPrMh+lMKiGzd FJjb4XWtwruiTZWz5Jwssf/0LN3YaFfdtBaBc5orUsvaC9pry8iYp0PfFuXRdQWM0acQmQIth oeJqmuWojcAitAMN16aHRT6MT6EUH0ZcpwQBO1/chSUA41sLuB5mCorWcfThvOwPD2XtbNVWP Efc68OmInr7+gmJlbK7y1oYnaHBjLmBNjRb9MfhdjL2fCUaZWOnMXqgtJMLDAKaSSl7naChOz 7ncfJ3UsjnBaSyBVpDpJjsKJHf0GMihd0T2791f1CJ58OlJwXQwjW0ZgCYCMZQ+1WcRieBy3Z eU78kAaUorul6Jl8E9RXGvZw0La0Xk9oyNeRZa7hKclRT5G1NyxF487KDxo3Ge7rN2bnTHT24 97aA0u6Xb5CuhWe/linqKfsSf3rso2RLSayCuz/Bm/GZyaMF2RrgJkGmPu0HKWueij15904WD PNZ9TIeoD3+yM+Jyo8f05k2EBQAxCwJA5L16VgRMUpGa7BgAwHZmxD5dKOSkgMXkPrmXFUTTb +LhBp+B
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/DSrcE_dN6_bRB5g-9CSqQuz81zM>
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: Tue, 17 Jul 2018 13:59:29 -0000

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):
> 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>om>; 
> draft-ietf-tcpm-accurate-ecn@ietf.org; 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/
> 
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>