Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports

HI,

As a general comment then I believe that when describing what is supported
by TCP/SCTP (or UDP) as standard then it does not suffice to look into
IETF RFCs.
One need at least to relate to the *basic functions* of the POSIX/Berkeley
socket api standard.

My understanding of the TCP API, for example, is that while RFC793 did
specify an abstract API for TCP, then
the true defacto standard for the socket api is the Berkeley socket api
from .?. around 1990.
Not saying the different socket api standards don't differ and that there
is *one* standard to look at.
But making is be RFC793 rather then what emerged as defacto in the 1990's
seems a "bit odd" to me.

Especially since we have RFCs RFC1122 dating back to 1989 already
clarifying part of RFC793 (namely the PUSH bit)
And one, much more recent, RFC6093, clarifying the urgent bit.

Please see below.

> -----Original Message-----
> From: Taps [mailto:taps-bounces@ietf.org] On Behalf Of
> gorry@erg.abdn.ac.uk
> Sent: 3. november 2015 22:33
> To: Michael Welzl <michawe@ifi.uio.no>
> Cc: taps WG <taps@ietf.org>
> Subject: Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports
>
> A note just on the INFO status of SCTP APIs (below):
> >
> > Dear all,
> >
> > Sorry for not being able to attend the TAPS meeting on site or even
> > remotely. I just finished watching the recording, and I noticed that
> > the question of RFC 6458  - "why is the SCTP part of draft-welzl- ..
> > based on only RFC 4960 and not on RFC 6458?" - was brought up several
> > times. I'd like to provide an answer and start a discussion about
this.
> >
> > There are two reasons why RFC 6458 wasn't used in
> > draft-welzl-taps-transports-00: a very mundane one, and a more serious
> > one. I'll list them both and hope we can discuss the second reason.
> >
> > 1) Reason one: RFC 6458 is quite long, and I wanted to limit the
> > amount of work I'm putting into the -00 version, given that the point
> > was to show people the procedure and the idea and see what they think,
> > and not to fully cover everything 100% correctly yet. Basically, I
> > didn't want to risk writing out all the stuff from RFC 6458 and then
> > have people tell me to go away  :-)
> >
[Karen Elisabeth Egede Nielsen] I have no problem with this approach. Only
now that you're
in, I would like you to look at RFC6458.

> > 2) Reason two, more serious: RFC 6458 is Informational, and my
> > understanding was that this is just one description of one API
> > implementation, not a recommendation or even prescription of what all
> > SCTP implementations must provide. However, my decision for
> > draft-welzl-taps-transports was to *exclude* things that are only
> > optional to implement - I don't think we want to end up with a TAPS
> > system that provides services that, alas, on Operating System XY are
> > not available because here only a subset of the API is implemented.
> > Therefore I went with a minimal set of functions that I thought we can
> > assume are implemented everywhere (well, at least in every system that
> > claims to "follow the spec").  Can we assume that every system that
> > claims to implement SCTP in accordance with the spec fully implements
RFC
> 6458?
> >
> GF: From a TSVWG Chair perspective, beware here...  *ALL* more recent
> IETF SCTP API work from TSVWG is INFO.  Each SCTP RFC is expected to
have
> an informative section that describes the API together with the
normative
> protocol spec. That is not because there are expected to be alternatives
to
> choose from:  It's because, as I understand, the IETF is not the formal
> standards body for specification of such normative APIs.
> >
[Karen Elisabeth Egede Nielsen] Not only that. RFC6458 was around as a
tsvwg  wg draft
long before RFC4960 work was started. My understanding is that while going
from RFC2960 to RFC4960 one did
not bother "too much" with updating the API section of RFC2960 -->
RFC4960, as the finer API details were being
worked on in this wg draft.

However I was not personally involved in IETF SCTP back then, so I like to
ask others to confirm this.

Something else:

The implementation that I have worked with was initiated in the early 2000
and at that time we
looked for RFC2960bis (RFC4960) for protocol specification and the socket
api for api features.
Yes there are particulars of the RFC6458 which represent implementations
aspects. For example
our API implementation implements certain calls in the format they were
specified in ver 14/15 of the socket api from
draft from around 2007  and not the exact form the calls have in RFC6458
(version 30-some of the draft) from 2011,
but the features available as controllable has not changed much during the
years. And it is the features available,
not the implementation aspects that we are focused on in Taps.

NB:
But I have to admit that in our SCTP API implementation we implements the
basic POSIX api functions of TCP/IP for SCTP simply
when they makes as much sense for SCTP as they do for TCP/IP. For example
DSCP is settable via a socket option per association,
even if I think this cannot be found in RFC6458 nor in RFC4960 (which is a
bit of a surprise to me). So my view
on the basic API functions of SCTP (as for TCP) is influenced by this.
Which I have to recognize.

> >
> > A side note about TCP, because Karen made a comment about the TCP API
> too:
> >  a similar logic applies here, irrespective of whether the API is old
> > or
> > not: I think we should cover whatever a system claiming to "implement
> > the protocol in accordance with the spec" has to cover. Going down the
> > path of looking at actual socket API implementations is dangerous in
> > that we end up in "only implemented here, not there" - land. We want a
> > minimal set of mechanisms that are (or at least really should be! for
> > that, what else can we use as a basis than our own recommendations?!)
> available everywhere.

[Karen Elisabeth Egede Nielsen] Yes I agree completely ! The difficult
exercise is where from
to gather this minimal set of mechanisms in a qualified manner.

> > Karen, you specifically mentioned URG and PSH and how they are
> > implemented; what is it in draft-welzl-.. about these two mechanisms
> > that you don't agree with?
> >
[Karen Elisabeth Egede Nielsen]

The PUSH bit as settable by application was recognized as being optional
by RFC1122 (1989).

Enforcing the PUSH bit set via Nagle off, does not mean that one can
control the PUSH function (one do get Nagle off at the same time).

Possible certain implementations have certain tweeks so that one may
control the PUSH bit from ULP. If that is consider to be the
Defacto standard, even if RFC1122 says that it is optional, then I do not
disagree, but is it so ?

The PUSH bit makes the data be available for read by the application (when
in-line) but I am not sure this, as defacto, makes
the data be pushed to the application in most common api's exposed to
applications today. In some implementations, a socket becomes readable
based on the amount of data that has arrived correlated with when the
application has asked to be awaken (in number of bytes), but the PUSH flag
makes no difference. Possibly that is a deficiency of such
implementations. Not sure ?
I know that in some implementations then a socket becomes readable only if
the receive buffer is full or the PUSH flag has arrived.

Perhaps I should ask in tcpm, if TCP implementations generally pushes the
data to the application (or notifies the application) when the PUSH bit is
seen ? Or perhaps I will get an overwhelming - YES SURE !! - response this
to email, and then at least  the receive part of the PUSH is then inline
with RFC1122/RFC793.

BR, Karen

> > Cheers,
> > Michael
> >
> > _______________________________________________
> > Taps mailing list
> > Taps@ietf.org
> > https://www.ietf.org/mailman/listinfo/taps
> >
> Gorry
>
> _______________________________________________
> Taps mailing list
> Taps@ietf.org
> https://www.ietf.org/mailman/listinfo/taps