Will be there for sure! Thanks, Nalini Elkins Inside Products, Inc. (831) 659-8360 www.insidethestack.com
________________________________ From: Michael Welzl <[email protected]> To: Nalini Elkins <[email protected]> Cc: Matt Mathis <[email protected]>; "[email protected]" <[email protected]>; "[email protected]" <[email protected]> Sent: Thursday, October 10, 2013 5:54 AM Subject: Plan for Vancouver Hi, I updated the subject... I hadn't made a plan for meeting yet; given the many collisions people usually have in the evenings of the IETF week, the relatively low priority this will have to many, and the unknown number of people interested + on site, I suggest the following procedure: Many of us will be at TCPM on Monday morning, which ends at 11:30; I will then stand at the IETF reception desk on Monday from 11:40 to 12:00, collecting people. If you show up in this time frame, you become part of a group that goes off to have lunch in the hotel together at 12:00, and will chat until up to 14:30 (the end of the next time slot, which doesn't contain anything related to TSV). If I find myself in a crowd of hundreds of people standing there, all craving for food on Monday lunch time, we'll use this chance to agree on a day and time for an evening meeting in a bar somewhere (making it a "real" bar BOF, with beer and stuff! woo hoo!), and I'll figure out a place and announce it on the transport-services list. Again, the short version: Monday 11:40-12:00, reception desk. Be there and see what happens. Cheers, Michael On 10. okt. 2013, at 14:10, Nalini Elkins wrote: Michael, > > >We have been working on a unified mechanism for Inter Layer Communication >(ILC) and Simplified Congestion Control (SCC) for all apps to use. > > >From looking at your draft charter, I am not sure that this fits into your >group. Will you be having a meeting in Vancouver to discuss? Did I miss that >email? > >Thanks, > > >Nalini Elkins >Inside Products, Inc. >(831) 659-8360 >www.insidethestack.com > > > >________________________________ > From: Michael Welzl <[email protected]> >To: Matt Mathis <[email protected]> >Cc: [email protected]; [email protected] >Sent: Wednesday, October 9, 2013 2:31 AM >Subject: Re: Call for participation: Transport Services > > > >Hi, > > >I'll start with this: > > >Your broadcast message should have included "Please discuss on xxxx list." > > >Apologies! The best I can do is say it now: please discuss on the >[email protected] list (in cc); subscription info: >https://sites.google.com/site/transportprotocolservices/ > > > > >On 8. okt. 2013, at 18:15, Matt Mathis wrote: > >I'm sorry if I haven't been paying attention, but what do you mean by "the >topic of transport services"? >> >> >>Several things come to mind: >> >>- please deliver my data >>- y/n reliable delivery >>- y/n out-of-order delivery >>- y/n fast connect, w/ or w/o crypto protection >>- optimize for min latency vs optimize for max throughput >>- weighted congestion control for fine tuning priorities >>- y/n multiple paths or endpoints >>- y/n "nat compatible" >>- y/n for event notification (up/down etc) >>- etc > > >I'd include many but not all of the things above. A part of the exercise of >working towards a BOF is to agree on how to decide which things would and >wouldn't be included in a list of transport services, and a first stab at the >approach for arriving at a list is included in our initial charter proposal: >https://sites.google.com/site/transportprotocolservices/home/charter-proposal-before-bof >(the steps 1, 2, 3). > > >If this sounds too abstract, I can go through your list above case-by-case >using the method described there, leading to "in", "probably in, but >represented in another way", "out" decisions for every item in the list I >think - but right now I'll refrain from doing that to avoid making this email >unnecessarily long. > > > >In varying degrees we know how to do most of these in both TCP and SCPT. The >trick to providing them as "services" is to unbundle the (sub)layers. > >Yes. > > > >If you mean to design a API, I think you will find that the IETF has a lot of >trouble with stuff that is not visible on the wire, and has repeatedly failed >to converge on such issues. > > >I mean to design services that would be exposed by an API, and describe >example API implementations. >(which is a politician's way of saying "yes, I want to design an API", I guess > :-) ) > > >About what's visible on the wire: imagine that, instead of having the >transport mechanisms that applications want embedded in the applications, we'd >have a transport system underneath an API that we could just ask for a certain >service instead of only requesting "TCP" or "UDP". Then clients would like to >tell servers what kinds of services they'd like to have or which services they >could accept. This signaling would have to specify a transport service (so >there you have something on the wire) - but without having a standardized list >of transport services, all a client can ever do is to signal services that it >*knows* to be available on the other side. Without a standardized list, the >only way to know what's available is if it's the same application - e.g. Skype >talking to Skype. So this is how we're stuck with a situation where every >application that needs a bit more than TCP's behavior from the network has its >own UDP-based transport solution built in. I think the first step towards breaking this up is to agree on services and define them (and write the code, which some folks involved in this are doing). > > >Cheers, >Michael > > > >
