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

[Karen Elisabeth Egede Nielsen <[e-mail]>]

Yes we agree ! :-) .
Glad that ended here.
Thanks a lot for the patience.

BR, Karen

> -----Original Message-----
> From: Michael Welzl [mailto:[e-mail]]
> Sent: 4. november 2015 21:39
> To: Karen Elisabeth Egede Nielsen <[e-mail]>
> Cc: <[e-mail]> Fairhurst <[e-mail]>;
> [e-mail]
> Subject: Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports
>
> Hi,
>
> I'm cutting the part about URG, because here we agree. I think we agree
> about PUSH too, but I'll say it in line below  :-)
>
>
> >> and about PUSH:
> >>
> >> ***
> >> The 'receive'
> >>   command can (under some conditions) yield the status of the PUSH
flag
> >>   according to [RFC0793], but this TCP functionality is made optional
> >>   in [RFC1122] and hence not considered here.  Generally, section
> >>   4.2.2.2 of [RFC1122] says that PUSH on send calls MAY be
implemented,
> >>   which could be a reason not to consider it here.  However, the text
> >>   then explains that "an interactive application protocol must set
the
> >>   PUSH flag at least in the last SEND call in each command or
response
> >>   sequence", and most implementations provide some option to cause a
> >>   behavior that is in some way similar to PUSH.  Therefore PUSH is
> >>   described as a part of SEND here.
> >> ***
> >>
> > [Karen Elisabeth Egede Nielsen] There is a very clear distinction in
> > between capitalized Keywords and non-capitalized must's and should's
> > in section
> > 4.2.2.2 of rfc1122.
>
> I know....
>
>
> > I have no problem with assuming that TCP implementations follow
> >           MUST set the PSH bit in
> >            the last buffered segment (i.e., when there is no more
> >            queued data to be sent).
>
> but it isn't a MUST, it's a "must".
>
>
> > I have no problem with assuming that applications, if the MAY option
> > is supported at the api, s Is assumed to set the PUSH flag at the
> > occasions described in RFC1122.
> >
> > But I do have a problem  with the following text - repeated from your
> > paragraph above;:
> >
> >> and most implementations provide some option to cause a
> >>   behavior that is in some way similar to PUSH.  Therefore PUSH is
> >>   described as a part of SEND here.
> >
> > You are referring to "most implementations provide some option"
> >
> > What do you mean by "most implementations" ?
> >
> > What do you mean by "option" ?
>
> GAAAAAAH !!!!!!   Here you did catch me diverging from my own
rules!!!!!!!
> That must have come from looking at actual API implementations, and no
it
> REALLY shouldn't be there. I did intend to strictly only follow RFCs.
Big
> mistake, very sorry!
>
>
> > My problem particularly with "the option" part, is that is to me in
> > the context of an API description sounds as if this "option" is a
> > function in the API (read an "API option") that the ULP can invoke.
>
> Based on what you said about capitalization and on the mistake in
talking
> about actual implementations I saw, I tend to erase PUSH from SEND
> because it's only qualified as MAY, period.
> Ok?
>
>
> >> We can debate these decisions, but I did base them on RFC 1122 and
> >> RFC 6093.
> >>
> >> More about PUSH:
> >>
> >>> [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).
> >>
> >> Technically, I don't see a connection between Nagle and PUSH. It's
> >> kind
> > of
> >> obvious though that if you want small messages to be delivered fast,
> >> you don't want Nagle and you do want PUSH, but still these are
> >> separate functions.
> >
> > [Karen Elisabeth Egede Nielsen] Perfect. I cound't agree more !!
> > I was trying to understand which "API option" that you might be
> > referring to, and as I have had many (in my opinion confused)
> > discussions with certain TCP users which looking for the "API option"
> > for setting of the PUSH, thought they had to use Nagle off for this.
> > While in fact they didn't have to do anything because the stack will
> > set the PUSH bit following the RFC1122 MUST.
> >
> >> This sounds exactly like the type of confusion we may end up with if
> >> we follow actual API implementations and not what the spec says!
> >>
> > [Karen Elisabeth Egede Nielsen] GOOD. I am happy that we avoid this.
> > So could we loose the text about that the TCP API provides an option
> > to control the PUSH flag - :-) :-) !!
>
> See above - we're in agreement. I'll drop it.
>
>
> >>> 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 ?
> >>
> >> See my interpretation above: I think RFC 1122 is a bit ambiguous
> >> here,
> > once
> >> saying it MAY be implemented, then saying "an interactive application
> >> protocol must set the PUSH flag ...."  ... though this isn't a
> > capitalized MUST.
> >>
> > [Karen Elisabeth Egede Nielsen] For what it is worth (if anything)
> > this is not how I interpret the text. I understand the text as saying
> > that if the MAY option to set PUSH in the apu is implemented then
> > applications must do what the text says. But as
> > RFC1122 is not really specifying what applications should or must do.,
> > these musts or should are not  capitalized.
>
> - right.
>
>
> > But I should assume that we could get the people working with
> > RFC793bis in tcpm provide the "right" interpretation ?!
>
> Nah I think this is clear enough already. I'll drop PUSH from SEND.
>
>
> >>> 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.
> >>
> >> Yes, it's certainly implementation-dependent. The idea of PUSH is
> >> that,
> > when
> >> not using it, the receiving process doesn't need to be woken up every
> > time a
> >> new handful of bytes arrive.
> >>
> > [Karen Elisabeth Egede Nielsen] Yes and certainly, as many TCP
> > implementations simply always sets the PUSH flag following the MUST of
> > rfc1122, section 4.2.2.2,
> >
> > then the PUSH flag ends up being set on a lot of segments just because
> > the application is writing in small chunks....
> >
> > Or even worse - the PUSH flag  it is lost when the SEND buffer gets
> > congested, which is terribly when the receiving side read operation
> > has implemented trust on the PUSH for being waken up. This actually is
> > something that we have seen resulting in outages (signaling network
> > collapse)  even recently.
> >
> >
> >>
> >>> 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.
> >>
> >> It's a mechanism of TCP, it's described in the spec, and it comes
> >> with
> > some
> >> SHOULD's and MAY's. I think one can create a very efficient TCP
> >> implementation that completely ignores PUSH,
> > but, depending on your
> >> system, it can also be helpful.
> > [Karen Elisabeth Egede Nielsen] Perhaps - but it can also be very
> > harmful to put trust in the PUSH flag, if the two ends to not agree on
> > what controls it - the ULP or the TCP SND buffer congestion level...
> >
> > Based on my analysis above, I thought it makes
> >> sense to assume that at least the sender can set it  (I think it's
> >> not
> > explicit in
> >> today's APIs but implicit... I did take a look (just out of
> >> curiosity,
> > not breaking
> >> my own rules when writing the document!  ;-)  ) and I think I found
> >> it
> > in the
> >> BSD API or in some older version thereof).
> >>
> > [Karen Elisabeth Egede Nielsen] But the implicit is what gets us into
> > the confusion !
> > How is it implicitly implemented in API  implementations ?
> >
> > (Despite that rfc1122 say that it need not be).
>
> ... we agree already.
>
>
>
> >> See, that's the point of trying to rely only on RFCs: we end up with
> >> a
> > view of
> >> what really should be implemented by the APIs out there. If it isn't,
> > well,
> >> that's bad, but then it's really a breach of the spec.
> >>
> > [Karen Elisabeth Egede Nielsen] In this case then I am afraid that it
> > is the spec that allowed the implementations to distroy the functions
> > as it (rfc793 to rfc1122) has given some freedom in implementations.
> > The uncertainty of which has made the function unreliable/not
> trustworthy.
> > (Or perhaps the function was never a good idea to begin with..)
>
> - which I why I want to drop parts of the protocol implementation that
are
> not at least qualified as SHOULD.
>
>
> >> 2)  SCTP:
> >> --------------
> >>
> >>
> >>>>> 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.
> >>
> >> I agree, I don't care much about the call format
> >>
> >>
> >>> 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).
> >>
> >>
> >> Hm, this is about the only piece from RFC 6458 that I did cite in
> > draft-welzl-
> >> taps-transports, just as a comment, because I found it disturbingly
> >> incoherent that TCP provides this but it's missing in RFC 4960:
> >>
> >> ***
> >>   o  Change DSCP
> >>      Protocols: TCP
> >>      Comments: This is described to be changeable for SCTP too in
> >>      [RFC6458].
> >> ***
> >>
> >> In RFC 6458, "uint8_t  spp_dscp;" is a part of the per-adress
> > parameters,
> >> struct sctp_paddrparams.
> >>
> >>
> > [Karen Elisabeth Egede Nielsen] Great. I missed it yesterday. Couldn't
> > understand it either.
> > Perhaps I can blame the jetlag...
> >
> >>> So my view
> >>> on the basic API functions of SCTP (as for TCP) is influenced by
this.
> >>> Which I have to recognize.
> >>
> >> Hm. This statement makes me feel a bit uneasy...
> >>
> >
> > [Karen Elisabeth Egede Nielsen] Yes. :-(.
> >
> >>
> >> So, if we have consensus that RFC 6458 reflects the services (not
> > necessarily
> >> the precise call format) that are supposed to be provided by any SCTP
> >> implementation, I'm happy to include it. Let's hear some more voices
> >> perhaps...
> >>
> > [Karen Elisabeth Egede Nielsen] Yes definitively.
>
>
> Cheers,
> Michael