Implementing Interfaces to Transport Services
draft-ietf-taps-impl-18

Yes

Zaheduzzaman Sarker
(Martin Duke)

No Objection

Erik Kline
Francesca Palombini
Jim Guichard
John Scudder
Murray Kucherawy
Roman Danyliw
Éric Vyncke
(Andrew Alston)
(Robert Wilton)

Note: This ballot was opened for revision 16 and is now closed.

Zaheduzzaman Sarker
Yes
Erik Kline
No Objection
Comment (2023-09-06 for -16) Sent 
# Internet AD comments for draft-ietf-taps-impl-16
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Nits

### <many>

* s/2001:DB8::/2001:db8::/g

  RFC 5952 section 4.3.
Francesca Palombini
No Objection
Comment (2023-09-07 for -16) Not sent 
Thank you for the work on this document.

Many thanks to Bron Gondwana for his ART ART early review: https://mailarchive.ietf.org/arch/msg/art/BCssDo0BzxJbmsBrn9pPcG8RLPg/ and to the authors for addressing Bron's comments.
Jim Guichard
No Objection
John Scudder
No Objection
Murray Kucherawy
No Objection
Comment (2023-09-06 for -16) Not sent 
Thanks to Bron Gondwana for the ARTART review.
Roman Danyliw
No Objection
Éric Vyncke
No Objection
Comment (2023-09-07 for -16) Sent 
Due to $dayjob work, I had no time to make a detailed review of yet another *neat* document.

Please address Benson Muite's comments in his int-dir review: https://datatracker.ietf.org/doc/review-ietf-taps-impl-16-intdir-telechat-muite-2023-09-05/

Thanks for having address Peter van Dijk's comments in his dns-dir review: https://datatracker.ietf.org/doc/review-ietf-taps-impl-16-dnsdir-telechat-van-dijk-2023-09-04/

In section 4, suggest to follow RFC 5952 to represent IPv6 address and use the usual 'browser' syntax for ports for IPv6: [2001:db8::1]:80. And in the same shot, why using 80 rather than 443 ? :-)

In section 4.1.1.1, while I like using real-world examples, the usual way in IETF drafts is to use example.net or similar.

I can only regret that most of the examples are using IPv4 over LTE while most mobile providers are IPv6-only nowadays...

-éric
Martin Duke Former IESG member
Yes
Yes (2023-09-06 for -16) Sent 
One nit: (S10.3) consistently appends (-Lite) to every reference to UDP, and then (S10.4) is explicitly about UDP-Lite. An equivalent editorial decision would to make every reference to TCP instead read "(MP)TCP."

I would recommend that you simply delete all instances of "(-Lite)".
Andrew Alston Former IESG member
No Objection
No Objection (for -16) Not sent 

                            

                        
                    

                
            
                
                    

                        

                            Robert Wilton Former IESG member
                        

                        

                            
                            No Objection
                            
                        

                    

                    

                        

                            

                                No Objection 
                                
                                    (2023-09-07 for -16)
                                
                                
                                    
                                         Sent
                                    
                                
                            

                        

                        
                            

                                
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?