Re: [Taps] Feedback Re: Fwd: New Version Notification for draft-gjessing-taps-minset-05.txt

[Michael Welzl <[e-mail]>]

Hi,

and thanks a lot for your comments!

Answers in line:


> On Jun 26, 2017, at 4:18 PM, Theresa Enghardt <[e-mail]> wrote:
> 
> Hi,
> 
> when reading the minset draft, I stumbled over a couple of points. Some of them may be nits and/or obvious to everyone except me, but I thought I'd offer them as feedback.
> 
> Section 2 (Terminology): Would it make sense to define several more terms here, such as Flow, Flow group, Message and Frame? While reading the rest of the draft I was, e.g., wondering if a "TAPS flow" is the same as "Connection" defined in Section 2 or something else. E.g., in Section 3.1 the draft talks about how to create a TAPS flow and at least for me it would be helpful to read a description of what a TAPS flow actually is beforehand.

Good input, will do!
(the answer is: it can be a (TCP) connection, a stream of an (SCTP) association, an (SCTP) association, …   so i thought it’s good to use a new word; yet it does fit the definition of a connection in section 2)


> Section 3.1 (Flow Creation, Connection and Termination), second paragraph: "A created flow can be queried for the maximum amount of data that an application can possibly expect to have transmitted before or during connection establishment." 
> I had trouble understanding this sentence, as it was not immediately obvious to me that it is possible to send data before a connection is established. Maybe it would be helpful to first state that this is a feature that some protocols have.

ACK, will do, thanks!


> Section 3.2 (Flow Group Configuration): Is it also possible to configure these features on individual flows? Only if they do not have a group? (I had the same question again later at the beginning of Section 4.)

These things apply to a group only, because in case a flow becomes a stream of an association, the protocol can only apply them to all  (e.g., change the timeout - you can’t do that for one stream of an SCTP association only). I’ll try to clarify this in the text.


> Section 3.3 (Flow Configuration): At this point I was also wondering how to configuring a flow to be, e.g., reliable. As reliability is one of the most obvious transport features for me, I would find it useful to make this explicit. It is not configured per flow, but per message, right? So an application can send both reliable and unreliable messages in one flow, but it does not communicate this through the TAPS API at flow creation time, but only later when it actually sends the messages?

Exactly. Though here lies a fault - if this is not communicated at all, the TAPS system may choose UDP, and then a sender decides for reliability….  bad!  Good catch !  Will try to fix.


> Section 3.4.1 (The Sender): This section talks about messages and per-frame properties. Is a message the same as a frame here?

Yes - but it’s another fault, I tried to use frame everywhere as the new term here just to avoid making a connection between “message” and an SCTP “message”  (can be the same but doesn’t have to be). So, use of message is a mistake. Will fix!


> Features that are optional - So are these still mandatory features to have in the API (which I thought the minset was) but then they do not have to be implemented, i.e., actually do something?

Hm, I see them as optional in the API… I don’t think we can truly “mandate” a minset - it is meant to be a set of functions that you will never be able to use unless you offer them in an API in one way or another.
In that sense, offering e.g. "Get max. transport frame size that may be sent without fragmentation from the configured interface” is just an optimization, because a user could just as well decide to forbid fragmenting and test various frame sizes … a less efficient way of implementing PMTUD atop minset than by using this extra functionality. So, I thought it’s less important to offer this extra...

Then again since nothing is *truly* mandatory maybe we should just skip saying “this and this is optional”.


> Section 4 (An Abstract MinSet API): Do I have to create a flow-group-id explicitly or is the flow-group-id just the flow-id of a previous flow? In other words, are the flow-id and the flow-group-id the same number space or are they distinct?

They’re distinct. The group is just a number to group flows, and flows must have identifiers too - so you can have group 1 containing flows 1, 2, 3 and group 2 containing flows 1, 2, 3.
I’ll try to make the text clearer, thanks!

Cheers,
Michael