Hi, In line:
> On Nov 14, 2017, at 8:20 AM, Tommy Pauly <[email protected]> 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
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
