Re: [tcpm] A possible simplification for AccECN servers

Bob Briscoe <ietf@bobbriscoe.net> Wed, 11 December 2019 10:13 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 91968120130 for <tcpm@ietfa.amsl.com>; Wed, 11 Dec 2019 02:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 chMzmt4jFSH6 for <tcpm@ietfa.amsl.com>; Wed, 11 Dec 2019 02:13:04 -0800 (PST)
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 513A41200E9 for <tcpm@ietf.org>; Wed, 11 Dec 2019 02:13:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=QK+riQl7ovm3QSe7oMB5QQtHV+f59x0rGYORsv5kWkE=; b=2ZaXLmW/hyof2Ha5RN1utE4X/C cOC3VrYdG7H77R8w1FZsZ79JGXzLZCUq5R0tCnG2YrBKB/aLSQ0NDcpWlzo75WR/PGu38zsbgHeGE 3cY3+VKpEy2UkvMb9sPk84m8E1ncVWTEx3YOaIrPVk16iHbw5l+YWT2lQB3mRAs80HsuKbOuRCBBh oQAC+CVjSSirEHHuQkJSqgoplGlqDyp8C2iWoBwIOTk71+MBAahcIAZS67cVI5ejR1QKqM8wGxgF2 OE/JwBsLr27rtgJbo6125rhuTm5Tm2JYso4YD1WynDbpF59CsqWFp8LgraLdRKG6CkTn6knZ8maLC vIVxhQZQ==;
Received: from [31.185.128.31] (port=44906 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <ietf@bobbriscoe.net>) id 1ieyzM-0000je-Rb; Wed, 11 Dec 2019 10:13:01 +0000
To: Mirja Kuehlewind <ietf@kuehlewind.net>
Cc: Jonathan Morton <chromatix99@gmail.com>, tcpm IETF list <tcpm@ietf.org>, Richard Scheffenegger <rscheff@gmx.at>
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> <F90043A1-87F5-4DD1-BB11-AE8D2F3C5A7E@kuehlewind.net> <86dd14dc-0c24-d604-ea57-b280407a1a09@bobbriscoe.net> <CCA9AFF7-6EBB-4DB0-B851-7806B8E96871@kuehlewind.net> <74fe4c25-6ea2-ac5e-e59e-51acfd54be5f@bobbriscoe.net> <F74FD1C5-DB49-45FB-8AF8-73CCE1A125EC@kuehlewind.net>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <6ea44dd6-e830-2bce-39a2-d0efd7a90b2e@bobbriscoe.net>
Date: Wed, 11 Dec 2019 10:12:59 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <F74FD1C5-DB49-45FB-8AF8-73CCE1A125EC@kuehlewind.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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/dKVZ3G1mdN-D7pP6nYbAW6PLOdA>
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: Wed, 11 Dec 2019 10:13:07 -0000

Mirja,

On 11/12/2019 08:48, Mirja Kuehlewind wrote:
> Hi Bob,
>
> Sorry about your laptop (but if I remember correctly, it was broken anyway…). I think we do agree (and did from the beginning). Yes, I think my first statement below was overly broad and I did not meant to remove all normative language from that section. I was only referring to language that talked about RFC3168 negotiation.
>
> You propose below that an AccECN sender "MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0)” and I'm rather saying that we should not use normative language here but rather say something like: “If an AccECN sender received a 3168 SYN (without AE=1 respectively) is replies as specified in RFC3168 if it is configured to support classic ECN.” Or something like that. That’s all :-)
Pls respond to my two points (that keep getting overlooked), both 
starting with "This cannot be said by referring to 3168" further down 
the email.


