[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/