Subject: Re: [IPFIX] WG Last Call for Implementation Guidelines

From: "Boschi, Elisa" <[email-masked]>
Date: Thu, 8 Mar 2007 16:45:49 -0000

Brian, all,

>
>
>I have a few comments for the guidelines:
>
>
>1. In Section 6.3, TCP Transport Specific Guidelines, para 4 states that
>TCP Collecting Processes SHOULD use the Sequence Number to check for
>missing IPFIX Messages.
>
>Wouldn't any condition that would cause missing messages cause a TCP
>connection reset? I have no problem with multi-transport implementations
>doing sequence number checks on TCP because they check sequence numbers
>regardless of protocol (indeed, due to layering between transport and
>message decode, our own implementation does precisely this) , but I'm
>not sure the guidelines should recommend a test that will always succeed.
>

What about:

   The Collecting Process may check whether IPFIX Messages are lost by
   checking the Sequence Number in the IPFIX header.

It is similar to the guideline we give for SCTP:

   "The Collecting Process may check whether IPFIX Messages are lost by
   checking the Sequence Number in the IPFIX header.  The Collecting
   Process SHOULD use the Sequence Number in the IPFIX Message header to
   determine whether any messages are lost when using an unreliable or
   partially reliable stream.  Sequence numbers should be tracked
   independently for each stream."

>
>2. The document is in sections 4.1 and 6.2 not particularly clear about
>template retransmission and expiration delays, and their
>configurability. From protocol-24 section 10.3.7, we have a guideline
>for Collector expiry delay to be set to at least three times Exporter
>retransmission delay; from protocol-24 10.3.6 and guidelines-02 6.2 we
>have a recommended retransmission delay of 10 minutes. So, I'd suggest
>the following:
>
> - Change the language in section 4.1 para 2 "If no template becomes
>available within 30 minutes...) to note that this is the expiry delay,
>and is configurable.
>
>
> - Change the language in the last paragraph of section 6.2 to recommend
>a 30 minute expiry time, instead of 60 minutes, in line with the 3x
>guideline noted above
>
>(This is a relatively straightforward change, but has been a point of
>much discussion for the protocol document)
>

what about changing the second paragraph of 4.1 to:

"A Data Set received with an unknown Set ID MAY be stored pending the arrival of the corresponding Template (cf. section 9 of  [IPFIX-INFO]). If no Template becomes available, the event should be logged and the Transport Session reset, which will cause the Templates to be resent. The amount of time the Collecting Process waits for a Template before resetting SHOULD be configurable.
We recommend a default of 30 minutes. Note that when using UDP as the transport protocol, this delay SHOULD be bound, when possible, by the Template Retransmit and the Template Expiry times (cf. Section 6.2)."

Regards,
Elisa

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

---

From: Brian Trammell <[email-masked]>
Date: Thu, 08 Mar 2007 13:42:19 -0500

>    checking the Sequence Number in the IPFIX header.

yep, sounds good... We don't want to preclude the CP from checking
sequence numbers in a transport-independent way (and out of sequence
messages over TCP should be logged anyway, as an indication that the
remote EP is broken), but it's not a requirement as with SCTP-PR and UDP.

> "A Data Set received with an unknown Set ID MAY be stored pending the
> arrival of the corresponding Template (cf. section 9 of  [IPFIX-INFO]).
> If no Template becomes available, the event should be logged and the
> Transport Session reset, which will cause the Templates to be resent.
> The amount of time the Collecting Process waits for a Template before
> resetting SHOULD be configurable.
> We recommend a default of 30 minutes. Note that when using UDP as the
> transport protocol, this delay SHOULD be bound, when possible, by the
> Template Retransmit and the Template Expiry times (cf. Section 6.2)."

Also good... this makes it clear that this storage (and associated
delay) is transport-independent.

Thanks,

Brian

---

From: Brian Trammell <[email-masked]>
Date: Thu, 08 Mar 2007 13:42:19 -0500

Thanks,

Brian

---

From: "Gerhard Muenz" <[email-masked]>
Date: Wed, 14 Mar 2007 19:42:09 +0100 (CET)

Elisa,

On Thu, March 8, 2007 5:45 pm, Boschi, Elisa said:
> arrival of the corresponding Template (cf. section 9 of  [IPFIX-INFO]). If
> no Template becomes available, the event should be logged and the
> Transport Session reset, which will cause the Templates to be resent. The
> amount of time the Collecting Process waits for a Template before

The paragraph in 4.1 is a repetition of the first paragraph in 3.1. I have
no problem with this redundancy - repeating important issues can make
things clearer. But 3.1 is missing the timing information. So you should
also mention the timings in 3.1 or refer to 4.1 for further information.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen
Sand 13 (Room B309), D-72076 Tuebingen, Germany
Phone:  +49 7071 29-70534       Fax: +49 7071 29-5220
E-mail: [email-masked]
WWW:    http://net.informatik.uni-tuebingen.de/~muenz

---

From: "Gerhard Muenz" <[email-masked]>
Date: Wed, 14 Mar 2007 19:42:09 +0100 (CET)

Elisa,

Regards,
Gerhard