Subject: RE: [ipfix-req] proposed changes for requirements document

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Wed, 22 Jan 2003 19:08:49 -0800

Hi,

  I'd agree with Tal, that without any Ack from the Collector,
the exporter is going to be hard pressed to identify what 
needs to be retransmitted.  And that any buffering done by
the exporter will be suboptimal, since there is no knowledge
about whether the flow has been delivered or not.

  I tried to be careful in my initial list of events which
impact the reliability.  In the modified list, one thing
I don't see is any mention of maintenance (i.e. graceful
"failover").  Could this be added as number 5 to your list:

  5. The Collector is taken down for maintenance or other
     administrative purposes.

Regards,

  Jeff Meyer

> -----Original Message-----
> From: Tal Givoly [mailto:[email-masked]]
> Sent: Wednesday, January 22, 2003 3:42 PM
> To: Juergen Quittek
> Cc: [email-masked]
> Subject: RE: [ipfix-req] proposed changes for requirements document
> 
> 
> Juergen,
> 
> Agreed with all with exception for a minor change I propose to item 4.
> 
> The problem with the current phrasing is that reliability 
> extension may not
> cover the most basic means for cost-effective deployments. 
> Therefore, I
> would like the following bullet added to the bullets 
> beginning with "-":
> 
> "   - an indication of acknowledgement from the collection 
> process to the
> exporting process, indicating to the exporting process that 
> it may discard
> flow information records that have been received at the 
> collection process."
> 
> I believe that by mandating the protocol be at least 
> extensible enough to
> support this, we can achieve the desired level of reliability 
> and permit for
> cost-effective deployments (less than 1-1 redundancy). This 
> is one of the
> least implementation-dependent ways to phrase this item. It 
> is implemented
> in slightly different ways in a large variety of protocols 
> today, DIAMETER,
> GTP', RADIUS, CRANE, and Streaming IPDR to name but a few. It 
> crystalizes
> what extension would be required to afford the right level of 
> applicability
> to the protocol.
> 
> Best regards,
> 
> Tal
> 
> -----Original Message-----
> From: majordomo listserver 
> [mailto:[email-masked]]On Behalf
> Of Juergen Quittek
> Sent: Wednesday, January 22, 2003 3:07 PM
> To: [email-masked]
> Subject: Re: [ipfix-req] proposed changes for requirements document
> 
> 
> Dear all,
> 
> After receiving input from Tal and Jeff, Benoit and I modified the
> proposal for changing the requirements draft. Again I am asking:
> Can we agree on this?
> 
>     Juergen
> 
> 
> 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3:
>    "RTP header fields" by "RTP header fields [RFC1889]"
> 
> 2. Append to Section "2.1. IP Traffic Flow":
>    "Also, please note that although packet properties may depend on
>     application headers, there is no requirement defined in 
> this document
>     related to applicaton headers."
> 
> 3. Move in section 6.1 "Information Model" item "7. if protocol
>    type is ICMP: ICMP type and code" from the list of MUST
>    attributes to the list of SHOULD attributes. Now it is item 17.
> 
> 4. Replace the entire section "6.3.2. Reliability" by
>    "Loss of flow records during the data transfer from the exporting
>     process to the collecting process MUST be indicated at the
>     collecting process. This indication MUST allow the collecting
>     process to gauge the number of flow records lost. Possible reasons
>     for flow records loss include but is not limited to:
> 
>     1. Metering process limitations: lack of memory, 
> processing power, etc.
>        These limitations are already covered in section 5.1.
>     2. Exporting process limitations: lack of memory, 
> processing power, etc.
>     3. Data transfer problems: packets that carry flow 
> records sent from
>        the exporting process to the collecting process, are 
> dropped by the
>        network. Examples are connection failures, congestions 
> in combination
>        with an unreliable transport protocol, etc.
>     4. Collecting process limitations: it may be experiencing 
> congestion
>        and not able to buffer new flows records."
> 
>     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.
> 
>     The data transfer between exporting process and 
> collecting process MUST
>     be open to reliability extensions including at least
>        - retransmission of lost flow records,
>        - detection of disconnection and fail-over, and
>     This extensibility MAY be used to provide additional reliability."
> 
> 5. Add to References:
>    "[RFC1889]   H. Schulzrinne, S. Casner, R. Frederick, V. 
> Jacobson, "RTP:
>                 A Transport Protocol for Real-Time 
> Applications", RFC 1889,
>                 January 1996."
> 
> 
> -- Juergen Quittek wrote on 03 January 2003 17:11 +0100:
> 
> > Dear all,
> >
> > Here is a list of suggestions for changes to the 
> requirements document.
> > They are based on our discussion in Atlanta and on a 
> comment by Benoit.
> >
> > I would like to achieve rough consensus on this list of changes
> > in order to enter working group last call for the 
> requirements document.
> >
> >     Juergen
> >
> >
> > 1. Replace in Section "2.1. IP Traffic Flow" in item 1., line 3:
> >
> >    "RTP header fields" by "RTP header fields [RFC1889]"
> >
> > 2. Append to Section "2.1. IP Traffic Flow":
> >
> >    "Also, please note that although packet properties may depend on
> >     application headers, there is no requirement defined in 
> this document
> >     related to applicaton headers."
> >
> > 3. Move in section 6.1 "Information Model" item "7. if protocol
> >    type is ICMP: ICMP type and code" from the list of MUST
> >    attributes to the list of SHOULD attributes. Now it is item 17.
> >
> > 4. Replace the first paragraph in section "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."
> >
> >    by
> >
> >    "Different levels of reliability of the data transfer MAY be
> >     supported. The collecting process MUST have sufficient 
> information
> >     for making a conservative assumption about the applied 
> reliability
> >     level. This means that the applied level of reliability 
> MUST be as
> >     high as or higher than indicated to the collecting process."
> >
> > 5. Add new paragraph after second paragraph in section "6.3.2":
> >
> >    "The chosen method of data transfer MUST be extensible concerning
> >     reliability. It MUST be possible to increase reliability by
> >     extensions."
> >
> > 6. Add to References:
> >
> >    "[RFC1889]   H. Schulzrinne, S. Casner, R. Frederick, V. 
> Jacobson,
> "RTP:
> >                 A Transport Protocol for Real-Time 
> Applications", RFC
> 1889,
> >                 January 1996."
> >
> >
> > --
> > Help        mailto:[email-masked] and say 
> "help" in message
> body
> > Unsubscribe mailto:[email-masked] and say
> > "unsubscribe ipfix" in message body
> > Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 
> 
> --
> Help        mailto:[email-masked] and say "help" 
> in message
> body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 
> 
> --
> Help        mailto:[email-masked] and say "help" 
> in message body
> Unsubscribe mailto:[email-masked] and say
> "unsubscribe ipfix" in message body
> Archive     http://ipfix.doit.wisc.edu/archive/
> 

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 23 Jan 2003 09:48:13 +0100

Jeff,

>   5. The Collector is taken down for maintenance or other

Got your point. I support your proposal.

    Juergen