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 > > >
