Robert Wilton has entered the following ballot position for draft-ietf-taps-impl-16: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-taps-impl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document and this work. Sorry, I have not had time to review this in detail, but did have a couple of minor comments/questions: Minor level comments: (1) p 2, sec 10. Specific Transport Protocol Considerations . . . . . . . . . 37 10.1. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.2. MPTCP . . . . . . . . . . . . . . . . . . . . . . . . . 40 10.3. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 40 10.4. UDP-Lite . . . . . . . . . . . . . . . . . . . . . . . . 42 10.5. UDP Multicast Receive . . . . . . . . . . . . . . . . . 42 10.6. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . 44 I was surprised not to see QUIC included in this list of specific transport considerations. Are there no specific considerations for QUIC, or is it out of scope? (2) p 25, sec 5.1.3. Batching Sends Since sending a Message may involve a context switch between the application and the Transport Services system, sending patterns that involve multiple small Messages can incur high overhead if each needs to be enqueued separately. To avoid this, the application can indicate a batch of Send actions through the API. When this is used, the implementation can defer the processing of Messages until the batch is complete. Since the API is asynchronous I would have thought that would have avoided the high overheads associated with synchronous blocking IPC, since calling the send() action shouldn't cause the sender to yield their time slice. Or is the concern here a context switch between kernel space and user space? Or a shared lock? Are there implementations of this new API with associated performance data and benchmarks against the legacy sockets API? _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
