[tcpm] Follow-up from AccECN discussion today: Robustness Principle
Bob Briscoe <ietf@bobbriscoe.net> Wed, 23 March 2022 18:33 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 DA4063A18F6 for <tcpm@ietfa.amsl.com>; Wed, 23 Mar 2022 11:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 9aH8Nmy-R1eB for <tcpm@ietfa.amsl.com>; Wed, 23 Mar 2022 11:33:04 -0700 (PDT)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (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 AE71F3A11AA for <tcpm@ietf.org>; Wed, 23 Mar 2022 11:33:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Subject:From:Cc:To:MIME-Version:Date: Message-ID:Content-Type:Sender:Reply-To:Content-Transfer-Encoding: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=F1FFhfurdxKbV7r+/lZWA8s6tlQei0H85dgf3SC/G90=; b=YbwUwUnDwK7c09znIoTocLShvn uz0CAwzkW4goRICrlqcGeYBCEMSfCm5sKJnxB3j9R8cdmnrUEcnphMBKq0k7isCq3jWGbtXD6Fwcg fsp9YL6pdMsVZvaKM48sYu4FZ4+Ow0ITGcZUA851FLK1OD19E1Swo3QwuCdWosYmd/yfE3kvHaRZh 2E4/Mi4Q8IY++9T2Y8Rj7VOdN+dhaS/FWcoygyJ+fHwK1P938E2b1EM82O4HNlD+98OL9Mg29F0dH IZueoTt1jxqfQgo+L68ERcU9HL7dwWetYYbznyhSDec7dYUlIGTZLJVbjwnr9qRjUpNeMBHYEsZKs mauNm2Lw==;
Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:54596 helo=[192.168.1.4]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <ietf@bobbriscoe.net>) id 1nX5nA-0006KQ-0m; Wed, 23 Mar 2022 18:33:02 +0000
Content-Type: multipart/alternative; boundary="------------heR1TO0H0gdKt0z4j7QuhtVK"
Message-ID: <13266aed-07bd-1d05-5dd1-26f15834c1cf@bobbriscoe.net>
Date: Wed, 23 Mar 2022 18:33:00 +0000
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
Content-Language: en-GB
To: Jonathan Morton <chromatix99@gmail.com>
Cc: tcpm IETF list <tcpm@ietf.org>
From: Bob Briscoe <ietf@bobbriscoe.net>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
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: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/_t3PqiHnha4bqS3ZcDmt5sUd23g>
Subject: [tcpm] Follow-up from AccECN discussion today: Robustness Principle
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, 23 Mar 2022 18:33:10 -0000
Jonathan, You said slide #9 was contrary to the Robustness Principle. https://datatracker.ietf.org/meeting/113/materials/slides-113-tcpm-draft-ietf-tcpm-accurate-ecn-18-00#page=9 and pasted at the end. (I couldn't find the email you referred to about this, so apologies for starting a new thread). There's a superficial resemblance, but the context is different. The context of the robustness principle is the possibility of differing interpretations. Quoting from its source [RFC791]: While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation must be conservative in its sending behavior, and liberal in its receiving behavior. In contrast, the advice in the AccECN draft is not about any possibility of differing interpretations. Rather, it's a question of which is preferable: * not even sending information, * or ignoring it on receipt. Both are ways of communicating nothing. This is not question of handling ambiguity, given different ways of communicating nothing are all equally unambiguous (!) This is rather a question of incremental deployment strategy. _________ Unfortunately this intervention distracted from the point at hand, so I'll repeat it here: * Given it's simple to implement the side that sends the AccECN TCP option, please do so; * Then whenever anyone implements the side that receives it, they will have instant gratification. Regards Bob /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Switch round preferred partial implementation of AccECN Option? * Current: Even if a developer does not implement sending of the AccECN Option, it is RECOMMENDED that they still implement logic to receive and understand any AccECN Options sent by remote peers. * Proposed: Even if a developer does not implement logic to understand received AccECN Options, it is RECOMMENDED that they still implement logic to send AccECN Options to provide richer feedback to those remote peers that do understand it. * Reasons: 1) Originally believed that Data Receiver (which sends AccECN Options) would be the more complex side, but it's the simpler 2) TCP Option needed more in upstream where ACK filtering is greatest 3) Servers more likely to be Linux where TCP option already fully implemented; client OS's still to be implemented /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ -- ________________________________________________________________ Bob Briscoehttp://bobbriscoe.net/