Subject: [IPFIX] UDP Sequence Numbers rfc 5101

From: "Steve Nash" <[email-masked]>
Date: Thu, 21 Mar 2013 11:45:55 -0000

Please consider the wording of the paragraph on Sequence Numbers in Section
3.1.

      Incremental sequence counter modulo 2^32 of all IPFIX Data Records

      sent in the current stream from the current Observation Domain by

      the Exporting Process. Each SCTP Stream counts sequence numbers

      separately, while all messages in a TCP connection or UDP

      transport session are considered to be part of the same stream.

The phrase I have put in italics is depended on Transport protocol.

Section 10.3.2 Reliability says:

In the case of UDP, the IPFIX Sequence Number contains the

total number of IPFIX Data Records sent for the UDP Transport Session

prior to the receipt of this IPFIX Message

This is NOT dependent on the ObservationDomain.  Nothing prohibits the
Exporting Process from using the same Transport Session for multiple
Observation Domains.  But in UDP the Sequence number is for the Transport
session, whereas in TCP and SCTP each Observation Domain has an independent
sequence on the same  (and on each) Transport Session.

The term 'Stream' seems to take different meanings in IPFIX, depending on
the transport protocol.

This is not consistent with IPFIX being  "Transport protocol independent "
(Section 10 first para).

Regards

Steve Nash

[email-masked]

UK

  _____

---

From: Brian Trammell <[email-masked]>
Date: Mon, 25 Mar 2013 13:32:25 +1300

Hi, Steve,

This is an error in RFC 5101; the intent of the Sequence Number is that it be Observation Domain (and in the case of SCTP, Stream) scoped (i.e., you are correct that transport independence, to the extent possible, is the intent). The language in the present revision of 5101bis still contains the same error. Thanks for the catch!

I would suggest we fix this by replacing the paragraph in question as follows:

OLD:

   The Collecting Process SHOULD deduce the loss and reordering of IPFIX
   Data Records by looking at the discontinuities in the IPFIX Sequence
   Number.  In the case of UDP, the IPFIX Sequence Number contains the
   total number of IPFIX Data Records sent for the UDP Transport Session
   prior to the receipt of this IPFIX Message, modulo 2^32.  A Collector
   SHOULD detect out-of-sequence, dropped, or duplicate IPFIX Messages
   by tracking the Sequence Number. 

NEW:

   The Collecting Process SHOULD deduce the loss and reordering of IPFIX
   Data Records by looking at the discontinuities in the IPFIX Sequence
   Number.  In the case of UDP, the IPFIX Sequence Number contains the
   total number of IPFIX Data Records sent for the Observation Domain in the
   current UDP Transport Session prior to the receipt of this IPFIX Message, 
   modulo 2^32.  A Collector SHOULD detect out-of-sequence, dropped, or 
   duplicate IPFIX Messages by tracking the Sequence Number. 

The document is presently in Publication Requested state, so I think this should be placed as an RFC editor note on the document. WG: any comments thereon?

Best regards,

Brian

On 22 Mar 2013, at 0:45, Steve Nash <[email-masked]> wrote:

> Please consider the wording of the paragraph on Sequence Numbers in Section 3.1.
> This is NOT dependent on the ObservationDomain.  Nothing prohibits the Exporting Process from using the same Transport Session for multiple Observation Domains.  But in UDP the Sequence number is for the Transport session, whereas in TCP and SCTP each Observation Domain has an independent sequence on the same  (and on each) Transport Session.
>  
> The term ‘Stream’ seems to take different meanings in IPFIX, depending on the transport protocol.
> This is not consistent with IPFIX being  “Transport protocol independent “ (Section 10 first para).
>  
> Regards
> Steve Nash
> [email-masked]
> UK
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Andrew Feren <[email-masked]>
Date: Mon, 25 Mar 2013 12:28:18 -0400

Hi Brian,

I'm OK with your text as an editor note.  That is how I always 
interpreted that section anyway.  However, if we are wordsmithing I have 
one other nit in this section.

The sequence number may not be "the total number of IPFIX Data Records 
sent for the UDP Transport Session prior to the receipt of this IPFIX 
Message" unless we assume in order (and instant ;) delivery.  Maybe 
transmission instead of receipt.

-Andrew

---

From: Brian Trammell <[email-masked]>
Date: Tue, 26 Mar 2013 07:29:25 +1300

On 26 Mar 2013, at 5:28, Andrew Feren <[email-masked]> wrote:

> Hi Brian,
> 
> I'm OK with your text as an editor note.  That is how I always interpreted that section anyway.  However, if we are wordsmithing I have one other nit in this section.
> 
> The sequence number may not be "the total number of IPFIX Data Records sent for the UDP Transport Session prior to the receipt of this IPFIX Message" unless we assume in order (and instant ;) delivery.  Maybe transmission instead of receipt.

Hi, Andrew,

Excellent point. So now we have:

NEW:

   current UDP Transport Session prior to the transmission of this IPFIX Message,

Thanks,

Brian