Subject: [Taps] Early TAPS Implementation in Go, Feedback Welcome

From: Thorben Krüger <[email-masked]>
Date: Tue, 04 Jan 2022 14:57:06 +0100

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/[email-masked]/taps

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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 5 Jan 2022 14:02:50 +0000

Hi Troben,

thanks for sharing and using the taps API. For the mistakes you found I recommend to open issues on github or even create a PR if the resolution is straight-forward: https://github.com/ietf-tapswg

Mirja

On 04.01.22, 15:18, "Taps on behalf of Thorben Krüger" <[email-masked] on behalf of [email-masked]> wrote:

    Dear TAPS,

    Thorben Krüger

    [1]: https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-dfd3bd71b085b967&q=1&e=f73004e3-6a0b-487f-b306-baac8445e614&u=https%3A%2F%2Fwww.ngi.eu%2Ffunded_solution%2Fngi-pointer-project-33%2F
    [2]: https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a6202abfcbbafaa4&q=1&e=f73004e3-6a0b-487f-b306-baac8445e614&u=https%3A%2F%2Fgithub.com%2Fnetsys-lab%2Fpanapi%2Ftree%2Ftaps
    [3]: https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-e2435aed8f4e8766&q=1&e=f73004e3-6a0b-487f-b306-baac8445e614&u=https%3A%2F%2Fdl.acm.org%2Fdoi%2F10.1145%2F3472727.3472808
    [4]: https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-9249a3ce4b132d30&q=1&e=f73004e3-6a0b-487f-b306-baac8445e614&u=https%3A%2F%2Fscion-architecture.net%2F
    [5]: https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-20505ec0daf0d7ae&q=1&e=f73004e3-6a0b-487f-b306-baac8445e614&u=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc8923.html
    [6]: 
    https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-76cbc5967efb114d&q=1&e=f73004e3-6a0b-487f-b306-baac8445e614&u=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-taps-interface-13.html
    [7]: 
    https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-367b4fc5664866f3&q=1&e=f73004e3-6a0b-487f-b306-baac8445e614&u=https%3A%2F%2Fgithub.com%2Fnetsys-lab%2Fpanapi%2Fblob%2Ftaps%2Fdoc%2FImplementation.md
    [8]: 
    https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-9fd94feaea2ba82d&q=1&e=f73004e3-6a0b-487f-b306-baac8445e614&u=https%3A%2F%2Fpkg.go.dev%2Fgithub.com%2Fnetsys-lab%2Fpanapi%40v0.3.0-alpha7%2Ftaps

    _______________________________________________
    Taps mailing list
    [email-masked]
    https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-a4d4eb0115e9372f&q=1&e=f73004e3-6a0b-487f-b306-baac8445e614&u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftaps

---

From: Thorben Krüger <[email-masked]>
Date: Thu, 06 Jan 2022 16:26:11 +0100

Hi Mirja,

thank you for the quick feedback. I have just created a ticket 
with my most important point of puzzlement: 
https://github.com/ietf-tapswg/api-drafts/issues/1001

Thorben

Mirja Kuehlewind <mirja.kuehlewind=[email-masked]> 
writes:

> Hi Troben,
>
> thanks for sharing and using the taps API. For the mistakes you 
> found
> I recommend to open issues on github or even create a PR if the
> resolution is straight-forward: https://github.com/ietf-tapswg
>
> Mirja

---

From: Theresa Enghardt <[email-masked]>
Date: Fri, 7 Jan 2022 19:01:36 -0800

Hi Thorben,

Thank you for sharing your TAPS implementation, your feedback, and your 
questions with us!

Please do feel free to open more issues on our Github regarding our 
drafts, especially if you have feedback on draft-ietf-taps-impl based on 
your implementation experience.

With my chair hat on, I'm wondering if you'd be interesting in joining 
our next virtual interim meeting, planned for Wednesday January 26th at 
16:00 UTC, and briefly present your implementation and most important 
questions/challenges?

With my co-author hat on for the rest of this email, I found your "Notes 
on Implementation" [0] an interesting read, and I have some initial 
thoughts:

On the first section, "Asynchronous, Event-driven Interaction 
Patterns": The TAPS documents strive to be independent of any 
language-specific considerations and I don't think that our use of 
"Event" as a basic term in the Interface draft implies the use of an 
actual Event system when mapping the abstract API into a concrete 
programming language.
Appendix A. Implementation Mapping in the Interface document [1], says 
"Actions could be implemented as functions or method calls, for 
instance, and Events could be implemented via event queues, handler 
functions or classes, communicating sequential processes, or other 
asynchronous calling conventions" - I am wondering if this means that 
Events can also be implemented using a construct such as the one 
described in your notes.
Perhaps it does, but I'm wondering if more needs to be said in the document.

