Subject: [ipfix-req] IPFIX Requirement draft status - section 6.3.2

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 30 Sep 2002 03:00:03 -0700

Hello, 

I'm looking to understand/really clarify this requirement. It seems
ambiguous...at least to me. I do not understand what is the meaning/purpose
of "-->abscence<-- of reliability....MUST be indicated". Shouldn't we just
rephrase that by just saying that the protocol MUST be reliable, provide
in-sequence delivery and retransmission? 

It seems to me we should have 2 options:

1. The IPfix protocol runs over TCP or SCTP
2. The ipfix protocol does not run over TCP or TCP but provide a service
equal or in excess to what is provided by TCP/SCTP in terms of reliability,
congestion awareness and in-sequence delivery.

Reading this text I feel there is a third option which is:

3. "the protocol should run over TCP or SCTP, but you can sidestep this
requirement by putting a sequence number on the application layer and/or
providing 'abscence' of reliability"...

Or maybe one should ask what's the definition of a reliable protocol as far
as the ipfix protocol is concerned...

"6.3.2.  Reliability

   Absence of reliability of the data transfer, for example caused by
   loss or reordering of packets containing flow information, MUST be
   indicated.

   Please note that if an unreliable transport protocol is used,
   reliability can be provided by higher layers. In such a case only
   lack of overall reliability MUST be indicated. For example reordering
   could be dealt with by adding a sequence number to each packet."

regards,

Reinaldo

---

From: "Peter Ludemann" <[email-masked]>
Date: Mon, 30 Sep 2002 10:56:27 -0700

IPFIX Requirement draft status - section 6.3.2Here's another situation: the
connection is broken for an extended period (or if there are very slow ACKs)
and internal queues fill up on the exporting device. One way to indicate
absence of reliability is by detecting a gap in the sequence numbers at the
collector when the connection is reestablished. (Is there any other
solution?) And if the exporter were to reboot in the interim, what then?
  CRANE's solution to this is to use a combination of exporter "boot time"
and sequence number -- the primary reason is not for detecting data loss due
to queue overflow, but for deduplication on fail-over. However, it is not
clear how to handle the case of a restart of the exporter, if it changes
boot time or forces a new initial sequence number. The exporter may output a
separate stream of data (over the same or another connection) which contains
status information, such as records lost due to queue overflow; but this is
not mandated by the CRANE protocol. The information might also be provided
on demand by CRANE's "STATUS REQUEST".
- peter
  -----Original Message-----
  From: majordomo listserver [mailto:[email-masked]]On Behalf
Of Reinaldo Penno
  Sent: Monday, September 30, 2002 3:00 AM
  To: req
  Cc: [email-masked]
  Subject: [ipfix-req] IPFIX Requirement draft status - section 6.3.2

  Hello,

  Or maybe one should ask what's the definition of a reliable protocol as
far as the ipfix protocol is concerned...

  "6.3.2.  Reliability

  regards,

  Reinaldo