[Taps] Early TAPS Implementation in Go, Feedback Welcome

Thorben Krüger <thorben.krueger@ovgu.de> Tue, 04 January 2022 14:13 UTC

Return-Path: <thorben.krueger@ovgu.de>
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 6DFD83A1CBF for <taps@ietfa.amsl.com>; Tue, 4 Jan 2022 06:13:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 n2h9cl6e7Gqv for <taps@ietfa.amsl.com>; Tue, 4 Jan 2022 06:13:35 -0800 (PST)
Received: from mail.ovgu.de (mail.ovgu.de [141.44.1.66]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82AF73A1CBE for <taps@ietf.org>; Tue, 4 Jan 2022 06:13:34 -0800 (PST)
Received: from RavenclawTower (port-ip-88-150-57-68.reverse.mdcc-fun.de [88.150.57.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by mail.ovgu.de (Postfix) with ESMTPSA id 8CA9DA019D for <taps@ietf.org>; Tue, 4 Jan 2022 15:13:28 +0100 (CET)
User-agent: mu4e 1.7.0; emacs 27.2
From: Thorben Krüger <thorben.krueger@ovgu.de>
To: taps@ietf.org
Date: Tue, 04 Jan 2022 14:57:06 +0100
Message-ID: <87czl7k2rd.fsf@ovgu.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/eBIk6l8IWf1W-VIOFeFNxDoOdUA>
Subject: [Taps] Early TAPS Implementation in Go, Feedback Welcome
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: Tue, 04 Jan 2022 14:17:43 -0000

Dear TAPS,

In the context of a recently started EU NGI Pointer project[1], we 
are currently involved in engineering[2] an open source transport 
services system in Go, with support for SCION[4], a 
next-generation path-aware Internet architecture, enabling 
multi-path communication at the inter-domain level.

Our system, called PANAPI[3] (Path-Aware Networking API), aims to 
hide complex automated processes (such as protocol racing) behind 
convenient high-level abstractions. In the backend, PANAPI 
consists of a (Lua) scriptable framework to support practical path 
selection in the context of the SCION architecture. (We also aim 
to provide UDP, TCP/IP and QUIC support, but achieving full 
RFC8923[5] compliance is only a secondary goal.)

To avoid re-inventing the wheel on the frontend-side, we have 
chosen to adopt the abstractions laid out in the current TAPS 
Interface draft[6]. Most of these could be easily mapped to our Go 
implementation, but in a few cases we decided to depart from the 
specification. We are unsure to what degree our decisions[7] are 
in violation of the TAPS vision and would appreciate feedback, 
especially from folks who have some familiarity with Go.

Note that this email is not intended to announce a fait 
accompli. PANAPI is still under development and only partially 
usable in its current state. The user-facing API[8] is about two 
thirds done, and we would be glad to incorporate your feedback on 
our implementation choices[7]. While Candidate Gathering and 
Candidate Racing are still waiting to be implemented, the main 
SCION-based, scriptable path-selection framework for the backend 
is nearly complete. We would highly appreciate any kind of 
contributions, even only informal feedback, also from non-Go 
programmers.

Finally, we believe we have identified a few minor mistakes in the 
Interface draft[6]. What is the proper process of discussing 
these?

Kind regards and happy new year,

Thorben Krüger
Otto-von-Guericke University, Magdeburg

[1]: https://www.ngi.eu/funded_solution/ngi-pointer-project-33/
[2]: https://github.com/netsys-lab/panapi/tree/taps
[3]: https://dl.acm.org/doi/10.1145/3472727.3472808
[4]: https://scion-architecture.net/
[5]: https://www.rfc-editor.org/rfc/rfc8923.html
[6]: 
https://www.ietf.org/archive/id/draft-ietf-taps-interface-13.html
[7]: 
https://github.com/netsys-lab/panapi/blob/taps/doc/Implementation.md
[8]: 
https://pkg.go.dev/github.com/netsys-lab/panapi@v0.3.0-alpha7/taps

PS: PANAPI receives official funding from NGI Pointer[1]