Subject: Re: [IPFIX] SCTP per-stream WGLC review

From: Benoit Claise <[email-masked]>
Date: Thu, 16 Oct 2008 12:51:35 +0200

Brian,

Many thanks! Not only you got some good points, but you even proposed 
some new text. This is the perfect review.
See inline.
> All,
>
> The following is a review of the SCTP perstream draft for WGLC.
>
> Serious issues (repeated inline):
>
> It is not clear in the language of the document that it is not  
> intended to update 5101, though its intended status precludes this.  
>   
At the beginning of section 4, there is this proposed text:

This section introduces improvements compared to the IPFIX 
specifications in [RFC5101].  These new specifications, which are more 
specific compared to [RFC5101], are descried with the key words 
described in [RFC2119 <http://tools.ietf.org/html/rfc2119>].

> Additionally, there are some specifications with respect to Collecting  
> Processes which may break interoperability.
>
> The Data Record Reliability Options Template does not appear to be  
> necessary, or at least, its purpose is unclear. As I read it the CP  
> can deduce all the information it provides rather easily.
>
> General comments:
>
> I have not consistently corrected the grammar in the document where it  
> does not have a significant impact on clarity (e.g. spurious  
> articles), though the document does need a grammar and typographic  
> editing pass between now and final publication.
>   
Surely one of the native English speakers in the author list will do a 
final check

> There is one general terminology issue which should be addressed; it  
> appears that throughout the document the phrase "Template ID" is used  
> to mean "number identifying a Template" as well as "Data Records (or  
> Data Sets) described by (or associated with) a Template". I agree this  
> latter construct is really awkward, but "Template ID" is a confusing  
> shorthand for the concept, and suggest finding a replacement and using  
> it consistently.
>   
I reviewed all "template" instances in the document, and I agree with 
your statement.
I changed a few sentences.
>   
>>  1. Terminology
>>
>>         IPFIX-specific terminology used in this document is defined
>>         in section 2 of [RFC5101].  As in [RFC5101], these IPFIX-
>>         specific terms have the first letter of a word capitalized
>>         when used in this document.
>>
>>         Template Reuse Delay
>>
>>            The configurable timeout to allow the Collecting Process
>>            to receive and process the last Data Record using this
>>            Template information before which the Template Withdrawal
>>            Message MUST NOT be sent.  [RFC5101] specifies a default
>>            value of 5 seconds.
>>     
>
> The wording here is confusing. I don't know what a Template Reuse  
> Delay is from this text. Is this correct:
>
> "The time after sending the last Data Set described by a given  
> Template the Exporting Process MUST wait before sending a Template  
> Withdrawal Message for the Template."
>   
This is a better wording, you're right.

Alternatively, I can simply cut and paste the sentence from RFC5101

   According to the IPFIX specifications [RFC5101], the Template 
   Withdrawal Message MUST NOT be sent until sufficient
   time has elapsed to allow the Collecting Process to receive and
   process the last Data Record using this Template information.  This
   configurable time is called the Template Reuse Delay.  [RFC5101] 
   specifies a default value of 5 seconds.

