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

Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com> Wed, 04 November 2015 14:09 UTC

Return-Path: <karen.nielsen@tieto.com>
X-Original-To: taps@ietfa.amsl.com
Delivered-To: taps@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC79A1B3008 for <taps@ietfa.amsl.com>; Wed, 4 Nov 2015 06:09:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tL4pmX-xAkm1 for <taps@ietfa.amsl.com>; Wed, 4 Nov 2015 06:09:55 -0800 (PST)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60DEF1B3006 for <taps@ietf.org>; Wed, 4 Nov 2015 06:09:55 -0800 (PST)
Received: by iody8 with SMTP id y8so54266134iod.1 for <taps@ietf.org>; Wed, 04 Nov 2015 06:09:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tieto.com; s=google; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc:content-type; bh=rtTfmjwqk9btwQ6aos29jCcBhyFWLjMsZukBEWnO1r8=; b=kz8uSKCjWPO3pXZxYv+/oUbMSyO6Q/G51TwNqtQNyrFT7Ds5Q3pQVcDtBnLo+gB35m 6lJ3l28ztvxNP0M9Ben0iu7ipoqHhGcq1/Kw6eWRnl56lYajPR3NKpCmbLYpwLhfRwXZ Ll0KWfF+dGntn8l1fMJSUAvTOyubbNtkdLG7k=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc:content-type; bh=rtTfmjwqk9btwQ6aos29jCcBhyFWLjMsZukBEWnO1r8=; b=PgzvoPL9w0A7wwGI5USONT4ZVkFwXQRoZtz0r+k2Ps3stMWYlHsxYOMYCh+F1OmEkc /IQ/qiU0SGNwiz+D0tVRa5xBUQCigRMhpS6fTE9iHThpbxuP5rFhcnvqcs6bYk4yU1H6 38RBJYhGtfmebz7ch3OzejKYWc5S2nMxXLestd40UN914k/CU78geix5BiJnM6FzgFjX 6XN0hBrjh1r7iwLJeHeCTpyLY4nXXhD1KJKUt/KmnrqLE650wqcVDzgobHA9fLWWWkKh JrKRRoajl9+rxsVjAsANGiwU2v9a//YPyJD3tdbJuDJ2LhAfalywDPkV8r5wVzZ4b7ze ozYg==
X-Gm-Message-State: ALoCoQm0csPg4ExmyllnsOr9BHILw2JLwegC57qlnRSQc2sTQKCqM2BjwrRgs7RZtsE7TW4D3GdPPnAFOza08nwcGTmdIifniLVVUYehKG9t+LxLyWWyRyw=
X-Received: by 10.107.10.217 with SMTP id 86mr3195124iok.145.1446646194618; Wed, 04 Nov 2015 06:09:54 -0800 (PST)
From: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
References: <945E755A-3EB4-4325-8257-9ECC2EE3FC4B@ifi.uio.no> <6f6d07994fde18062e39ced796f199a9.squirrel@erg.abdn.ac.uk> <168e06db09417654f64461f700a0d4f5@mail.gmail.com> <2B7D70A6-4675-40D0-AEE5-47D824A21A0A@ifi.uio.no> <675a044a04faf0c6f28f9f02416fbb84@mail.gmail.com> <88C880B9-4B26-44D6-A1BB-40C0FE377728@ifi.uio.no>
In-Reply-To: <88C880B9-4B26-44D6-A1BB-40C0FE377728@ifi.uio.no>
MIME-Version: 1.0
X-Mailer: Microsoft Outlook 15.0
Thread-Index: AQLqPZ7YNAMdgKXUwCSqRxv62pP6+wJmZ4dkAhiQoQkBo0RrLgHBFIkSAWlTB3GcDzQV4A==
Date: Wed, 4 Nov 2015 23:09:56 +0900
Message-ID: <cfe51395ee504bd562bd250d2e1c5d6a@mail.gmail.com>
To: Michael Welzl <michawe@ifi.uio.no>
Content-Type: text/plain; charset=UTF-8
X-DomainID: tieto.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/taps/cKAt-vizfLgkDBX7gAK7xZFryj4>
Cc: gorry@erg.abdn.ac.uk, taps@ietf.org
Subject: Re: [Taps] RFC 6458 etc. in draft-welzl-taps-transports
X-BeenThere: taps@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussions on Transport Services <taps.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/taps>, <mailto:taps-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/taps/>
List-Post: <mailto:taps@ietf.org>
List-Help: <mailto:taps-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/taps>, <mailto:taps-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2015 14:09:58 -0000

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

BR, Karen

> -----Original Message-----
> From: Michael Welzl [mailto:michawe@ifi.uio.no]
> Sent: 4. november 2015 21:39
> To: Karen Elisabeth Egede Nielsen <karen.nielsen@tieto.com>
> Cc: <gorry@erg.abdn.ac.uk> Fairhurst <gorry@erg.abdn.ac.uk>uk>;
> taps@ietf.org
> 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