Re: [Taps] Eric Rescorla's No Objection on draft-ietf-taps-minset-08: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Thu, Sep 13, 2018 at 11:02 AM, Michael Welzl <[e-mail]> wrote:

> Hi,
>
>
> > COMMENTS
>> > S 1.
>> >     of libraries to use this transport feature without exposing it,
>> based
>> >     on knowledge about the applications -- but this is not the general
>> >     case).  In most situations, in the interest of being as flexible and
>> >     efficient as possible, the best choice will be for a library to
>> >     expose at least all of the transport features that are recommended
>> as
>> >     a "minimal set" here.
>> >
>> > What is the bar for the requirements here. I.e., do you believe that
>> > all of these can be implemented with a standard sockets API.
>>
>> I don't fully get this - it CAN be implemented atop the standard
>> socket API (cf. https://github.com/NEAT-project/neat), if that's
>> what you're asking?
>>
>
> How do you implement limits on retransmission rates with standard sockets?
>
>
> It’s an SCTP feature (limiting the number of retransmissions is a part of
> its partial reliability, specified as one way of doing it in RFC 3758);
> when you fall back to TCP, you do nothing.
>
> In terms of the document, the following text in appendix A.1 says it:
>
>    o  Configurable Message Reliability
>       Protocols: SCTP
> (..)
>       Implementation over TCP: By using SEND.TCP and ignoring this
>       configuration: based on the assumption of the best-effort service
>       model, unnecessarily delivering data does not violate application
>       expectations.  Moreover, it is not possible to associate the
>       requested reliability to a "message" in TCP anyway.
>       Implementation over UDP: not possible (UDP is unreliable).
>
>
> If that seems disappointing: the goal of this document was to describe
> what can be done while being protocol-independent and allowing to fall back
> to TCP, or even UDP in some cases. The minute you write code that checks if
> configuring retransmission limits is possible, you need to implement an
> exception for the TCP case. I’m not saying this is bad design at all, it
> just wasn’t the goal of the minset. This doesn’t mean that a TAPS system
> needs to be limited in this way - it’s just the minimum you can expect from
> it.
>

I'm not disappointed, I'm just trying to figure out how to think about this
API and its requirements.

What does it mean to implement this API when you have a transport which
doesn't support the feature? Just that you have an affordance that pretends
to implement it but doesn't?



> S 3.
>> >
>> >     Based on the categorization, reduction, and discussion in Appendix
>> A,
>> >     this section describes a minimal set of transport features that end
>> >     systems should offer.  The described transport system can be
>> >     implemented over TCP.  Elements of the system that are not marked
>> >     with "!UDP" can also be implemented over UDP.
>> >
>> > Does this mean over native UDP with no other session protocol. Because
>> > you can have TCP over UDP.
>>
>> Native; we added a disclaimer about this at the end of the introduction.
>>
>>
>>
>> > S 3.2.
>> >     multiplexed as streams on a single SCTP association when SCTP may
>> not
>> >     be available).  The transport system must therefore ensure that
>> >     group- versus non-group-configurations are handled correctly in some
>> >     way (e.g., by applying the configuration to all grouped connections
>> >     even when they are not multiplexed, or informing the application
>> >     about grouping success or failure).
>> >
>> > How do you group connections in TCP? Or is this text saying it
>> > doesn't?
>>
>> The text doesn't make any assumption about this being possible with
>> anything but SCTP. This being said, I can't resist offering an answer
>> (but that's out of scope of minset):
>> https://ieeexplore.ieee.org/document/8406887/
>
>
> This is behind a paywall, but it appears to just be about congestion
> control, so perhaps there is some confusion about "grouping". I had read
> that as application visible grouping. Is that not what you mean?
>
>
> Sorry for the link problem; it IS application visible grouping, with
> prioritization. There’s also this draft:
> https://tools.ietf.org/html/draft-welzl-tcp-ccc
> and we have FreeBSD code doing this. Safiqul has various material here:
> http://safiquli.at.ifi.uio.no/tcp-ccc/
>
> I think we're diverging from the minset discussion, so I’ll stop here -
> but if this really interests you, tell me: I’d be very happy to discuss it
> further and send you the paper. I’d love for someone to use this!
> Since you mentioned TCP over UDP before - that’s actually one of the
> things we implemented, to ensure that flows traverse the same path.
>

I'd love to see the paper.


>
> > S 7.2.
>> >
>> >     o  Disable MPTCP
>> >        Protocols: MPTCP
>> >        Automatable because the usage of multiple paths to communicate to
>> >        the same end host relates to knowledge about the network, not the
>> >        application.
>> >
>> > I don't think I understand how this is automatable. Is the theory that
>> > the host auto-negotiates MPTCP? But what if the app doesn't want it no
>> > matter what.
>>
>> Then the application wants more than what this design of strictly
>> "application-specific knowledge" is giving it. That's the trade-off here -
>> there may be many reasons for applications to want things beyond this
>> document, but if we weren't strict about these limitations, this would
>> have hardly become a "minimal set".
>>
>
> That's reasonable, but it seems like a somewhat confusing definition.
>
>
> What is it that’s confusingly defined? “application-specific knowledge”?
> “Automatable"? Happy to fix if you tell me what.
>

Automatable, I think.

-Ekr


> Cheers,
> Michael
>
>