Yes we agree ! :-) . Glad that ended here. Thanks a lot for the patience. BR, Karen
> -----Original Message----- > From: Michael Welzl [mailto:[email protected]] > Sent: 4. november 2015 21:39 > To: Karen Elisabeth Egede Nielsen <[email protected]> > Cc: <[email protected]> Fairhurst <[email protected]>; > [email protected] > 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 _______________________________________________ Taps mailing list [email protected] https://www.ietf.org/mailman/listinfo/taps
