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 protected]> 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 protected] 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 protected]
>> https://www.ietf.org/mailman/listinfo/taps
>
> _______________________________________________
> Taps mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/taps
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
