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

From: Tommy Pauly <[email-masked]>
Date: Tue, 14 Nov 2017 08:20:14 +0800

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"

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.

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.

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.

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.

Thoughts?

Best,
Tommy

> On Oct 23, 2017, at 4:38 PM, Michael Welzl <[email-masked]> wrote:
> 
> Hi everyone,
> 
> This update addresses 2 out of 3 major comments that we got at the last meeting:
> 
> 1) also fall-back to UDP  => done.  This turned out to be much easier than I thought because the set of transport features for which TCP is a possible fall-back is, with *one* exception (receiving a message) strictly a superset of transport features for which UDP is a possible fall-back.   Sorry for the clumsy sentence but the point is, TCP itself is of course *not* strictly a superset of UDP itself, but that doesn’t matter.  Anyway, because of this superset relationship, we were able to just mark limitations that arise when requiring to fall back to UDP with (!UDP).
> 
> 2) make it clearer that the abstract interface description of the min set is *not* an API proposal => done. I hope this is now clear enough for folks.
> 
> 3) make it less TCP-specific, also consider fall-back to e.g. TLS => not done. Maybe next time?
> 
> Thanks for the very useful feedback, everyone who was there last time!
> 
> Also, there are now considerations on how to begin. With the minset as it was, it is possible for TAPS to choose UDP as a protocol and for the application to later request reliability. At least such deadlocks must be prevented - I’m not claiming that what we put in there is generally ideal (in fact the text explains why it isn’t), but it is one possible approach that avoids such deadlocks.
> 
> 
> Chairs: I’d like to request a 20-minute slot for this update, if possible  (I think this should be enough including discussions, as my presentation would probably fit in about 10 minutes).
> 
> Cheers,
> Michael
> 
> 
> 
>> On Oct 23, 2017, at 1:43 AM, [email-masked] wrote:
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transport Services WG of the IETF.
>> 
>>       Title           : A Minimal Set of Transport Services for TAPS Systems
>>       Authors         : Michael Welzl
>>                         Stein Gjessing
>> 	Filename        : draft-ietf-taps-minset-00.txt
>> 	Pages           : 53
>> 	Date            : 2017-10-22
>> 
>> Abstract:
>>  This draft recommends a minimal set of IETF Transport Services
>>  offered by end systems supporting TAPS, and gives guidance on
>>  choosing among the available mechanisms and protocols.  It is based
>>  on the set of transport features given in the TAPS document draft-
>>  ietf-taps-transports-usage-08.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-taps-minset/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-taps-minset-00
>> https://datatracker.ietf.org/doc/html/draft-ietf-taps-minset-00
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> Taps mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/taps
> 
> _______________________________________________
> Taps mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/taps

---

From: Christopher Wood <[email-masked]>
Date: Tue, 14 Nov 2017 08:36:18 +0800

On Tue, Nov 14, 2017 at 8:20 AM, Tommy Pauly <[email-masked]> wrote:
> 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. Encryption is a property of the connection and the TAPS API
must enable it. If configured, it must always be used, regardless of
how connection establishment is done.

Best,
Chris

---

From: Michael Welzl <[email-masked]>
Date: Tue, 14 Nov 2017 09:08:02 +0800

Hi,

In line:

> On Nov 14, 2017, at 8:20 AM, Tommy Pauly <[email-masked]> wrote:
> 
> - Title should be "4.  A MinSet Abstract Interface" not "4.  An MinSet Abstract Interface”

Ack,

> 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 c…

Absolutely! No problem

> 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 eithe…

Agreed,

> 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 t…

I completely agree!

That was easy  :)

Cheers,
Michael