Add Transport Property Profiles

[philsbln]

This addresses Issue #325

[gorryfair]

So, some comments:

• First I suggest that we explicitly refer to these but the service they provide, not the protocol they resemble. Hence:

• The final one would be "datagram service" and UDP is an example of such.

• I would also suggest it is useful to say that the application-supplied properties can now override these defaults, hence in the Datagram case, the property permitting/requiring partial coverage could result in UDP-Lite being selected instead of UDP to supply this service.

• Then, I have a question about the specific UDP/Datagram service. This currently says:

Property	Value
reliability	avoid
preserve-order	avoid
congestion-control	avoid
preserve-msg-boundaries	require
idempotent	true

To me some of these are not really requirements, but to me seem like side affects. The requirement could be to need low latency, and idempotence, preserve-msg-boundaries, etc
but I wouldn't care if the service also happened to provide the following, as long as those requirements (or whatever we agree upon) were prioritised: reliability, preserve-order , congestion-control. (Of course UDP would not offer these, and that would also be fine).

Thoughts?

[philsbln]

I agree with the first point and updated the PR accordingly.

For the second one, I also agree that avoiding reliability, order preservation, and congestion-control are side effects of latency or other optimisations and do not really belong into the profile. Therefore, I changed "avoid" to "ignore".
I am a bit hesitant about speaking about UDP lite here given your first point, tried to incorporate it as a hint in a slightly different way.

After these changes, I would like to raise the question whether we should mention "udp like" or "tcp like" for the impatient searching the document.

[gorryfair]

Looks better, thanks for checking my inputs. Will comment on the integrated text, unless there is more debate

[gorryfair]

Something to help start thinking: we could say something like this datagram service resembles the service offered by the socket API that binds to the UDP transport?

[gorryfair]

Something to help start thinking: we could say something like this datagram service resembles the service offered by the socket API that binds to the UDP transport?

[mwelzl]

I checked this now and like it. I also read the dialogue and agree with all points that were raised and how they were answered.

Regarding @gorryfair 's suggestion to say: "we could say something like this datagram service resembles the service offered by the socket API that binds to the UDP transport?" - actually, when reading the update first before looking at the comments, I thought "why doesn't this say: 'an example of a protocol that provides this service is UDP' ?". I think this is almost the same thing, but I like my own phrasing better :) the whole "socket API that binds to" thing seems a bit clumsy to me and I don't think we need it.

[britram]

Thanks, this is useful! However, I think it would be better self-contained in the appendix.

[britram]

I think this is very useful in the appendix, but adding language here in the normative section might lead to some of the confusion that putting this in the appendixi is meant to avoid. Consider leaving this section unchanged, and make the modification to NewTransportProperties() in the appendix where properties are introduced.

[philsbln]

Hmm… I think it is a much worse idea to modify function signatures in the appendix

[philsbln]

I liked the split between saying "there are profiles" in the normative part and defining examples for these in the appendix. If this is a Problem, we should rather move the profiles into the property section. I have a bad feeling about modifying function signatures defined in the main documents in the appendix.

Any other opinions?
Leave un-merged and discuss in Montreal?

[mirjak]

I actually think this is useful but more an implementation question. I don't think this need to a part of the base API, so having this in the appendix or the implementation draft seems more suitable for me.

[philsbln]

@mirjak What about the Parameter to pass the profile – is re-defining it in the appendix the right way?

[mirjak]

The API we define is anyway mostly a recommendation and will not be normative; so you will always she slight variations in the implementation. Proposing an optional parameter (in the appendix or implementation draft) seems okay.

[tfpauly]

I believe that profiles are conveniences that are layers implementations can build on top of the TAPS interface, but they do not need to belong in the API definition, and I think they're unnecessary to add here. At the most, we can say that implementations MAY make conveniences that are implementation -specific.