Re: [Taps] TCP components

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 <michawe@ifi.uio.no> wrote:

>
> > On 20. jun. 2015, at 00.55, Joe Touch <touch@isi.edu> wrote:
> >
> >
> >
> > On 6/19/2015 3:42 PM, Mohamed Oulmahdi wrote:
> >>
> >>
> >> On Sat, Jun 20, 2015 at 12:11 AM, Joe Touch <touch@isi.edu
> >> <mailto:touch@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
>