What I mean is defining what the apps need is not independent of also defining what the protocols offer.
Marie-Jose Montpetit, Ph.D. mari...@mit.edu @SocialTVMIT > On Feb 5, 2015, at 4:57 AM, Michael Welzl <mich...@ifi.uio.no> wrote: > > >> 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
