Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt

Sebastian Moeller <moeller0@gmx.de> Mon, 04 November 2019 09:17 UTC

Return-Path: <moeller0@gmx.de>
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 3B7BD120D84; Mon, 4 Nov 2019 01:17:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.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 r_S9pAi9Mi7R; Mon, 4 Nov 2019 01:17:11 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 8A098120D7F; Mon, 4 Nov 2019 01:17:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1572859027; bh=ggfCHP2vO/4u7p8XCIxUft6yagnvIa8LHf1DRuUolFI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=At61n2JVwHHm7m33E1xtzxsg3t8UVOa9auGi1hiUtUQNSoNWFHr8CScWZYtyI3pxH rDgykQez5gx97fzNir0KMdpoKEfqO7xomz0zu8b4TIhpg7BhGJel2eAWewdQ2Brgip KIEu0GfKWt4ltsvc66oHGK+6Cp1RJSPUbf1D2+go=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [10.11.12.33] ([134.76.241.253]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MsHns-1i6zLY0RI2-00tgnF; Mon, 04 Nov 2019 10:11:50 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <5DBFDF26.5080101@erg.abdn.ac.uk>
Date: Mon, 4 Nov 2019 10:11:48 +0100
Cc: Jonathan Morton <chromatix99@gmail.com>, "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, "tcpm@ietf.org" <tcpm@ietf.org>, "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BA2535E8-E7D9-430C-897C-DEAAFBC351A8@gmx.de>
References: <201911022326.xA2NQIYm093618@gndrsh.dnsmgr.net> <5DBEA1E3.9020009@erg.abdn.ac.uk> <66994B86-4EEA-45BC-80FA-31F1EF8EFE96@gmail.com> <5DBFDF26.5080101@erg.abdn.ac.uk>
To: gorry@erg.abdn.ac.uk
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:9tWeAfb/Ri2alT9BXCk75cYpBQGVBuhMUEhOUFUnlpS+w5scAal DEf6Tj85kb2FHt+HlaNRJlA6K8whCvOG2/pu410iBCTHTTBL91sLG4PpHwNqXVQn66KbSgJ fpV/HDAMk1bLEakef6WJTOsw5uR8lxBSOO47mkJSDjPPmgHfhI6nMee7BCf+ingx0Kya1Vt 1eRtMR/4nM7NuHkoLnlmg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:15J04BmW1/E=:u7/gHhYpC2jMEk0XsLtoDS KYcQ9QUVSg/G9pCc3XnpuwVpItgkEfoJmFG+ZKQXdTFfkbW4+O3dzjeG49i9y4GEuJ/o0BD4w /komWx2mOju7bCzhiOLGVi0zjWl87CxKbV3YmelYFHqpHavICBVf5cOE3FHyqKBwifmOtxTRv AS5/jE4y/+KlDcjmSopcvYpCegxXELFJ1tIYxofSy5GIx9qK63pqzp7/m2xGe5wfqQx/PU5FF xaEwcKKXIJpk9JDYp5EhVeI+f2Sgk34AHPEQE03Y/HpdsXn/wclzDhb2j2Yz+MGOwKzNFImZu R0vgPji3HGA6emZGbWkt4HKcZiBOOYKEpCKACUuF7YE6Gk5a+sfmUQ5YbjS6SCoNFxm905IM2 BrZGKxiaU7ZtGC1i37wR4GJBucmQxjnZRYNG04zShPqpqbCnYezk3NelyZoFyNza8FqXH4Kml logr3JJLVF9i/L2J/t9ctQ8ChwWkIkRlg5OOacIW7gD8n5iBNjg73B7SW9oRxwsrHyLcim1uL Bk6push3usRQjpNxu/0cei8AyhUYqwhae2Qz6cyUrGkJspNVY7TSQ9q72/RlOpQiuuKtrDBAI 8SRa6d+DkndLafyr7fLhWcGgMXLuEpiwkRvZDMokStBN3JY0TMbAdQFADhDtoDj2aVQbKJKa8 WrF9Jzjo94jSz4Y7DWuMQC2dam4rYwmUNK2MUPTM+TGVptMB9nRYj3u7Hzb1zZu5/Js5/dFQm mXMTQ7WmqOiwXimCWOeZg13LkI9lPl9nF3uEl4hwl6NKNlq03QWlWhkcwl3LNTIrNHoLcbwOe 2m/COt2NZ/fY6fzZeiqw7PzNO03jbYvofSZfEJzkrw9vE+wFDgznWKX2YNjU7gnZFwO8xQ6mf 59DdB9nya6ITuHl9F687zLiYfVcdqIyJzhuI53eZh65j09VRfyMYjvjaGD0ldjs7cUrYcoH3w tMrQrYn9A815VSgDZWf1odEjMVYEOZgS2QTT2EVb8pxMHez9ggBmAX9m2/Lrjwjr4NxHTTHOC KPikF/7qvR+Tfqus9OLvBy9cJc9K0HClcsgiW/VRAdvZNYeP/VtVGO8dLhoqTY6K6DRWUU+Vn Q7MSQj88K9LeQhEiDhMHyiM7SheOjb6ULXd1cpSqk82KKeR2Ju7qn0BgX1vMY8meRyVtW99KX Xg2zzEcJ9yUJSGHT29Oa2MUT7kVJEUhzp4X+Uqz+/maArnp2USJV9k3/GLnDDPUqTYtDQJ8sf d0U3sIQdS7DksZVnK76mJ+9pIY4aTH2KqTC51MQJ894iI46rPESLCB+JPnpg=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/DGgio-o23_fPcglQbSUeZ1szaCE>
Subject: Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 04 Nov 2019 09:17:13 -0000


> On Nov 4, 2019, at 09:19, Gorry Fairhurst <gorry@erg.abdn.ac.uk>; wrote:
> 
> On 03/11/2019, 13:08, Jonathan Morton wrote:
>>> On 3 Nov, 2019, at 11:46 am, Gorry Fairhurst<gorry@erg.abdn.ac.uk>;  wrote:
>>> 
>>>> With respect to draft-ietf-tcpm-accurate-ecn and
>>>> draft-grimes-tcpm-tcpsce compatibility:
>>>>   When accurate ecn (AccECN) fails to negotiate an AccECN capable session
>>>>   it falls back to RFC3168 conformance, leaving a state that is fully
>>>>   compatible with SCE, hence they are compatible.
>>> I was expecting this to fall-back to RFC8511, treatment at the endpointrs, since that is the most recent spec. Does that make any difference to your thoughts abiout what you expect an endpoint to do when it receives ECN-marking without Accurate ECN?
>> RFC-8511 doesn't change the signalling on the wire relative to RFC-3168.  That was the sense intended here.
>> 
>>  - Jonathan Morton
> RFC3168 describes both endpoint behaviour and network functions. To me, this sentence is about
> how you receive indications of incipent congestion, the sender can change from using only CE to using CE plus
> the accurate information -or fall back to using just CE - ultimately it falls back to just detecting congestion (loss,delay).
> So yes, the CE signal could be regarded as input to SCE.
> 
> The endpoint behaviour, I think, should fall back to RFC8511.
> 
> Gorry
> 

Question: Since the ABE RFC is marked experimental while RFC3168 is a proposed standard, why should tcpsce fall-back to RFC8511 instead of RFC3168? 
I ask as in the discussion of L4S it was (IMHO rightfully) argued that including a requirement on another experimental RFC (RACK in that case) was problematic as it would link basically independent experiments (and introduce undesired fate-sharing).

Sebastian