IETF Logo Mail Archive

[tcpm] A possible simplification for AccECN servers

Bob Briscoe <ietf@bobbriscoe.net> Sat, 23 November 2019 11:27 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 BEA5E1207FD for <tcpm@ietfa.amsl.com>; Sat, 23 Nov 2019 03:27:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 OOAnyyJH77Yi for <tcpm@ietfa.amsl.com>; Sat, 23 Nov 2019 03:27:52 -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 3040C12008A for <tcpm@ietf.org>; Sat, 23 Nov 2019 03:27:52 -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: MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=/8l0hp0cPoVwltyhrS4S4+0qdL7zHhA4o1o1O5/7dlM=; b=Ep0ZrGhAgAHEtLv9Qj5MHcZXwt bj71TXQ+xT5hWo1qlm5TqePtGR2j4PC6KnMTkmr4ikom2N+8bJyY6rlO1cqzUQBz94cG7Xir0osXX 7IMCCz9PTD6u6N5NIuGIu8hMVp6bRoaut3u6HL1CffUA6PgRVbJUUoUWAz0tbv1ZPCO5mnMlLyIKp 9xu5O+kcFLwpx004rNrLWqMVZzxzZA6TgzffBL5U4i4tcCmuGCuQUbmx0zieAKoc6rn2EZTDm2m5q 3iLoVV96RWv9Wyv3NERJdeirYu+5iU2sX5pfNXXzqXL9SUlVHfR1Z6p6jupG2C9SstMfKAwal/YCJ ZJZiuroQ==;
Received: from [31.185.128.31] (port=39314 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 1iYTZt-00088D-Ks; Sat, 23 Nov 2019 11:27:50 +0000
To: tcpm IETF list <tcpm@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, Richard Scheffenegger <rscheff@gmx.at>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <d35618ee-c0dc-44ee-9e22-50bdabbe026c@bobbriscoe.net>
Date: Sat, 23 Nov 2019 19:27:48 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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/m-18iVutIWm9IbZCBAabdQbIcNE>
Subject: [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: Sat, 23 Nov 2019 11:27:55 -0000

tcpm-ers, Mirja, Richard,

draft-ietf-tcpm-accurate-ecn-09 currently says that an AccECN-enabled 
server MUST support both classic ECN and non ECN. However, that's not 
actually necessary for interoperability. Certainly, when an AccECN 
server receives a non-ECN-setup SYN, it MUST fall back to a 
non-ECN-setup SYN-ACK. But, if it receives an ECN-setup SYN, does anyone 
object if we change it from MUST to SHOULD respond with an ECN-setup 
SYN-ACK? And it MAY respond with a non-ECN-setup SYN-ACK?

Potential reasons for a server only supporting AccECN and non-ECN (which 
we can put in the draft):
* lightweight server to minimize code complexity;
* to allow for the possibility that AccECN clients might one day have 
widely replaced classic ECN, and some servers might choose to remove 
their classic ECN code to save having to maintain it.



FYI, the other way round, no such simplification of the client is 
possible. 'Cos there's no space for an AccECN SYN to say "I support 
AccECN but not ECN". So the client has to be able to support all three 
(AccECN, Classic ECN and non-ECN).




Bob



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

v2.23.0 | Report a Bug | By Email