[Taps] Robert Wilton's No Objection on draft-ietf-taps-impl-16: (with COMMENT)

Robert Wilton via Datatracker <noreply@ietf.org> Thu, 07 September 2023 13:15 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-taps-impl@ietf.org, taps-chairs@ietf.org, taps@ietf.org, ietf@trammell.ch, ietf@trammell.ch
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <169409255027.13051.18165409192603081836@ietfa.amsl.com>
Date: Thu, 07 Sep 2023 06:15:50 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/taps/XeIkMO1yxxxcjhX_8LVh1YWkZzk>
Subject: [Taps] Robert Wilton's No Objection on draft-ietf-taps-impl-16: (with COMMENT)

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] Robert Wilton's No Objection on draft-ietf… Robert Wilton via Datatracker