> On 05 Feb 2015, at 09:54, Marie-Jose Montpetit <mari...@mit.edu> wrote: > > > > >> On Feb 5, 2015, at 3:44 AM, Michael Welzl <mich...@ifi.uio.no> wrote: >> >> >>> On 05 Feb 2015, at 00:29, Marie-Jose Montpetit <mari...@mit.edu> wrote: >>> >>>> snip/snip >>> >>>> In summary, we need a better way to describe the services we want before >>>> we'll ever be able to expect the transport to handle them properly. >>>> >>> I totally agree. >> >> We've been around the "let's specify what the application wants, not what >> protocols can do" block a couple of times prior to creation of this group. >> We started and ended with the bottom-up'ish plan that is in the charter now. > > Yes but in fact I think that you have to look at both ends: define what the > service wants can be tricky but necessary. On the other hand it also almost > implies that the mechanims or services also expose their characteristics - if > not, matching of services to transport cannot happen.
I couldn't parse this. What do you mean? >> So, if you take a look at item #2 in the charter, it's rather unclear what >> that item is going to look like, and in particular how we'll arrive there: >> >> "2) Specify the subset of those Transport Services, as identified >> in item 1, that end systems supporting TAPS will provide, and >> give guidance on choosing among available mechanisms and >> protocols. Note that not all the capabilities of IETF Transport >> protocols need to be exposed as Transport Services." >> >> We'll have to figure out reasonable ways to shorten the list in item #1 at >> some point; this could include compiling a number of services under more >> application-oriented terms - such as "willing to choose low latency at the >> cost of X". What this statement precisely means depends on "X", and I think >> we can get an idea of what "X" is when we create that service from the list >> in item #1, not out of the blue. >> >> Does that make sense? > Yes but the issue will be in defining X - less latency at the expense of > bandwidth or more complexity in the network or ??? Each of those may imply a > different transport. Agreed - my point is: when we build #1, X will come. Michael _______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
