Re: [Taps] I-D Action: draft-ietf-taps-minset-00.txt

[Michael Welzl <[e-mail]>]

Hi,

In line:


> On Nov 14, 2017, at 8:20 AM, Tommy Pauly <[e-mail]> wrote:
> 
> A couple initial comments on the minset document:
> 
> In Section 4:
> 
> - Title should be "4.  A MinSet Abstract Interface" not "4.  An MinSet Abstract Interface”

Ack,


> For this:
> 
> 3.  Not offer any of the transport features of these protocols and
>        the LEDBAT congestion control mechanism that do not require
>        application-specific knowledge (to give maximum flexibility to a
>        TAPS system)
> 
> Could this be written as "that can be performed automatically" or something, rather than "do not require application-specific knowledge"? It ends up having a lot of negatives that get confusing.

Agreed,


> I'd like to see the reference removed to Post Sockets indicating that it would require any protocol changes or the system on both ends. As discussed on the other thread, Post does not require any changes to the peer for compatibility.

Absolutely! No problem


> TLS:
> 
> We can discuss in the group, but I think that security can stay a separate document for now. You wouldn't "fall back" to TLS—TLS is just something you can use underneath the TAPS API, and you either have security or you don't. That shouldn't be changing underneath you.

Agreed,


> General:
> 
> Much of the document is phrased in terms of "fall-back" to TCP, UDP, etc. While I understand where this is coming from, I'm wondering from a larger perspective if this is the right framing. As the document reads now, there's this underlying normative assumption that "TCP and UDP are less preferred" and MPTCP or SCTP etc is preferred over them. This may be true for some systems, but maybe not always. The set of transports that a TAPS system may eventually use hopefully won't be just limited to the set in the survey, but include things like QUIC, etc. And depending on the scenario, maybe we prefer something over TCP, and then fall-back to some other less preferred mode. Or, the application may not allow falling back at all, but simply wants to reuse its transport code that uses a TAPS API between different protocols it uses for different, mutually exclusive scenarios.
> 
> So, I would be tempted to change the first two requirements from:
> 
>    1.  Support one-sided deployment with a fall-back to TCP (or UDP)
>    2.  Offer all the transport features of (MP)TCP, UDP(-Lite), LEDBAT
>        and SCTP that require application-specific knowledge
> 
> To:
> 
>    1.  Support basic functionality required for all transports (the 
> 	minimal set for TCP and UDP)
>    2.  Offer all extended transport features that require application-
> 	specific knowledge (such as options for (MP)TCP, UDP(-Lite), LEDBAT
>        and SCTP)
> 
> Then, for each feature listed, you have essentially this format:
> 
>    o  [Feature name]
>       Protocols: SCTP
>       [Description]
>       Fall-back to TCP: [do nothing/not supported]
>       Fall-back to UDP: [do nothing/not supported]
> 
> How about something like:
> 
>    o  [Feature name]
>       Supported by: SCTP
>       Ignored by: TCP
>       Incompatible with: UDP
>       [Description]
> 
> This way, we list how each protocol will treat it, but we're not making normative preferential statements, and we're not relying on the notion of falling back. I think "falling back" is something that belongs in documents around happy eyeballs and racing, etc, and baking in which protocol is a fallback and which is the primary may be quite misleading to implementers.

I completely agree!

That was easy  :)

Cheers,
Michael