Tom H: WGLC comments on Appendix A:

[gorryfair]

This section would be more relevant if it had reference to source code (I believe there's some FreeBSD implementation). Basic design and supported options would also be more useful than a list of sysctls.

Regarding the design of implementation, there's two basic approaches to processing options in transport layer protocols:

1) Process the options completely in the kernel stack (like how TCP is implemented) 2) Process the options completely in the application (like how QUIC is implemented)

UDP options seems to specify a hybrid approach, where the options would be processed in the kernel and the results are somehow passed to the application (presumably, setting the results in ancillary data of recvmsg). Honestly, I think this hybrid approach is going to be a hard sell to upstream UDP options in LInux. I suggest that the second approach should be used for UDP options.

In this model, we would add a UDP socket option indicating that the UDP payload and any surplus area are set to the application as part of the data in a recvmsg. Ancillary data in the receive message could contain the length of the UDP payload and we could probably provide the checksum over the surplus area as well for OCS computation. Once the payload+surplus area is in userspace then the application can process UDP options as needed (presumably using a common library for that).

This approach greatly simplifies the kernel implementation (probably <50 LOC) since all we need to do is figure out how to post the surplus area data on the socket. Moving the bulk of protocol processing to userspace is a huge simplification and allows much faster time to implement and deploy features (this is one of the major advantages of QUIC over TCP). Once we have that, userspace implementation can be freely modified and extended.

The justification for UDP options as a Proposed Standard would be much stronger if there was some deployment experience that could be described.

(Added by GF during WGLC)

[gorryfair]

If anyone wishes to dig into what we did, this was one of the things that was mentioned: https://datatracker.ietf.org/meeting/interim-2021-tsvwg-02/materials/slides-interim-2021-tsvwg-02-sessa-42-udp-options-status-update-00.pdf

[Mike-Heard]

UDP options seems to specify a hybrid approach, where the options would be processed in the kernel and the results are somehow passed to the application (presumably, setting the results in ancillary data of recvmsg). Honestly, I think this hybrid approach is going to be a hard sell to upstream UDP options in LInux. I suggest that the second approach should be used for UDP options.

In this model, we would add a UDP socket option indicating that the UDP payload and any surplus area are set to the application as part of the data in a recvmsg. Ancillary data in the receive message could contain the length of the UDP payload and we could probably provide the checksum over the surplus area as well for OCS computation. Once the payload+surplus area is in userspace then the application can process UDP options as needed (presumably using a common library for that).

This approach greatly simplifies the kernel implementation (probably <50 LOC) since all we need to do is figure out how to post the surplus area data on the socket. Moving the bulk of protocol processing to userspace is a huge simplification and allows much faster time to implement and deploy features (this is one of the major advantages of QUIC over TCP). Once we have that, userspace implementation can be freely modified and extended.

As long as this approach would play well with checksum offload, it may indeed be advantageous.

That being said, there is nothing in the UDP Options specification that would preclude this; the abstract API in the spec is agnostic as to whether the application makes calls to operating system functions or to a library. So I don't think this discussion is really germane to what should be in the spec.

[gorryfair]

I'd agree that the place that UDP Options is implemented is not the topic of the current work, that can if needed be specified in a later document. I see the naming proposed in the appendix could help interoperability by avoiding different names in different OS, if this approach was used. One way to clarify could be to modify the description, e.g.: / The following information is provided to encourage interoperable API implementations. / The following information is provided to encourage consistent naming for API implementations. /