hi Michael, (snipping some history...)
>> (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. That's a good distinction to make. This, of course, doesn't solve the problem of needing a framing to make this work, as noted below. >>> 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. So I'm not sure I understand what you're suggesting here... are you saying that there'd be some application-layer callback to determine where the framing is on the receive side? Yeah, that might work. (If that's not what you're saying... well, it might work anyway :) ) >> 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?! Yes, except that there the application has to know about the fallback, and has to work with streams, which changes its logic. And it'd be nice if we could avoid that. But if there were a way to piggyback on application-layer framing, that might make this less awkward. I think we're on to something. In any case, it definitely answers the first question we had (do we want to talk about this further in a TAPS context?) Cheers, Brian
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