Which one do you prefer?
> It's not a CP delay, or is it? I'm confused as to what configurability  
> at the CP has to do with it.
>   
>   
>>      2. Introduction
>>
>>         The IPFIX working group has specified a protocol to export IP
>>         Flow information [RFC5101].  This protocol is designed to
>>         export information about IP traffic Flows and related
>>         measurement data, where a Flow is defined by a set of key
>>         attributes (e.g. source and destination IP address, source
>>         and destination port, etc.).  However, thanks to its template
>>         mechanism, the IPFIX protocol can export any type of
>>         information, as long as the relevant Information Element is
>>         specified in the IPFIX Information Model [RFC5102],
>>         registered with IANA, or specified as an enterprise-specific
>>         Information Element.
>>
>>         The IPFIX protocol [RFC5101] specifies that IP traffic
>>         measurements for Flows are exported using a TLV (type,
>>         length, value) format.  The information is exported using a
>>         Template Record that is sent once to export the {type,
>>         length} pairs that define the data format for the Information
>>         Elements in a Flow.  The Data Records specify values for each
>>         Flow.
>>
>>         The IPFIX protocol [RFC5101] is flexible: it foresees the  
>> usage
>>         of the multiple SCTP streams per association; it allows the
>>         transmission of Data Sets, Template Sets, and/or Options
>>         Template Sets on any stream; it offers the full or partial
>>         reliability export of Data Sets; it proposes the ordered or  
>> out-
>>         of-order delivery of Data Sets.  However, due to bandwidth
>>
>>
>>      <Claise, et. Al>       Expires January 1, 2009           [Page 5]
>>
>>      Internet-Draft      <IPFIX Export per SCTP Stream>       July  
>> 2008
>>
>>
>>         restrictions and packet losses in the network as well as
>>         resource constraints on the Exporter and Collector (e.g.,
>>         limited buffer sizes), it is not always possible to export all
>>         Data Sets in a reliable way.
>>
>>     
>
> I'm going to make a few stylistic suggestions here in the  
> introduction, because the introduction, I think, needs to be very  
> clear as to what the document is, and it reads a little awkwardly to  
> me as it stands.
>
>   
>>         Without delving into the details of the specifications  
>> described
>>         later on in this document, the basic idea is to export the
>>         Template Record and its associated Data Sets into a single
>>         unique SCTP stream, ideally to limit the Template ID to a  
>> single
>>         stream, while imposing in-order transmission.
>>     
>
> Introductory construct is a little unclear. Suggest replacement of  
> this paragraph with:
>
> This document specifies a method for exporting a Template Record and  
> its associated Data Sets in a single SCTP stream, limiting each  
> Template ID to a single stream if possible, and imposing in-order  
> transmission.
>   
That reads a lot better. Done.
>   
>>         The specification in this document offers several advantages
>>         such as: calculation of Data Record losses in case of  
>> partially-
>>         reliable SCTP export, immediate export of the Template
>>         Withdrawal Message, immediate reuse of template ID within a
>>         stream, reduced likelihood of losing Data Record, and the
>>         Collecting Process's job is easier.
>>     
>
> Text is not parallel; there are typographic errors here as well.  
> Suggest replacement of this paragraph with:
>
> This method offers several advantages over IPFIX export as specified  
> in [RFC5101] such as the ability to calculate Data Record losses for  
> PR-SCTP, immediate export of Template Withdrawal Messages, immediate  
> reuse of Template IDs within an SCTP stream, reduced likelihood of  
> Data Record loss, and reduced demands on the Collecting Process.
>
>   
Good proposal. Done.
I've also updated the abstract to be in line with this paragraph.
>>        2.1. Relationship with IPFIX and PSAMP
>>
>>         The specification in this document applies to the IPFIX
>>         protocol specifications [RFC5101].  However, it only applies
>>         to the SCTP transport protocol [RFC4960] option of the IPFIX
>>         protocol specifications, specifically in the case of the
>>         partial reliability extension [RFC3758].  All specifications
>>         from [RFC5101] apply unless specified otherwise in this
>>         document.
>>
>>         As the Packet Sampling (PSAMP) protocol specifications
>>         [PSAMP-PROTO] are based on the IPFIX protocol specifications,
>>         the specifications in this document are also valid for the
>>         PSAMP protocol.  Therefore, the advantages specified by this
>>         document also apply to PSAMP.
>>     
>
> The document specifies a method, not a set of advantages; suggest  
> "Therefore, the method..."
>   
Done.
>>      2.2. Applicability
>>
>>         The specifications are required in cases where we must know  
>> how
>>         many Data Records of a certain type (i.e. from a certain
>>         Template ID) were lost.  Furthermore, they apply in cases  
>> where
>>         the Exporter can not afford to export all the Flow Records
>>         reliably, due to the limited resources to buffer the huge  
>> amount
>>         of flow records.  Such situations may occur if Data Sets are
>>         generated at a higher rate at the Exporter than can be
>>         transferred to the Collector because of bandwidth  
>> limitations in
>>
>>
>>      <Claise, et. Al>       Expires January 1, 2009           [Page 6]
>>
>>      Internet-Draft      <IPFIX Export per SCTP Stream>       July  
>> 2008
>>
>>
>>         the network or slow reception at the Collector.  A typically
>>         example is a router exporting billing records.
>>     
>
> typical example
>   
Done.
>   
>>         To be more precise, the specification applicability is the  
>> case
>>         where multiple Template IDs are sent within a SCTP Transport
>>         Session and the calculation of the Data Record loss for a
>>         particular one Template ID is required.  Indeed, with the
>>         current IPFIX specifications [RFC5101], if an IPFIX Message is
>>         lost (UDP or SCTP partially reliable), it is not possible to
>>         determine to which Template ID of the Transport Session the  
>> lost
>>         Data Records belong to.
>>     
>
> Not in the general case, no. An EP can of course use only a single  
> template for all export in a given session, or use a separate  
> observation domain for each application. This is not the _only_ way  
> under the current spec to estimate loss, it's just the most SCTP  
> friendly, and the least hackish.
>   
Understood. To stress the point, I changed "within a SCTP Transport 
Session" into "within a _single _SCTP Transport Session"
I also added the following sentence as a new paragraph at the end of the 
section 3.1.1 (I think it's more appropriate there): "Note that a 
workaround allowed by the IPFIX specifications [RFC5101] is to use only 
one Template per SCTP Transport Session, at the cost of multiplying the 
number of SCTP Transport Sessions when multiple Template are required."

I propose not to mention the option of separate observation domain as 
this hack will certainly lead to some more confusion.

>   
>>         In terms of Collector, there is backwards compatibility: the
>>         Collecting Process does not require any changes to support an
>>         Exporter that complies to the specifications in this document.
>>     
>
> Suggest:
>
> Exporting Processes following this specification will interoperate  
> with existing Collecting Processes that comply with [RFC5101]; no  
> changes are required at the Collecting Process to support this method.
>   
Done.
>   
>>      2.3. Limitations
>>
>>         To be compliant with the specifications in this document, the
>>         Transport Session must support multiple SCTP streams.
>>         Furthermore, if the SCTP Transport Session does not support
>>         enough streams for the increasing number of Template ID in the
>>         Transport Session, the addition of streams must be supported
>>         according to [SCTP-RESET].  Alternatively, the new Template ID
>>         and associated Data Records may be added to an existing stream
>>         at the cost of diluting the granularity of Data Records loss.
>>         The other alternatives, which is not practical in operational
>>         networks, is to restart the SCTP association with an increase
>>         number of streams.
>>     
>
> A few unclear and nonstandard constructs here, and a little  
> terminology confusion. The discussion of alternatives to one-session- 
> per-stream and SCTP reset is not a limitation of the approach, it's a  
> workaround to limitations in certain SCTP stacks, and is a bit  
> detailed for an introduction I think.  Suggest replacement:
>
> This method requires multiple SCTP streams in the association between  
> the Exporting and Collecting Process, ideally one per Template. The  
> SCTP association should support the addition of streams according to  
> [SCTP-RESET] in order to handle the transmission of additional  
> Templates during the Transport Session.
>   
Perfect.
>   
>>      3. IPFIX Protocol Specifications Limitations and Improvements
>>     
>
> I think this section needs some frontmatter explaining its  
> organization. From the point of view of the TOC it makes sense, but  
> reading the document through end to end it's a little disorienting.
>   
New proposal

    For three specific topics (Data Record Loss per Template,
    Transmission Order within a Stream, No Transmission Order across
    SCTP Streams), this section explains the IPFIX protocol
    specifications limitations on one hand, and the advantages of the
    method specified in this document on the other hand.

>   
>>      3.2.2. IPFIX Export per SCTP Stream Advantages
>>
>>         By exporting each Template Record and the corresponding Data
>>         Records within a single stream and imposing in-order
>>         transmission, the Template will always arrive before the
>>         associated Data Records.  Therefore, there is no risk that
>>         the Collecting Process discards Data Records while waiting
>>         for the Template to arrive.
>>
>>         Furthermore, when reusing a Template ID within a stream, the
>>         Template Withdrawal Message will be guaranteed to arrive
>>         before the new definition of the Template and therefore the
>>         Template Record may be sent directly after the Template
>>         Withdrawal Message.  In other words, the Template Reuse Delay
>>         restriction (by default, 5 seconds, as specified in [RFC5101]
>>         is removed for Template ID reuse within the same stream.
>>
>>         Another advantage with the new specifications in this
>>         document is that the Collecting Process's job is now easier.
>>         Indeed, the Collecting Process doesn't have to store the Data
>>         Records while waiting for the Template Records, as the
>>         transmission order is always guaranteed.  This way, extra
>>         reliability of the Data Records is achieved without extra
>>         burden on the Collecting Process.
>>     
>
> Prefer "reduces load on the CP" to "the CP's job is now easier"; the  
> latter reads quite informally for a specification.
>   
Done.
> It might be nice if there were some way for a full-featured CP (i.e.  
> one that supports buffering of Data Sets with missing Templates) to  
> know whether it had to preallocate buffers for such a thing, but this  
> is a very minor technical point.
>   
Since we must have the backwards compatible with other RFC 5101 CPs, I'm 
not sure if this possible.
>   
>>      3.3.2. IPFIX Export per SCTP Stream Advantages
>>
>>         By exporting each Template Record and the corresponding Data
>>         Records within a single stream, imposing in-order
>>         transmission, and limiting the Template ID to a single
>>         stream, the issue of ordered transmission across multiple
>>         streams is avoided.
>>
>>         By exporting all corresponding Data Records within the same
>>         ordered stream as the Template Definition, each stream is
>>         independent and self-contained and the interaction between
>>         streams is limited to that of Options Data interactions.  This
>>         has several advantageous consequences, including the order
>>         preservation that does not result in the blocking of unrelated
>>         data and the Collector's job simplification (as the Template
>>         Records are guaranteed to be delivered before the associated
>>         Data Records).
>>     
>
> see previous comments about the "collector's job" language.
>   
New text:
This has several advantageous consequences, including the order 
preservation that does not result in the blocking of unrelated data and 
load reduction on the Collecting Process (as the Template Records are 
guaranteed to be delivered before the associated Data Records, there is 
no need for buffering of Data Sets with missing Templates).
>   
>>      4. Specifications
>>
>>      4.1. Template Management
>>
>>         This section introduces modifications compared to the Template
>>         Management section 8 in [RFC5101].
>>
>>
>>      <Claise, et. Al>       Expires January 1, 2009          [Page 10]
>>
>>      Internet-Draft      <IPFIX Export per SCTP Stream>       July  
>> 2008
>>
>>
>>
>>         As specified in [RFC5101], Template Sets and Options Template
>>         Sets MUST be sent reliably.  In other words, any IPFIX Message
>>         containing an (Options) Template Set MUST be sent reliably.
>>     
>
> Verify that all 2119 keywords drawn from 5101 actually do restate the  
> point properly; as I recall there was a bit of trouble over this with  
> the implementation guidelines.
>   
When I wrote "As specified in [RFC5101]", I always cut and pasted the 
exact sentence(s) from RFC5101.
If there is something specific to this draft, I would start a new paragraph

>   
>>         Any Data Sets associated with a Template Record MUST be sent  
>> on
>>         the same stream on which the Template Record was sent.
>>     
>
> The use of 2119 MUST language here implies a mandatory modification to  
> 5101. I know this is not the case given the document's intended  
> status, but perhaps there should be some frontmatter in section four  
> scoping the 2119 keywords within this section to implementations of  
> the specification only.
>   
Proposed new text in section 4

    This section introduces improvements compared to the IPFIX
    specifications in [RFC5101].  These new specifications, which are
    more specific compared to [RFC5101], are descried with the key words
    described in [RFC2119 <http://tools.ietf.org/html/rfc2119>].

>   
>>         The Exporter SHOULD send a single Template and associated Data
>>         Sets within a single stream in order to calculate the  
>> potential
>>         Data Record loss for this Template ID.
>>     
>
> in order to _enable_ calculation (it's the collector doing the loss  
> calculation, right, not the exporter?)
>   
Done.
>   
>>  However, the Exporter
>>         MAY group related Templates and their associated Data Sets
>>         within a single stream so loss statistics are calculated for  
>> the
>>         group.  This may be suitable in cases where there is
>>         insufficient SCTP streams to send each Template on its own
>>         stream and/or the case where there are slight variations on a
>>         single Template to show that some fields were unavailable at  
>> the
>>         time of monitoring.
>>     
>
> This last sentence is kind of confusing. What I think you mean is:
>
> This is suitable in cases where there are only slight variations among  
> the templates in a group, e.g. the omission of unavailable fields for  
> export efficiency, and may be necessary if the SCTP association does  
> not support enough streams to export each Template in its own stream.
>   
Nicely expressed. Done.
> Hmm... Actually, I think the specification would be greatly improved  
> by the formal introduction of a "template group" concept, and the  
> rephrasing of the specification to cover the export of one template  
> _group_ per stream. Since the omission of missing fields is not only  
> common practice but recommended by the documents, you're often likely  
> to get a set of related templates. Exporting these as a group is I  
> think what you're really trying to do with this document, since it's  
> application-granularity loss you're trying to estimate, yes?
>   
Actually, we're saying: _always _export one template per SCTP stream, 
except in some circumstances:
- you don't care about the loss calculation
- you want to export within the same stream the option template record 
that will help the data record interpretation (example: sampling rate)
- you don't have enough SCTP stream. If this is the case, use "template 
group"

>   
>>         If a SCTP stream contains a mixture of Data Records defined  
>> by a
>>         Template Record and Options Template Record(s), the Data  
>> Records
>>         defined by the Options Template Record(s) SHOULD be sent
>>         reliably within the same stream so that the Collector does not
>>         consider any loss to be associated with the Options Data.
>>         Indeed, if the Collector does not have the guarantee that the
>>         Data Records defined by the Options Template Record are sent
>>         reliably, the Collector can not determine whether the loss in
>>         that stream belongs to the Data Records defined by the  
>> Template
>>         Record, defined by the Option Template Record, or by both of
>>         them.  By sending the Options Data reliably (which is usually
>>         required to interpret the Data Records correctly), any loss  
>> will
>>         be limited to the non-option Data Record and loss can still be
>>         calculated on a per Template basis.
>>
>>         For each (Options) Template Record, the Exporting Process MUST
>>         send the Data Record Reliability Option Template using an  
>> Option
>>         Template with the following Information Elements:
>>
>>          SCOPE:     Template ID
>>          NOT-SCOPE: dataRecordsReliability
>>
>>         The Data Record Reliability Option Template MUST be sent
>>         reliably.
>>
>>     
>
> It's a template, so it must be sent reliably. This is redundant. 
Yes. I removed it.
> Or do  
> you mean the record described by this template?
>
> More seriously, I don't see the point of this Option. Can't the CP  
> just deduce from the EP's actions whether it's sending the data for a  
> given template reliably or not? 
How?
Isn't it a layer violation if the Exporter looks in the SCTP transport 
to determine the reliability level?
Also, just because the Exporter sent some records reliably there is not 
a guaranteed indication of future intent, or more specifically an
indication that any lost records won't be associated with this Template ID.
> Also, what additional functionality  
> does the CP really gain by deducing this? Doesn't all the stream loss  
> estimation stuff still work (well, on a per-group basis, anyway)?
>   
If you're sending with the same SCTP stream, a mix of:
    flows record with sampled data and sampler ID
    option template describing the sampling rate asssociated with a 
specifier sampler ID
If  the CP sees a gap in the sequence number, and the CP doesn't know 
that the option data records (for a lack a better term) are sent 
reliably, what should be the CP deduce?
    1. I lost a flow record -> this is pretty bad from an accuracy point 
of view
    OR
    2. I lost an option data record -> I can't fully interpret my data.
This mechanism will help the CP to say that the loss comes only from 
data record, because the option data record were sent reliably.
I understand that this is a different "group" that what you described 
above, as in this case the group contains data records and associated 
option data records. Really the options data is considered information 
that supports the interpretation of the group data, but isn't part of 
the group.

>   
>>      <Claise, et. Al>       Expires January 1, 2009          [Page 11]
>>
>>      Internet-Draft      <IPFIX Export per SCTP Stream>       July  
>> 2008
>>
>>
>>         The Option Data Record SHOULD be sent before the Data Record
>>         that needs it so that it arrives first and is available for  
>> the
>>         Collector to use.
>>     
>
> And I presume it should also be sent reliably?
>   
Yes, added.
Note: the "Option Data Record" doesn't exist.
New text:

    The Data Record defined by the Data Record Reliability Option
    Template SHOULD be sent, reliably, before the Data Record that needs
    it so that it arrives first and is available for the Collector to use.

In some other instances of "Option Data Record", I changed the draft to 
use _o_ption Data Record
>   
>>      4.2. New Information Element
>>
>>         dataRecordsReliability
>>
>>            Description:
>>                 The Data Records reliability associated with this
>>                 Template ID.  The integer value 1 means that the Data
>>                 Records are sent reliably, while the integer value 2
>>                 means that the Data Records are not sent reliably.
>>            Abstract Data Type: boolean
>>            Data Type Semantics: identifier
>>            ElementId: xxx
>>            Status: current
>>     
>
> Inconsistent. Is it an integer, or a boolean?
>   
 >From RFC5101

            6.1.5. boolean

       The boolean data type is specified according to the TruthValue in
       [RFC2579 <http://tools.ietf.org/html/rfc2579>]: it is an integer with the value 1 for true and a value 2
       for false.  Every other value is undefined.  The boolean data type
       MUST be encoded in a single octet.

However, you're right, let's not confuse the information model with the 
encoding rule

New proposed text:
Description:
                The Data Records reliability associated with this
                Template ID.  The true value means that the Data
                Records are sent reliably, while the false value
                means that the Data Records are not sent reliably.

>   
>>      4.3. SCTP
>>
>>         This section introduces modifications compared to the "SCTP"
>>         section 10.2 (and subsections) in [RFC5101].  More  
>> specifically
>>         the "Stream" section 10.2.4.3
>>     
>
> See above about 2119 language and intended status. This frontmatter  
> clearly reads as if it supercedes or updates 5101, which is not the  
> case.
>   
This section introduces some more specific specifications compared to 
the "SCTP" section 10.2 (and subsections) in [RFC5101]. 
>   
>>         PR-SCTP [RFC3758] MUST be implemented by all compliant
>>         implementations.
>>
>>         All IPFIX Messages MUST be sent in order within a stream.
>>
>>         Depending on the application requirement, the Exporting  
>> Process
>>         MAY send Data Sets with full or partial reliability.   
>> Unreliable
>>         data transfer MAY be used where the application does not  
>> require
>>         reliable transmission or the use of a retransmission queue is
>>         impractical due to resource restrictions at the Exporter.
>>
>>
>>         If the Exporting Process requires to export a new Template but
>>         there are no more free SCTP streams available, it SHOULD  
>> attempt
>>         to increase the number of outbound streams it is able to send
>>         to, per [SCTP-RESET].  Alternatively, the Exporting Process  
>> MAY
>>         add the Template Set and Data Records to an existing stream at
>>         the cost of diluting the granularity of Data Records loss.
>>
>>
>>
>>
>>
>>      <Claise, et. Al>       Expires January 1, 2009          [Page 12]
>>
>>      Internet-Draft      <IPFIX Export per SCTP Stream>       July  
>> 2008
>>
>>
>>      4.4. Template Withdrawal Message
>>
>>         This section introduces Template Withdrawal Message-related
>>         modifications compared to the Template Management section 8 in
>>         [RFC5101].
>>     
>
> As above.
>
>   
>>         Templates that are not used anymore SHOULD be deleted.  Before
>>         reusing a Template ID, the Template MUST be deleted.  In order
>>         to delete an allocated Template, the Template is withdrawn
>>         through the use of a Template Withdrawal Message.  The  
>> Template
>>         Withdrawal Message MUST be sent on the same stream as the
>>         Template Record.
>>     
>
> Inconsistent terminology. Template deletion == withdrawal?
>
>   
The first two sentences are cut and pasted from RFC5101.
I added "as specified in [RFC5101] in front of them
>   
>>         As the Template Withdrawal Message MUST be sent reliably,  
>> using
>>         SCTP-ordered delivery per [RFC5101], and as all IPFIX Messages
>>         are sent in order within a stream (per the specifications in
>>         this document), the IPFIX Message containing the Template
>>         Withdrawal Message will not arrive at the Collecting Process
>>         before any associated and previously sent Data Record.  As a
>>         consequence, no Data Records will be lost due to delayed  
>> arrival
>>         at the Collector.
>>
>>         The Template ID from a withdrawn Template MAY be reused on the
>>         same stream immediately after the Template Withdrawal  
>> Message is
>>         sent.  This case is equivalent to the use of a Template Reuse
>>         Delay value of 0.
>>
>>         If the new definition of the Template ID is to be reused on a
>>         different stream, the Template Withdrawal Message MUST NOT be
>>         sent before the Template Reuse Delay.
>>
>>         A Template Withdrawal Message to withdraw all Templates for  
>> the
>>         Observation Domain ID specified in the IPFIX Message header  
>> MUST
>>         NOT be used.
>>
>>         Multiple Template IDs MAY be withdrawn with a single Template
>>         Withdrawal Message at the condition that all the Template  
>> IDs in
>>         the Template Withdrawal Message are used on the same SCTP
>>         stream.
>>
>>
>>      4.5. The Collecting Process's Side
>>
>>         This section introduces modifications to the Collection  
>> Process
>>         as compared to section 9 in [RFC5101].
>>     
>
> Modification of Collecting Process behavior is in conflict with the  
> statement in the introduction that EPs using this spec interoperate  
> with 5101 CPs. Which is it?
>   
New proposal.

This section introduces some more specific specifications to the 
Collection Process compared to section 9 in [RFC5101].  However, the new 
specifications are backwards compatible with RFC5101-compliant 
Collecting Processes.

>   
>>      <Claise, et. Al>       Expires January 1, 2009          [Page 13]
>>
>>      Internet-Draft      <IPFIX Export per SCTP Stream>       July  
>> 2008
>>
>>
>>         The Collecting Process SHOULD listen for a new association
>>         request from the Exporting Process.  The Exporting Process  
>> will
>>         request a number of streams to use for export: the number of
>>         streams SHOULD be equivalent to the number of simultaneous
>>         Template Records used in the association. Note that the  
>> Template
>>         Records don't include the Options Template Records.
>>     
>
> This statement does not modify 5101 CP behavior and is superfluous.
>   
It might not be obvious for new comers. So we thought about adding that. 
Anyway, removed.
>   
>>         A Collecting Process SHOULD support the procedure for the
>>         addition of an SCTP stream [SCTP-RESET].
>>
>>         The IPFIX protocol has a Sequence Number field in the IPFIX
>>         Message header that increases with the number of IPFIX Data
>>         Records in the IPFIX Message.  A Collector may detect out-of-
>>         sequence, dropped, or duplicate IPFIX Messages by tracking the
>>         Sequence Number.  As this Sequence Number is per SCTP stream,
>>         the loss for the Data Records sent in that stream can be
>>         calculated in case of partially-reliable export.
>>     
>
> A recommendation for how to do this calculation would be nice here.
>   
New proposal

  When one or more IPFIX Messages are considered lost, the number of lost
  Data Records is equal to the Sequence Number of the first IPFIX 
Message Header
  following the lost packets (S2) minus the Sequence Number of the
  first lost IPFIX Message (S1).  The Sequence Number of the first lost
  IPFIX Message can be calculated as the Sequence Number of the last
  IPFIX Message before the sequence of lost IPFIX Messages (S0) plus the 
number
  of Data Records in that IPFIX Message (N0).

    S1   = S0 + N0
    loss = S2 - S1 = S2 - (S0 + N0)
>   
>>         If the Collecting Process receives a Template Withdrawal  
>> Message
>>         on a different stream than the one on which the Template ID is
>>         used, then the Collecting Process MUST reset the association  
>> and
>>         SHOULD log an error message.
>>     
>
> This is not possible without superceding 5101 and breaking  
> interoperability with stock 5101 EPs. Therefore it must be removed.
>   
Good catch.
New text:

    If the Collecting Process receives a Template Withdrawal Message on
    a different stream than the one on which the Template ID is used,
    then the Collecting Process SHOULD log an error message.

> Furthermore (though I know we do it all over the protocol), CP- 
> initiated Transport Session shutdown does not follow the general  
> protocol design rule of "be conservative in what you send and liberal  
> in what you accept". Adding a new condition where we do this would be  
> less than ideal. But I accept that I lost this fight a while ago. :)
>   
Actually we have heard some very good arguments against Postel's robustness
principle. In 2001 Marshall Rose wrote:

    Counter-intuitively, Postel's robustness principle ("be conservative
    in what you send, liberal in what you accept") often leads to
    deployment problems. Why? When a new implementation is initially
    fielded, it is likely that it will encounter only a subset of existing
    implementations. If those implementations follow the robustness
    principle, then errors in the new implementation will likely go
    undetected. The new implementation then sees some, but not widespread
    deployment. This process repeats for several new implementations.
    Eventually, the not-quite-correct implementations run into other
    implementations that are less liberal than the initial set of
    implementations. The reader should be able to figure out what happens
    next.
>   
>>         The following sentences from [RFC5101] are not applicable in
>>         this specification:
>>
>>            "The Collecting Process normally receives Template Records
>>            from the Exporting Process before receiving Data Records.
>>            The Data Records are then decoded and stored by the
>>            Collector.  If the Template Records have not been  
>> received at
>>            the time Data Records are received, the Collecting Process
>>            MAY store the Data Records for a short period of time and
>>            decode them after the Template Records are received."
>>     
>
> No need to remove this. CPs may still support buffering of template- 
> less Data even if the EP doesn't require them to.
>   
Sentences removed.

Regards, Benoit.
> Regards,
>
> Brian
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix
>   

_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Benoit Claise <[email-masked]>
Date: Thu, 16 Oct 2008 12:51:35 +0200

Brian,

Which one do you prefer?
Good proposal. Done.
Done.
Done.

Done.
Perfect.
New proposal

Done.
New text:

Done.
Nicely expressed. Done.

Yes. I removed it.
How?

Yes, added.

            6.1.5. boolean

New proposed text:
Description:

New proposal.

New proposal

    S1   = S0 + N0
Good catch.
New text:

Sentences removed.

Regards, Benoit.