IETF Logo Mail Archive

Re: [tcpm] A possible simplification for AccECN servers

Mirja Kuehlewind <ietf@kuehlewind.net> Mon, 25 November 2019 17:02 UTC

Return-Path: <ietf@kuehlewind.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 B2C4612099E for <tcpm@ietfa.amsl.com>; Mon, 25 Nov 2019 09:02:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 Jr7oms4TjOUx for <tcpm@ietfa.amsl.com>; Mon, 25 Nov 2019 09:02:10 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 031CB12099A for <tcpm@ietf.org>; Mon, 25 Nov 2019 09:02:09 -0800 (PST)
Received: from 200116b82c892300b4b6b2442066fb94.dip.versatel-1u1.de ([2001:16b8:2c89:2300:b4b6:b244:2066:fb94]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iZHkU-0007YI-TD; Mon, 25 Nov 2019 18:02:06 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <A76315DB-B3B4-45A4-A8CA-5F4701EB4085@gmail.com>
Date: Mon, 25 Nov 2019 18:02:05 +0100
Cc: Bob Briscoe <ietf@bobbriscoe.net>, tcpm IETF list <tcpm@ietf.org>, Richard Scheffenegger <rscheff@gmx.at>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F90043A1-87F5-4DD1-BB11-AE8D2F3C5A7E@kuehlewind.net>
References: <d35618ee-c0dc-44ee-9e22-50bdabbe026c@bobbriscoe.net> <732C4247-BC55-4719-A399-711689CB379A@kuehlewind.net> <256E6F9D-607A-4A9D-9505-933FC4EC28FC@gmail.com> <333DA677-0930-45B2-AC65-05852FC46955@kuehlewind.net> <A76315DB-B3B4-45A4-A8CA-5F4701EB4085@gmail.com>
To: Jonathan Morton <chromatix99@gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1574701330;9d151d66;
X-HE-SMSGID: 1iZHkU-0007YI-TD
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/sIJ_8cVwdKrrpdJW-HgtytcUod4>
Subject: Re: [tcpm] A possible simplification for AccECN servers
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, 25 Nov 2019 17:02:12 -0000

Hi Jonathan,

Sorry I wasn’t clear. I think we should not have these normative requirement in the draft and change the text to make it non-normative. This section was meant to explain which modes you end up in and the current use of normative language doesn’t seem to be right to me. 

Likewise the table was also not meant to say whenever you implement AccECN, you MUST negotiate it in the handshake. And likewise the table does not show any classic ECN only transitions.

Mirja


> On 25. Nov 2019, at 17:48, Jonathan Morton <chromatix99@gmail.com> wrote:
> 
>> On 25 Nov, 2019, at 6:43 pm, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
>> 
>> I don’t think we can or should derive a normative requirement from this table. The table rather explains which mode you are in depending on the handshake that has happened. So it says: when client A is ECN capable and requests classic ECN support in the handshake and server B is AccECN capable and negotiated classic ECN support in the handshake then you are in classic ECN mode. 
> 
> I will merely re-quote the final sentence from my quoted text, which transforms that table into a normative requirement:
> 
>>      Therefore, as soon as an
>>      AccECN-enabled TCP server (B) receives the SYN shown, it MUST set
>>      both its half connections into the feedback mode shown in the
>>      rightmost column.
> 
> - Jonathan Morton

v2.23.0 | Report a Bug | By Email