[Edm] Protocol testability

Christopher Wood <caw@heapingbits.net> Wed, 29 March 2023 00:27 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: edm@ietfa.amsl.com
Delivered-To: edm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA036C15152D for <edm@ietfa.amsl.com>; Tue, 28 Mar 2023 17:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b="LvlwuWsF"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="Ww7PtsSc"
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWdqzadfbCyW for <edm@ietfa.amsl.com>; Tue, 28 Mar 2023 17:27:49 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 838A7C14CE55 for <edm@iab.org>; Tue, 28 Mar 2023 17:27:49 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8802C5C00CF for <edm@iab.org>; Tue, 28 Mar 2023 20:27:48 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 28 Mar 2023 20:27:48 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :sender:subject:subject:to:to; s=fm2; t=1680049668; x= 1680136068; bh=fyyE+KUeLVRQAa+jyHQR7bUHlcugrAD/psQQJO/aGSE=; b=L vlwuWsFHgW6KR9CnYLie/2neBCjpkE0d/DsnQc43gmBsqAlj0ABwY+vLInB1N3uO lMb/N4lnx2O9mZCE+D+Ec+7p1sxmtK9KmHzBzCYEDIO06zJ4rC5BGKXIq79JZFlF QEUmJa1i/0rkx3T4M6CuU9/1AaO79OQkmbajnKnufYpzYb6LL1vdNkKlnbTDLHSC kfgnBnzQ9ns3ssfSMzHnL8NMhUQohT9+hvArcIJci+6yZR4CxnlAZ6AxnkugI7tw 0Ut9D5qdpFzdylj8cKLdu1C6U30Q0bp0ZgsPtyC/jvSiOQwbXUIBLUcXRS//7w/2 eMoLJcgd//4/e7gnemGvg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1680049668; x=1680136068; bh=fyyE+KUeLVRQA a+jyHQR7bUHlcugrAD/psQQJO/aGSE=; b=Ww7PtsScIDD5QCD79DLLKDioouYvQ P+a28of7mx12dNUP1QyQQBlF+u6cFmBm2ypCM+m8GwpZC6CSZCkXLXg9/EzLunVZ gLinMLeE6vJFRPAaXGCPxP38ZaCf9BQdMmHrT5nD76JyWrQuSSAcwwr0ILTxUiMq pQP0snkXFReaGVOBR4XCLdApzW3CpUna77VA3AVoqHcld8jAi5UvnTEPwscpSMuv YxSQ9nmqKFVvsZ+PGL7EMnitCx7nergztKueTlGSLQ/GFz8ZsZ67t2lVCjxAqjyS SKfxuQrRVnKixswLMSWo4KBgUYCY/ZRkRY+n5dF5JwY05y6Y2dneB1dqg==
X-ME-Sender: <xms:BIYjZNNjzvy6xikY66byqOquW6FaQpzoJ_Ssoqk0MER-0oM_-W5xvg> <xme:BIYjZP8uClpHJupLdm46vNe_PqwYh6fGb_r44U0ugteBbcmFfD79T5jH-7GQ69Yso CMYOuznJ7p4_4xPBG8>
X-ME-Received: <xmr:BIYjZMR0A-kgXG40U3Sv9bhk4qzaoQ-EMELtq6NcmZNfI_KwxMTR95W1qyMyCwlqr4C8njm_R5BJcNml7Ab5WjqfeCZrYw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdehhedgfeehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfukfffvffosehtqhhmtd hhtddvnecuhfhrohhmpeevhhhrihhsthhophhhvghrucghohhougcuoegtrgifsehhvggr phhinhhgsghithhsrdhnvghtqeenucggtffrrghtthgvrhhnpeejiefhleegudeiudfgve ekkeeuleekfeelvdehvedvheelkeeghffhkeduffeuhfenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrd hnvght
X-ME-Proxy: <xmx:BIYjZJs79DJH-CCnRBFhCzfz1HAPQYVNpD2CyYB2CbttXJu0wHtKmA> <xmx:BIYjZFdnsrjyp91_9x7Lhx7IjDqOAzc1Xxfp6QU_U3ak0zSUFS6VVg> <xmx:BIYjZF3G6COOhWkkH-8fq04Ma2GBfdGansxxS-nriOVcXCVR2rUD8w> <xmx:BIYjZLqiH4r0SHeVcng7P9e_lhIhGdMt4TtiowYgE2B8xiY7KfOX2w>
Feedback-ID: i2f494406:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for <edm@iab.org>; Tue, 28 Mar 2023 20:27:47 -0400 (EDT)
From: Christopher Wood <caw@heapingbits.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
Message-Id: <C10E5882-5FF8-45DF-8463-DC15C64BA2D9@heapingbits.net>
Date: Wed, 29 Mar 2023 09:27:44 +0900
To: edm@iab.org
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/edm/EiA8Po7zS3b-UMJKnxNAGscklWQ>
Subject: [Edm] Protocol testability
X-BeenThere: edm@iab.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" <edm.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/edm>, <mailto:edm-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/edm/>
List-Post: <mailto:edm@iab.org>
List-Help: <mailto:edm-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/edm>, <mailto:edm-request@iab.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Mar 2023 00:27:54 -0000

Apologies again to everyone for making you sit through my rambling thoughts earlier in the meeting. Here's my attempt to better articulate what I was trying to say at the mic.

The bug that was mentioned in the meeting seems to have manifested in practice because of a lack of "proper" testing, for some definition of proper. This happens all the time, and for good reason: perhaps the easiest way we validate a protocol specification is by deploying it and seeing if it works in practice. A much harder (and, frankly, equally imperfect) way would be to spend all of our energy on improving tests and our test harnesses. 

So the way I see it, there are basically two extremes for how we validate protocol specifications. One extreme is where we could write exactly zero tests and rely entirely on deployment experiments to determine if a protocol is correct. The other extreme is where we could focus entirely on tests and do no deployment to determine correctness. In practice, we wind up somewhere in the middle.

Where different implementations fall on this spectrum varies a lot in practice and is influenced by a number of things:

- How much time pressure there is to ship software.
- How many different implementations exist for the purposes of perfroming interop tests.
- How many resources there are to dedicate on tests and test harnesses, and how feasible it is to implement tests in different environments.
- How complex the protocol is and, consequently, how difficult it is to produce test vectors to exercise different parts of the protocol.

There may certainly be more. I don't think there's a "right" answer as to where anyone should fall on this spectrum of testability, but I wonder if it would be useful for us to retroactively look back at collaborative efforts of different protocols to see if there are any trends worth documenting. QUIC is an obvious candidate here. I mentioned Oblivious HTTP in the meeting. Maybe there are others?

Time provided, I'm willing to help look back at time and collate this information, though I'm curious to hear what folks think about this topic in general.

Best,
Chris