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
