Then we agree.
On Feb 5, 2015, at 12:21 PM, Marie-Jose Montpetit <[email protected]> wrote: > What I mean is defining what the apps need is not independent of also > defining what the protocols offer. > > Marie-Jose Montpetit, Ph.D. > [email protected] > @SocialTVMIT > >> On Feb 5, 2015, at 4:57 AM, Michael Welzl <[email protected]> wrote: >> >> >>> On 05 Feb 2015, at 09:54, Marie-Jose Montpetit <[email protected]> wrote: >>> >>> >>> >>> >>>> On Feb 5, 2015, at 3:44 AM, Michael Welzl <[email protected]> wrote: >>>> >>>> >>>>> On 05 Feb 2015, at 00:29, Marie-Jose Montpetit <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/taps
