On Wed, Sep 6, 2023 at 9:56 AM Robert Wilton via Datatracker <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
