Hi, Thanks for posting a really interesting draft!
Similar to the other (also interesting) draft that was just posted ( draft-mcquistin-taps-low-latency-services-00.txt ), this reads quite a bit like a "wish list". I'm not saying that's a bad thing, I think that both drafts contain an interesting and very reasonable wish list (with quite some overlap, 1) with each other, 2) with what current protocols provide, as we can see from draft-gjessing-taps-minset-03). Both also identify at least one thing that seems missing in currently standardized transports: being able to define dependencies between messages. Interesting! However, given that current protocols don't do all these things, what's the context here for TAPS? Should the charter be extended to allow for such "wish lists" for future protocols? (Personally, I'd say yes) I mean, draft-mcquistin-taps-low-latency-services-00.txt even explicitly says "The next phase, enabled both by the use of transport services and their separation from transport protocols, is to define novel transport services based on the needs of applications." I'd say this is clearly *not* what the charter says. When TAPS started, lots of folks wanted this, but TAPS would have never seen the light of day if we had put that in the charter. Now maybe it's time to be more forward-looking? BTW, something that made me particularly curious is, in the draft announced below, the following statement: "It must be possible to implement Post over vanilla TCP in the present Internet architecture." - how? To start with, you require message delineation. What's the idea here? Cheers, Michael > On 27 Oct 2016, at 14:52, Brian Trammell <[email protected]> wrote: > > Greetings, TAPS, > > We've submitted an initial version of our Post Sockets abstract interface > draft, draft-trammell-post-sockets. It's not yet clear that we'd want this to > be adopted by the TAPS working group for a future milestone in partial > fulfillment of point 3 on the charter -- perhaps the ideas here are merely an > illustration of what is possible in the space, that could point toward a more > concrete definition of an abstract interface for TAPS. We'd like to discuss > this point in Seoul. > > Thanks, cheers, > > Brian > >> Begin forwarded message: >> >> From: [email protected] >> Subject: New Version Notification for draft-trammell-post-sockets-00.txt >> Date: 27 October 2016 at 11:57:39 GMT+2 >> To: "Mirja Kuehlewind" <[email protected]>, "Tommy Pauly" >> <[email protected]>, "Brian Trammell" <[email protected]>, "Colin Perkins" >> <[email protected]> >> >> >> A new version of I-D, draft-trammell-post-sockets-00.txt >> has been successfully submitted by Brian Trammell and posted to the >> IETF repository. >> >> Name: draft-trammell-post-sockets >> Revision: 00 >> Title: Post Sockets, An Abstract Programming Interface for the >> Transport Layer >> Document date: 2016-10-27 >> Group: Individual Submission >> Pages: 17 >> URL: >> https://www.ietf.org/internet-drafts/draft-trammell-post-sockets-00.txt >> Status: https://datatracker.ietf.org/doc/draft-trammell-post-sockets/ >> Htmlized: https://tools.ietf.org/html/draft-trammell-post-sockets-00 >> >> >> Abstract: >> This document describes Post Sockets, an asynchronous abstract >> programming interface for the atomic transmission of objects in an >> explicitly multipath environment. Post replaces connections with >> long-lived associations between endpoints, with the possibility to >> cache cryptographic state in order to reduce amortized connection >> latency. We present this abstract interface as an illustration of >> what is possible with present developments in transport protocols >> when freed from the strictures of the current sockets API. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> > > _______________________________________________ > Taps mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/taps _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
