IETF Logo Mail Archive

[Taps] How to handle Protocol stacks that are not equivalent

"Philipp S. Tiesel" <philipp@tiesel.net> Mon, 22 July 2019 21:26 UTC

Return-Path: <philipp@tiesel.net>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346AC1200B6 for <taps@ietfa.amsl.com>; Mon, 22 Jul 2019 14:26:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 s3g_VkWSIoXN for <taps@ietfa.amsl.com>; Mon, 22 Jul 2019 14:26:33 -0700 (PDT)
Received: from einhorn-mail.in-berlin.de (einhorn-mail.in-berlin.de [217.197.80.20]) (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 345A312001B for <taps@ietf.org>; Mon, 22 Jul 2019 14:26:33 -0700 (PDT)
X-Envelope-From: philipp@tiesel.net
X-Envelope-To: <taps@ietf.org>
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de with ESMTPS id x6MLGC1V015441 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <taps@ietf.org>; Mon, 22 Jul 2019 23:16:12 +0200
Received: from [2001:67c:1232:144:61e4:ece:6fb0:5d36] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <philipp@tiesel.net>) id 1hpfdI-0008RE-Lr for taps@ietf.org; Mon, 22 Jul 2019 23:14:08 +0200
From: "Philipp S. Tiesel" <philipp@tiesel.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Message-Id: <3D1D6BE1-6AE2-4098-A2C8-40ADF73A2316@tiesel.net>
Date: Mon, 22 Jul 2019 17:16:05 -0400
To: taps WG <taps@ietf.org>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/Iqon1OmjCaERstWy0YxSwnbbEYs>
Subject: [Taps] How to handle Protocol stacks that are not equivalent
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IETF Transport Services \(TAPS\) Working Group" <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2019 21:26:35 -0000

Hi,

as time did not permit to discuss all open issues in the session today, I’ll take them to the list as proposed.
This issue is based on Github issue #305: https://github.com/ietf-tapswg/api-drafts/issues/305

Following the architecture draft, only protocol stacks that are equivalent can be safely raced. What should happen if selection properties result in a candidate set that includes protocol stacks that are not intuitively equivalent?


Resolution Proposals:

a) Define Protocol Stack Equivalence more rigorously. A possible way to do this would be to say two stacks are equivalent with respect to the applications’ requirements if both fulfil all require properties specified by the applications and do not violate any of the prohibit properties.

b) Generate some kind of Error Event for configurations with unlike protocol stack candidates. (May need a definition of "unlike”).

c) Do nothing and close the issue.


AVE!
   Philipp S. Tiesel

-- 
Philipp S. Tiesel 
https://philipp.tiesel.net/

v2.23.0 | Report a Bug | By Email