Re: [Taps] Robert Wilton's Yes on draft-ietf-taps-interface-22: (with COMMENT)

["Devon H. O'Dell" <[e-mail]>]

On Wed, Sep 6, 2023 at 9:56 AM Robert Wilton via Datatracker
<[e-mail]> wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Hi,
>
> Moderate level comments:
>
> (1) As per the architecture doc, I think that it is great that you are defining
> a new transport API.  I note that this API doesn't really include any standard
> APIs or structures to monitor the state of the transport sessions for a given
> application (i.e., API user).  E.g., how many connections are currently open,
> total number of connections (since library was initialized), number of errored
> transport connections, drops, mtu issues, flow rates, etc.  I think that with
> some of the changes to the Internet architecture (e.g., QUIC to cite one
> obvious example), it reduces the ability for network operators to monitor and
> debug network issues between applications.  A potential corollary of this is
> that a lot more debug and diagnostics information will need to be made
> available to applications in a common way to allow application support staff,
> and users of those applications to better understand where in the network
> issues and failures are happening.  It would seem unreasonable for me to hold a
> discuss on this document for what might be a lot of work and discussion that
> could take a long time to resolve but I hope that the authors and WG will
> consider whether there is further useful future work required in additional
> RFCs.

Thanks for bringing this up. It's indeed a huge subject and I agree
that it's a topic for additional publications. I had intended to
discuss this in the interim in May, but I was unfortunately unable to
attend last-minute. I see the observability space as related to
configuration / discoverability / policy topics.

It appears in the minutes of that meeting[1] that Zahed still prefers
to close the WG. I'm still very much interested in exploring this
space. What's the best path forward on this topic?

Kind regards,

--dho

[1]: https://datatracker.ietf.org/doc/minutes-interim-2023-taps-01-202305151500/

> Minor level comments:
>
> (2) p 6, sec 1.1.  Terminology and Notation
>
>    *  Array: Denoted []Type, an instance takes a value for each of zero
>       or more elements in a sequence of the given Type.  An array may be
>       of fixed or variable length.
>    *  Collection: An unordered grouping of one or more values of the
>       same type.
>
> Perhaps calling it a Set may be better than Collection (if duplicates are not
> allowed) or a Bag (if duplicates are allowed).
>
> (3) p 17, sec 6.1.  Specifying Endpoints
>
>    Note that an IPv6 address specified with a scope (e.g.
>    2001:db8:4920:e29d:a420:7461:7073:0a%en0) is equivalent to
>    WithIPAddress with an unscoped address and WithInterface together.
>
> Would it not just be cleaner to not allow interface scoped IP addresses, and
> force the clients to use WithInterface, in the case they want to target a
> specific interface?
>
> (4) p 26, sec 6.2.  Specifying Transport Properties
>
>      Upon reading, the Preference type
>    of a Selection Property changes into Boolean, where true means that
>    the selected Protocol Stack supports the feature or uses the path
>    associated with the Selection Property, and false means that the
>    Protocol Stack does not support the feature or use the path.
>
> I misunderstood this on first reading - maybe explicitly state that the types
> for non Preference types are unchanged on a get, maybe give an example of the
> return type for section 6.2.11.
>
> (5) p 64, sec 9.2.  Sending Data
>
>    The optional endOfMessage parameter supports partial sending and is
>    described in Section 9.2.3.
>
> If this is an asynchronous API, I presume that the caller must prevent any
> changes to, or freeing of, the messageData object until it has received a event
> to indicate that the send has successfully completed.  Perhaps this is too
> detailed for this abstract level API and is left to the implementation.
>
> (6) p 70, sec 9.3.2.  Receive Events
>
>    Each call to Receive will be paired with a single Receive event,
>    which can be a success or an error.  This allows an application to
>    provide backpressure to the transport stack when it is temporarily
>    not ready to receive Messages.
>
> The backpressure aspect wasn't entirely clear to me.  So, if an application can
> handle receiving multiple receive events at the same time, it can make multiple
> calls to receive without waiting for, or processing, any receive events?  Is
> that how the application controls the backpressure?
>
> (7) p 70, sec 9.3.2.  Receive Events
>
>    Each call to Receive will be paired with a single Receive event,
>    which can be a success or an error.  This allows an application to
>    provide backpressure to the transport stack when it is temporarily
>    not ready to receive Messages.
>
> How does the transport stack know that the application has finished with the
> memory holding the message in the receive event, or is the expectation that the
> receive message contents is logically always allocated on the heap and it is
> responsibility of the receiver to free the memory once it is done with it?
>
> Regards,
> Rob
>
>
>
> _______________________________________________
> Taps mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/taps