Re: [Taps] New Version Notification for draft-trammell-post-sockets-00.txt

[Michael Welzl <[e-mail]>]

> On 09 Nov 2016, at 12:30, Brian Trammell <[e-mail]> wrote:
> 
> hi Michael,
> 
>> On 09 Nov 2016, at 10:59, Michael Welzl <[e-mail]> wrote:
>> 
>> 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".
> 
> To some extent, that's the point: if we started over, what would we want the interface to look like.
> 
>> 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!
> 
> ...and shamelessly lifted from Minion.

Well - this seems to be a pretty general requirement, coming from HTTP/2 as well...


>> 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)
> 
> So, there are two ways I see to do this:
> 
> (1) Everything here except message delineation *works* without any specific transport protocol support,

well and (as Minion identified) it all begins and ends with message delineation really - you're not able to offer much of what this draft describes unless you have message delineation.


> it just works better if you have transport protocols that support the contracts. Note that receive() doesn't expose any of the object properties that send() takes, those properties are only used for purposes of ordering, scheduling, and path selection at the sender. So if you have a transport protocol that doesn't support partial reliability, for instance, the lifetimes could be silently ignored. The TAPS transport selection layer could give the application access to information about which contracts of the API are honored and which are not, but an application that didn't care could be written once and still work on the worst fallback, if with less optimum performance.

That seems good to me.


> (2) Alternately, a Post implementation more tightly integrated with a TAPS one could raise errors on attempts to use contracts not supported by the underlying transport. This requires more application logic support, though, and negates one of the advantages we see of this approach: write once, use any transport.

The approach we ended up taking in NEAT (to be presented) is to always choose between "required" or "desired".
"Required" means the API fails and gets back to you; "desired" means you get a fall-back as you describe here. This yields the flexibility that TAPS wants to achieve, yet allows applications to be in control of the things they really must control.


>> 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?
> 
> Post doesn't say this *explicitly*, but I think you've noticed that it's kind of assumed. Yes, I do think it's time to be forward-looking. Where that looking forward happens is a different question: it could happen in TAPS, or in its own WG or RG. In any case, it definitely needs to happen hand in hand with TAPS, as it's an effort that can provide more diversity in ways to implement services and features.

So here's a question. To implement e.g. Post with TCP, one could also provide a layer on top of TCP that offers the suggested API and at least takes care of message delineation (and then that layer could use other protocols instead of TCP too). This would need to be there on both ends of a connection.
I mean, AFAIK, as Minion developed, it was at some point suggested to not insert a delimiter in TCP as part of TCP's functionality, but to simply use delimiters coming from app-layer protocols. I.e., when that protocol has a delimiter, why use another one?

If that's what we need, then all of a sudden, we're not discussing a forward-looking wish-list anymore, but a way to implement a TAPS system. I'd think that would be a better direction than just creating a wish list for new protocols... but both could be done, I guess.


> (reading from my slides which I should send Aaron and Zahed shortly): At least with respect to Post, we're just looking to start that conversation now, to see how many people are interested in this next step, and to get some feedback on what's good about what we're thinking, and what's not so good.
> 
>> 
>> 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?
> 
> Ah, now you've found the older draft buried in the newer draft. :)
> 
> That was an original hard requirement of the wishlist, but as we went down the rabbithole of ordering our wishes the object framing (from SEQPACKET) really stood out as a missing feature that makes sense to have, and it's very hard to have a common API for a send() with asynchronous recv() that doesn't just turn into a read/write loop unless the message framing is there.

Right.


> Again, two approaches I can see to make this happen, neither of which is very good IMO:
> 
> (1) Define a framing layer (or choose an existing one; for maximum layer confusion, how about websockets? ;) ) to run over vanilla TCP; in this case, Post is less of an API than a flexible transport layer, since it can't be used to connect to endpoints not running Post.
> 
> (2) When running on vanilla TCP, only open_stream() works on an association. Same drawbacks as in (2) above.
> 
> Maybe try 1 with a fallback to 2, but then you'd need a negotiation protocol running at both ends, rather than a sensing layer that can work at each endpoint independently as in TAPS.

Sorry for inventing the same as you in my answer above  :-)   it seems we completely agree here. I also agree that both (1) and (2) would be possible solutions.
Interesting idea about the fallback - indeed, wouldn't trying (1) with a fallback to (2) be ideal?!


Cheers,
Michael