Subject: [Taps] Preconnections are not valuable?

From: Martin Duke <[email-masked]>
Date: Wed, 16 Jun 2021 14:58:01 -0700

Michael and I have been having a good github discussion
<https://github.com/ietf-tapswg/api-drafts/issues/859> about preconnections
and it has refined my thinking on this subject.

*Tommy*: do I read correctly that NetworkFramework doesn't have a notion of
preconnections?

*TL;DR* the preconnection concept is currently quite heavyweight and
conceptually messy for not achieving very much. We should either give it
more to do, or get rid of it.

*Current design*: at the last interim, I believe we converged on the
following.

1. Create preconn with endpoints and properties: do not deep copy, just
store a preference
2. The preconn validates that the properties are satisfiable with an
available stack and just stores the rest
3. Create connection from the preconn: build the candidate tree, resolve
names, start racing.
Note that because the properties may have changed, the minimal validation
in #2 has to occur again.
4. The connection deep-copies all the necessary stuff.

In other words, the *only* value add for the preconnection is a check that
has to be repeated anyway at connection time.

*The simplest fix* would be to do a deep copy at preconnection time.
However, this implies two deep copies, which is expensive.

Instead, I think we should do one of two things:
1) Beef up the preconnection: take all the endpoint and property data and
do as much work as possible. Build the candidate tree up to the point of
resolving names (and maybe even do that!). Obviously, this requires a deep
copy at preconnection time, but I believe these data structures would no
longer be necessary in the connection itself, so there would still be only
one copy.

2) Abolish the preconnection. If all of these arguments aren't being used
until connection time, why not just send them to TAPS at connection time?

What do others think about this?

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 17 Jun 2021 11:02:07 -0700

Hi Martin,

I don’t think this is the right direction. Network.framework is only different in that we have two parts of the preconnection—we split it into NWEndpoint and NWParameters.

Your second option “abolish, and just send them at connection time” is really just what we’re doing today with the preconnection. Really, just think of it as a struct that bundles all of the parameters, rather than having a list of 50 parameters to pass to Initiate.

The only thing it is is a convenient bundle. I don’t think there’s anything actually to do at runtime. The API doc says that the error only gets thrown when you try to initiate with a bad preconnection.

Thanks,
Tommy

> On Jun 16, 2021, at 2:58 PM, Martin Duke <[email-masked]> wrote:
> 
> Michael and I have been having a good github discussion <https://github.com/ietf-tapswg/api-drafts/issues/859> about preconnections and it has refined my thinking on this subject.
> 
> Tommy: do I read correctly that NetworkFramework doesn't have a notion of preconnections?
> 
> TL;DR the preconnection concept is currently quite heavyweight and conceptually messy for not achieving very much. We should either give it more to do, or get rid of it.
> 
> Current design: at the last interim, I believe we converged on the following.
> 
> 1. Create preconn with endpoints and properties: do not deep copy, just store a preference
> 2. The preconn validates that the properties are satisfiable with an available stack and just stores the rest
> 3. Create connection from the preconn: build the candidate tree, resolve names, start racing.
> Note that because the properties may have changed, the minimal validation in #2 has to occur again.
> In other words, the *only* value add for the preconnection is a check that has to be repeated anyway at connection time.
> 
> The simplest fix would be to do a deep copy at preconnection time. However, this implies two deep copies, which is expensive.
> 
> 1) Beef up the preconnection: take all the endpoint and property data and do as much work as possible. Build the candidate tree up to the point of resolving names (and maybe even do that!). Obviously, this requires a deep copy at preconnection time, but I believe these data structures would no longer be necessary in the connection itself, so there would still be only one copy.
> 
> 2) Abolish the preconnection. If all of these arguments aren't being used until connection time, why not just send them to TAPS at connection time?
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps