Subject: Re: [IPFIX] WG last call on draft-ietf-ipfix-reducing-redundancy-01.txt until December 1st

From: "Boschi, Elisa" <[email-masked]>
Date: Mon, 4 Dec 2006 16:16:23 -0000

Gerhard,

thanks for your comments.
Find my answers (and comments) inline:

>
>Some comments on Section 8:
>
>   The main advantage of the method specified in this document is the
>   reduction in the amount of measurement data that has to be
>   transferred from the Exporter to the Collector.
>
>I would like to add here "under some conditions" (or something similar)
>since the proposed method does not necessarily lead to a reduction of
>the amount of data.
>

I propose to add a sentence at the beginning of section 8:

"The main advantage of the method specified in this document is the reduction in the amount of measurement data that has to be transferred from the Exporter to the Collector.  Note that several factors influence its efficiency, as discussed in this section. "

and then in section 8.4 swap the two paragraphs, moving the example evaluation to the end:

"While the goal of this specification is to reduce the bandwidth, the efficiency might be limited.  Indeed, the efficiency gain is based on the numerous redundant information in flows.  While the Exporting Process can evaluate the direct gain for the Flow Records to be exported, it can’t predict whether future Flow Records would contain the information specified by active commonPropertiesID values.  This implies that the efficiency factor of this specification is higher for specific applications where filtering is involved, such as one-way delay or trajectory sampling.

The example in section 11.2 below uses IPFIX to export measurement data for each received packet.  In that case, for a flow of 1000 packets the amount of data can be decreased more than 33 percent."

>
>   The transfer of the commonPropertiesIDs originates some overhead.
>   Note that IPFIX allows reduced-size encoding of Information
>   Elements.  In cases where the range of the commonPropertiesID can be
>   restricted, reduced-size encoding can be applied also to the
>   commonPropertiesID, and would result in a further bandwidth
>   efficiency gain.
>
>I would say: the overhead of the commonPropertiesID IE is very
>significant if 64 bit are used. 
>
>The length of the commonPropertiesID
>field also gives you a necessary condition if you ever want to reach a
>reduced amount of data: The length must be shorter than the length of
>the replaced IEs, otherwise you even increase the amount monitoring data!
>
>As a consequence, reduced-size encoding should be used whenever possible.
>

what about changing the text in 8.2 as follows:

OLD:
In cases where the range of the commonPropertiesID can be restricted, reduced-size encoding can be applied also to the commonPropertiesID, and would result in a further bandwidth efficiency gain.

NEW:
In cases where the range of the commonPropertiesID can be restricted, it is  RECOMMENDED to apply reduced-size encoding to the commonPropertiesID, to achieve a further bandwidth efficiency gain.

>
>   The example in section 11.2 below uses IPFIX to export measurement
>   data for each received packet.  In that case, for a flow of 1000
>   packets the amount of data can be decreased more than 33 percent.
>
>The example in 11.2 refers to OWD measurements, which is a very special
>application where the proposed method is very beneficial. Maybe you
>should mention "OWD measurements" here, since 33 percent may not be the
>general case.
>

33 percent is of course not the general case. It is the efficiency gain of the example in 11.2...

>
>   While the goal of this specification is to reduce the bandwidth, the
>   efficiency might be limited.
>
>As I said before, you can even increase the amount of data with the
>proposed method. So I suggest to explain under which conditions the
>approach achieves its goal.
>

we give guidelines in sections 8.1 and 8.4 for that:

"The proposed method is most effective using a reliable transport protocol for the transfer of the Common Properties...."

and:

"While the goal of this specification is to reduce the bandwidth, the efficiency might be limited.  Indeed, the efficiency gain is based on the numerous redundant information in flows.  While the Exporting Process can evaluate the direct gain for the Flow Records to be exported, it can’t predict whether future Flow Records would contain the information specified by active commonPropertiesID values.  This implies that the efficiency factor of this specification is higher for specific applications where filtering is involved, such as one-way delay or trajectory sampling."

Are you suggesting to add more conditions (which ones?) or is the text above not clear?

>How many times do I need to refer to the common properties until the
>amount of data is reduced for the first time?
>This should be a simple calculation. Even if this number cannot be
>predicted in advance in pratice, it might be useful to estimate when I
>should use the approach.
>

that depends on which ones the Common Properties are, and how many they are, don't you think? Or are you proposing to do this for one of the examples?

Regards,
Elisa

>
>Regards,
>Gerhard
>
>Juergen Quittek wrote:
>
>>Dear all,
>>
>>As agreed at the IPFIX session in San Diego last week
>>this is the WG last call on the Internet draft on
>>Reducing redundancy in IPFIX and PSAMP reports,
>>draft-ietf-ipfix-reducing-redundancy-01.txt.
>>
>>The WG last call starts today and will be closed on
>>December 1st.
>>
>>Please review the draft and send your comments!  Please also
>>send a message to the mailing list if you reviewed it and
>>have no comment to make!
>>
>>Thanks,
>>
>>   Juergen
>>
>>
>>_______________________________________________
>>IPFIX mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/ipfix
>
>
>
>
>_______________________________________________
>IPFIX mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ipfix
>
**************************************************************************************************
 
 E-mail Confidentiality Notice and Disclaimer.
 
  This email and any files transmitted with it are confidential and are intended solely for 
the use of the individual or entity to which they are addressed. Access to this e-mail by 
anyone else is unauthorised. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in reliance on it, is 
prohibited. 
  E-mail messages are not necessarily secure.  Hitachi does not accept responsibility 
for any changes made to this message after it was sent. 
  Please note that Hitachi checks outgoing e-mail messages for the presence of 
computer viruses.

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

---

From: Gerhard Muenz <[email-masked]>
Date: Tue, 05 Dec 2006 10:38:25 +0100

Hi Elisa,

Boschi, Elisa wrote:
> "The main advantage of the method specified in this document is the
> reduction in the amount of measurement data that has to be transferred
> from the Exporter to the Collector.  Note that several factors influence
> its efficiency, as discussed in this section. "

You write "main advantage". Are there any other advantages than reducing
the amount of data? Then you should mention them.
If not, what do you think about: "The objective of the method..."
This would also leave it open if this goal is actually achieved or not.

Otherwise, your added sentence is fine.

> "While the goal of this specification is to reduce the bandwidth, the
> efficiency might be limited.  Indeed, the efficiency gain is based on
> the numerous redundant information in flows.  While the Exporting
> Process can evaluate the direct gain for the Flow Records to be
> exported, it can?t predict whether future Flow Records would contain the
> information specified by active commonPropertiesID values.  This implies
> that the efficiency factor of this specification is higher for specific
> applications where filtering is involved, such as one-way delay or
> trajectory sampling.

You could remark here that the amount of data might even increase under
bad conditions.

> The example in section 11.2 below uses IPFIX to export measurement data
> for each received packet.  In that case, for a flow of 1000 packets the
> amount of data can be decreased more than 33 percent."

> In cases where the range of the commonPropertiesID can be restricted,
> reduced-size encoding can be applied also to the commonPropertiesID, and
> would result in a further bandwidth efficiency gain.
> 
> NEW:
> In cases where the range of the commonPropertiesID can be restricted, it
> is  RECOMMENDED to apply reduced-size encoding to the
> commonPropertiesID, to achieve a further bandwidth efficiency gain.

Ok.
You should add that the length of the commonPropertiesID field has to be
shorter than the length of the replaced fields, otherwise the amount of
data is increased.
You could note that a big difference between the length of the replaced
fields and the length of the commonPropertiesID field increases the
efficiency gain.

> "The proposed method is most effective using a reliable transport
> protocol for the transfer of the Common Properties...."
> 
> and:
> 
> "While the goal of this specification is to reduce the bandwidth, the
> efficiency might be limited.  Indeed, the efficiency gain is based on
> the numerous redundant information in flows.  While the Exporting
> Process can evaluate the direct gain for the Flow Records to be
> exported, it can?t predict whether future Flow Records would contain the
> information specified by active commonPropertiesID values.  This implies
> that the efficiency factor of this specification is higher for specific
> applications where filtering is involved, such as one-way delay or
> trajectory sampling."
> 

See my suggestions above.

> that depends on which ones the Common Properties are, and how many they
> are, don't you think? Or are you proposing to do this for one of the
> examples?

A calculation of thumb is:
1) I save X bytes in my flow records (difference between length of
replaced fields and length of commonPropertiesID field)
2) I need my Y bytes to send the option record
=> The amount if data is reduced after Y/X flow records sent
This calculation neglects the overhead of additional templates and set
headers.
But maybe these considerations are more interesting for an academic
publication than for a standard document.

Regards,
Gerhard

---

From: Gerhard Muenz <[email-masked]>
Date: Tue, 05 Dec 2006 10:38:25 +0100

Hi Elisa,

Ok.

Regards,
Gerhard