Re: [tsvwg] UDP Options API document

[Tom Herbert <[e-mail]>]

On Tue, Sep 14, 2021 at 12:04 PM [e-mail]
<[e-mail]> wrote:
>
> Hi, Mike,
>
> I’m a bit confused by the note below.
>
> UDP is a datagram service. Whether an implementation supports cached parameters on a per socket-pair basis or not is their decision; the abstract API should not need to address this.
>
> I.e., every parameter of UDP is per message and should be available via a ’sendmsg()/recvmesg()’ command (or equivalent). Every parameter can potentially be cached into the OS, with OS defaults, overrides on a OS-wide or per-connection basis, etc. - as desired, but that’s outside the scope of a protocol. That’s for the manual page for that OS.
>
> The UDP service is:
> send a message
> (with options) with the following options:
>
> Or
> receive a message
> (with options) which returns an indicator of the options received
>
> Everything else, including per-OS, per-socket, etc. configurations, etc - including decisions on how to override UDP option defaults - are implementation optimizations and should never be part of an abstract API.
>
> If there’s something beyond that you’re expecting, can you give us a simple example? Or are you thinking more of an OS manual page than a protocol spec?

Basically, yes. An API is not a necessary part of protocol
specification, it is part of implementation. Instead of an abstract
API description, what would really be most helpful is a reference to
an open source implementation demonstrating the APIs as well as the
rest of the functionality described in the specification. Until there
is an actual implementation that can be evaluated by developers that
use and support the APIs, any discussions of APIs are pretty much an
academic exercise IMO.

Tom

>
> Joe
>
> —
> Joe Touch, temporal epistemologist
> www.strayalpha.com
>
> On Sep 14, 2021, at 11:19 AM, C. M. Heard <[e-mail]> wrote:
>
> On Fri, Sep 3, 2021 at 10:35 AM Tom Jones wrote:
>>
>> It was raised today during the interim (I think by Carsten) that a clear
>> API description is very important for real world adoption of a protocol.
>> Michael Tuexen added that during the original SCTP standardisation a
>> separate API draft made writing portable applications much easier.
>>
>> Let me start the discussion, should we provide a separate draft for UDP
>> Options API or should this work happen inside the UDP Options draft?
>
>
> I would like to see thorough and clear documentation in the base specification of the ***services*** that are provided by UDP options.to the application layer (or the higher layer protocol running on top of UDP).
>
>
> On Sat, Sep 4, 2021 at 9:35 AM Joe Touch replied:
>>
>> As I mentioned during the meeting, there’s already an abstract API in the spirit of TCP's in section 8 of the draft, with a real-world example in Appendix A based on a preliminary implementation.
>>
>> It’s been there since draft-touch-tsvwg-udp-options-06, dated March 27, 2017.
>>
>> I don’t recall anyone commenting on that yet, though.
>
>
> I took Tom's advice and read both RFC 8303 ("On the Usage of Transport Features Provided by IETF Transport Protocols") and RFC 8304 ("Transport Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP-Lite)"). RFC 8303 (and RFC 8304) relied on existing, documented application interface requirements and abstract APIs, and that Tom is proposing to do something similar for UDP options, and asks whether we should do that in the base spec or as a separate document. Note that RFC 8303, despite its title, deals substantively only with connection-oriented transport protocols, and simply references RFC 8304 in its sections on connectionless transport protocols.
>
> I also heeded Joe's admonition to read the abstract API in the current draft (I indeed have not paid attention to it or commented on it up to now).
>
> My sense is that the existing abstract API is insufficient to serve as a basis for something like an extended version of RFC 8304. But I also feel that RFC 8304 somewhat misses the mark, since it does not adequately distinguish what primitives should actually be per-datagram (i.e., figuring as input parameters to send(), sendto(), or sendmsg() and output parameters from recv(), recvfrom(), and recvmsg() or the like) versus what things should be per-socket (and controlled by setsockopt() or the like).  I would really like to see a complete laundry list written down, and I will take a stab at it if I am asked.
>
> Thanks,
>
> Mike Heard
>
>