Bob
>
> Mirja
>
>
>
>> On 11. Dec 2019, at 03:19, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>
>> Mirja,
>>
>> On 23/1119 I sent an analysis of the changes that would need to be made to the AccECN draft if it became stds track (which would imply that it then updates RFC3168) instead of expt track. For context, please read and possibly respond to that before you respond to this email.
>>
>> However, my email below applies whether AccECN is stds track or expt track.
>>
>> I've shifted the quoting back into order below, so the context is more clear, and I've then responded inline...
>>>> On 25. Nov 2019, at 22:41, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>>>
>>>> Mirja,
>>>>
>>>>
>>>> On 26/11/2019 01:02, Mirja Kuehlewind wrote:
>>>>> Hi Jonathan,
>>>>>
>>>>> [MK] 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.
>> [BB] Please be clear exactly which requirements you are talking about. When I read the above, I just gave up and threw my laptop out of the window.
>>
>> Having bought a new laptop, I'm now wondering... perhaps you didn't mean all of the normative requirements under table 2 when you said 'we should not have these normative requirements', altho from your earlier email I got the distinct impression you did mean that (which is why I wasted a laptop).
>>
>> What did you mean? Given the considerable amount of normative language in this part of the draft, and that it's all been stable for all 16 revisions since draft-kuehlewind-01, I think we deserve to see the actual text you are proposing, and some sound reasoning for why the current normative text suddenly all has to be junked.
>>
>> more...
>>
>>>>> [MK] 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.
>>>> [BB] In the spec of AccECN, it's necessary and reasonable to state normative requirements for a node "that is AccECN-enabled". That doesn't mean that an AccECN implementation has to always support AccECN - it can always disable AccECN. But we do have to say what it is expected to do if it is following the AccECN protocol.
>>>>
>>>> This draft has included that normative language for the negotiation phase in all 16 revisions since the first individual draft (that you wrote!).
>>>>
>>>> The table shows only cases where one end or the other is AccECN-capable, and the text preceding and following the table gives normative requirements solely for the AccECN node(s) in those cases. It doesn't give any normative requirements for non-AccECN nodes.
>>>>
>>>> In block 3, the server is AccECN capable, so in the AccECN spec. it's perfectly reasonable to say what it ought to do in response to various types of SYN. In particular, if it receives a SYN with AE,CWR,ECE=0,0,0 the AccECN-enabled server MUST respond with AE,CWR,ECE=0,0,0.
>>>>
>>>> The only case that is in question, AFAIC, is whether we have to say what an AccECN-capable server does in response to a SYN from an RFC3168 client (AE,CWR,ECE=0,1,1). We need to somehow say an AccECN server can respond with a SYN-ACK that is either RFC3168 or non-ECN.
>>>>
>>>> I just proposed respectively SHOULD and MAY, but I can now see there is no need to make that judgement call. However, it is still important to say an AccECN-enabled server MUST respond with either (0,0,1) or (0,0,0).
>> On 02/12/2019 11:15, Mirja Kuehlewind wrote:
>>> Hi Bob,
>>>
>>> Regarding the [above] sentence:
>>>
>>> This is a normative statement that is defined in RFC3168 and we should not state it here again but refer to RFC3168 instead.
>> [BB] But an AccECN /server/ does not have to support RFC3168. It might be desirable to support 3168 as well as AccECN, but strictly it doesn't have to for interoperability - it can fall-back to non-ECN if it receives a 3168 SYN.
>>
>> That was my reason for starting this thread. If an AccECN server supports 3168, it replies (0,0,1). But it can just not support 3168 at all. Then it replies (0,0,0).
>>
>> However, it cannot do neither. Hence why I said it MUST respond to a 3168 SYN with either (0,0,1) or (0,0,0).
>>
>> This cannot be said by referring to 3168.
>>>> [BB] It's also important that the spec defines all three bits in the SYN-ACK responses, not just the 2-bits defined in RFC3168 - so that the combinations with AE=1 are ruled out and therefore remain available for future use.
>> [BB] This cannot be said by referring to RFC3168 either.
>>
>>
>>
>> Bob
>>>>
>>>>
>>>> Bob
>>>>> 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
>>>> -- 
>>>> ________________________________________________________________
>>>> Bob Briscoe                               http://bobbriscoe.net/
>>>>
>>>>
>> -- 
>> ________________________________________________________________
>> Bob Briscoe                               http://bobbriscoe.net/
>>
>>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/