Subject: [Taps] comments on draft-brunstrom-taps-impl-00

From: "Aaron Falk" <[email-masked]>
Date: Tue, 20 Mar 2018 17:56:53 +0000

Comments on the draft.  HTH.

--aaron

----

General

Should the draft address the issue of applications that want to go 
directly to a specific transport protocol and bypass TAPS?  For example, 
this may affect capacity profiles predictions.

> 4.2.  Branching Order-of-Operations
...
>    usable DNS results on one network may
>    not necessarily be the same as DNS results on another network due 
> to
>    local network entities, supported address families, or enterprise
>    network configurations.

CDN cache assignment is another reason DNS results may vary by network 
interface.

> 4.5.  Completing Establishment
...
>    an implementation may choose to hold
>    onto fully established leaf nodes that were not the first to
>    establish for use in future connections, but this approach is not
>    recommended since those attempts were slower to connect and may
>    exhibit less desirable properties.

Seems like there are other good reasons not to encourage holding 
duplicate connections open such as consuming valuable server resources.

> 6.2.  Handling Path Changes

Is there a realistic case where, say, a routing change causes a protocol 
to stop working.  Should TAPS deal with this?

> 10.  Rendezvous and Environment Discovery
...
>    o  Gathering Remote Endpoint Candidates

As in sec 4, I think it may be worth mentioning that DNS resolutions may 
vary by interface (e.g., with CDNS).  Perhaps there should be a 
recommendation to perform DNS lookups separately for each interface to 
get the remote IP address.