To the "Property/Parameter Access and Type Safety" section, I am 
wondering if this is covered by Section 5 in the Interface document, 
e.g., the last bullet point: "Implementations may use other 
representations for Transport Property Names, e.g., by providing 
constants, but should provide a straight-forward mapping between their 
representation and the property names specified here." - Wouldn't this 
cover struct fields, too?

Regarding the last section, "Pre-Establishment", it sounds to me like 
this is an okay way to handle it. In my mind, "should have a list 
available" means there could simply be a piece of documentation listing 
the protocols which can be registered. Does "registering" each protocol 
with the core system mean that there can be different implementations 
for a given protocol, and/or that these can be dynamically added? If so, 
this could be related to the "TAPS Transport Discovery" idea [2] which 
Martin Duke brought to us last year. It is not clear yet whether the WG 
will work on such a discovery mechanism, but I'm still curious if the 
concepts are related.

Of course, the above are just one co-author's thoughts, and I'm happy 
for the others to chime in as well.

Best,
Reese (formerly known as Theresa)

[0] 
https://github.com/netsys-lab/panapi/blob/a982200736ffe81c1f1be750c8df27845442045d/doc/Implementation.md
[1] 
https://www.ietf.org/archive/id/draft-ietf-taps-interface-14.html#name-implementation-mapping
[2] https://datatracker.ietf.org/doc/draft-duke-taps-transport-discovery/

---

From: Michael Welzl <[email-masked]>
Date: Mon, 10 Jan 2022 11:13:16 +0100

Dear all,

I have to apologize: I had been in touch with Thorben before, and already answered him regarding the “Notes on Implementation” directly, in a private, German email.
That was unconstructive!  I should have sent it here and saved Reese some work - it seems that this reflects almost 100% what I already wrote to him. Sorry!   A few more comments below:

> On Jan 8, 2022, at 4:01 AM, Theresa Enghardt <[email-masked]> wrote:
> 
> Hi Thorben,
> 
> Thank you for sharing your TAPS implementation, your feedback, and your questions with us!
> 
> Please do feel free to open more issues on our Github regarding our drafts, especially if you have feedback on draft-ietf-taps-impl based on your implementation experience.
> 
> With my chair hat on, I'm wondering if you'd be interesting in joining our next virtual interim meeting, planned for Wednesday January 26th at 16:00 UTC, and briefly present your implementation and most important questions/challenges?
> 
> With my co-author hat on for the rest of this email, I found your "Notes on Implementation" [0] an interesting read, and I have some initial thoughts:
> 
> On the first section, "Asynchronous, Event-driven Interaction Patterns": The TAPS documents strive to be independent of any language-specific considerations and I don't think that our use of "Event" as a basic term in the Interface draft implies the use of an actual Event system when mapping the abstract API into a concrete programming language.
> Appendix A. Implementation Mapping in the Interface document [1], says "Actions could be implemented as functions or method calls, for instance, and Events could be implemented via event queues, handler functions or classes, communicating sequential processes, or other asynchronous calling conventions" - I am wondering if this means that Events can also be implemented using a construct such as the one described in your notes.

My view is that this doesn’t need more text in the API document, but the fact that Thorben was led to believe that his implementation conflicts with the API makes me a bit uneasy… I think we should try to stress the abstract nature as much as possible and write somewhere (in the implementation draft, IMO) that concrete implementations might look quite different (perhaps even giving some language-specific examples from the implementations that now exist).

> To the "Property/Parameter Access and Type Safety" section, I am wondering if this is covered by Section 5 in the Interface document, e.g., the last bullet point: "Implementations may use other representations for Transport Property Names, e.g., by providing constants, but should provide a straight-forward mapping between their representation and the property names specified here." - Wouldn't this cover struct fields, too?

I would also have thought so - I was surprised by this text, which reads as if we demand that Properties are defined by a string. I wonder if there’s something wrong or misleading in the API draft that led Thorben to believe so?

> Regarding the last section, "Pre-Establishment", it sounds to me like this is an okay way to handle it. In my mind, "should have a list available" means there could simply be a piece of documentation listing the protocols which can be registered. Does "registering" each protocol with the core system mean that there can be different implementations for a given protocol, and/or that these can be dynamically added? If so, this could be related to the "TAPS Transport Discovery" idea [2] which Martin Duke brought to us last year. It is not clear yet whether the WG will work on such a discovery mechanism, but I'm still curious if the concepts are related.

100% agree as well; in fact I also mentioned Martin’s draft in this context in my private response  :-)

> 
> Of course, the above are just one co-author's thoughts,

two now  :-)

Cheers,
Michael

> and I'm happy for the others to chime in as well.
> 
> Best,
> [0] https://github.com/netsys-lab/panapi/blob/a982200736ffe81c1f1be750c8df27845442045d/doc/Implementation.md
> [1] https://www.ietf.org/archive/id/draft-ietf-taps-interface-14.html#name-implementation-mapping
> https://www.ietf.org/mailman/listinfo/taps