Re: [Taps] Lars Eggert's Discuss on draft-ietf-taps-interface-22: (with DISCUSS and COMMENT)

[Tommy Pauly <[e-mail]>]

Hi Lars,

> On Dec 12, 2023, at 10:42 AM, Lars Eggert <[e-mail]> wrote:
> 
> Hi,
> 
> On Dec 12, 2023, at 19:48, Tommy Pauly <[e-mail]> wrote:
>>>>> ### Section 6.1.3, paragraph 6
>>>>> ```
>>>>>   In order to scope an alias to a specific transport protocol, an
>>>>>   Endpoint can specify a protocol identifier.
>>>>> 
>>>>>   AlternateRemoteSpecifier.WithProtocol(QUIC)
>>>>> ```
>>>>> This is the first and only time protocol identifiers are used. What
>>>>> are they defined to be?
>>>>> 
>>>>> 
>>>>> ### Section 6.1.3, paragraph 9
>>>>> ```
>>>>>   The following example shows a case where example.com has a server
>>>>>   running on port 443, with an alternate port of 8443 for QUIC.
>>>>> 
>>>>>   RemoteSpecifier := NewRemoteEndpoint()
>>>>>   RemoteSpecifier.WithHostname("example.com")
>>>>>   RemoteSpecifier.WithPort(443)
>>>>> 
>>>>>   QUICRemoteSpecifier := NewRemoteEndpoint()
>>>>>   QUICRemoteSpecifier.WithHostname("example.com")
>>>>>   QUICRemoteSpecifier.WithPort(8443)
>>>>>   QUICRemoteSpecifier.WithProtocol(QUIC)
>>>>> 
>>>>>   RemoteSpecifier.AddAlias(QUICRemoteSpecifier)
>>>>> ```
>>>>> Why does the `RemoteSpecifier` definition not contain a `WithProtocol`
>>>>> clause for TCP/TLS? And what would that look like, given that TCP/TLS
>>>>> is a protocol combination?
>>>> 
>>>> These comments around protocol-specific endpoints are addressed with https://github.com/ietf-tapswg/api-drafts/pull/1408 and https://github.com/ietf-tapswg/api-drafts/pull/1451
>>>> 
>>>> The text now clarifies that the values for the protocol scoping here are implementation-provided enumerations.
>>>> 
>>>> "To scope an Endpoint to apply conditionally to a specific transport
>>>> protocol (such as defining an alternate port to use when QUIC
>>>> is selected, as opposed to TCP), an Endpoint can be
>>>> associated with a protocol identifier. Protocol identifiers are
>>>> objects or enumeration values provided by the Transport
>>>> Services API, which will vary based on which protocols are
>>>> implemented in a particular system."
>>>> 
>>>> The reason to show one protocol being specified with an override is to show how there’s a default endpoint that the connection should use, and it should conditionally load an alternate when using a particular protocol. This then doesn’t constrain the protocol stacks being used, but only customizes the endpoint in case a particular protocol is loaded.
>>> 
>>> How would a developer know what the default endpoint was?
>> 
>> The “default” endpoint is the one that the application developer themselves provided that didn’t include a protocol-specific binding. In the example above, that’s the port 443 endpoint, while there’s a protocol-bound endpoint that uses port 8443.
> 
> OK, but where in the example does it set that the default it TCP/TLS? The only thing specified for the "default" is port 443 - is something inferring TCP/TLS based on the port?

The default isn’t explicitly set to TCP/TLS there—it’s the endpoint address/host/port details that are set as default. So it’s saying “use this default endpoint for any protocol that’s used, except if quic is chosen because I know it uses a different port”. Theoretically if the stack could choose TLS/TCP, QUIC, and something else like SCTP, that default would apply to everything other than QUIC.

> 
>>> I'd argue that "safer" is in the eye of the beholder. I'll certainly agree that TAPS is trying to provide a more principled and more abstract interface to transport functions (also also that the socket API's platform-dependendness is terrible), but at least a developer with sufficient motivation can concretely implement their desired behavior. I remain unconvinced that an abstraction like TAPS will lead to a stable developer experience esp. over time and across platforms.
>> 
>> It’s certainly fair to have a different opinion on how the usefulness and stableness of various transport/socket options will play out over time.
>> 
>> Personally, I think the best philosophy for setting options on a connection / socket should be to set the minimum set required, so as to not unnecessarily constrain the behavior of the stack. If an application sets many options that can eventually only be satisfied by a set of existing protocols, and not some future as-yet-undesigned protocols, then indeed the connections will be constrained to use the existing protocols that work. But apps that only set the options they strictly need will allow for more variation.
>> 
>> Are there specific changes you are thinking of for the document?
> 
> I don't, and that was a comment (i.e., not part of the discuss), so I don't expect changes.

Understood, thanks.

Tommy
> 
> Thanks,
> Lars
>