i dont have any spare time to do it, but maybe someone could have a go at analyzing all the different TCP offload techniques, which would give another lens to view this through...
On Sat, Jun 20, 2015 at 9:35 AM, Michael Welzl <mich...@ifi.uio.no> wrote: > > > On 20. jun. 2015, at 00.55, Joe Touch <to...@isi.edu> wrote: > > > > > > > > On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote: > >> > >> > >> On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch <to...@isi.edu > >> <mailto:to...@isi.edu>> wrote: > >> > >> > >> You're getting far ahead of the conversation, IMO. This document > >> needs to start by explaining the services we already have before > >> jumping into a "service of services" model. > >> > >> I don't disagree with the goal, but it's impractical to develop a > >> meta-interface when the base interface has not been described. > >> > >> > >> It is just to say that TCP already defines its services, and the goal is > >> not to give another definition of these services, but only to change the > >> way they are exposed to applications. So the services definition already > >> exists, but implicitly. > > > > It's explicit - see section 3.8 of RFC 793. The issue with that variant > is that it captures the state of TCP in 1981; it has evolved quite a bit > since then. Although we do have a 793-bis in the works, the update of that > section hasn't been tackled yet. > > > > Let's put it this way: > > > > - if the goal of TAPS is to unify existing APIs, > > then those APIs need to be summarized together in one place > > > > > > - if TAPS is indeed focused solely on an alternate API, > > then it should NOT try to 'restate' the existing TCP API > > in a TAPS doc > > > > "Do, or do not; there is no try." > > - Yoda > > TAPS is focused on an alternate API that it's based on existing > transports. As a way of analyzing existing transports and creating a > foundation for this API, document #1 is written. I think this discussion is > about the approach taken to write document #1. > > So now I wonder what you're complaining about, as you go on about TCP > already defining its services implicitly in the API. I mean, yes it does, > okay - and so? You criticized the SCTP API for not being abstract enough - > so clearly if we'd just copy+paste the API descriptions of the RFCs of the > considered transports in a list, that would look pretty messy. You seem to > want a "clean" approach, but you're not going to get that unless we focus > on TCP alone :-) > > I've been proposing go through transport APIs and then analyze what we > have, because this way, SCTP is already going to give us a long list of > services. > You've been saying that we should start with TCP. Well okay, but the > service list there is pretty narrow. Maybe the TCP API isn't properly > described in the current draft, okay, I think we can take that criticism > for what it is. Still, I don't know what you're really after - in the end, > we're going to get a list that's pretty similar to what's there now, and > that's what we want, right? > > - unordered reliable delivery of messages > - delivery of messages with timed delivery > - reliable delivery of a data stream (naturally that's ordered) > > .... and so on. Right? Or what else is it you want / expect? > > Cheers, > Michael > > _______________________________________________ > Taps mailing list > Taps@ietf.org > https://www.ietf.org/mailman/listinfo/taps >
_______________________________________________ Taps mailing list Taps@ietf.org https://www.ietf.org/mailman/listinfo/taps
