Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-00

From: Paul Aitken <[email-masked]>
Date: Mon, 13 Jun 2011 14:02:40 +0100

Al, Jan,

I've attached a version of draft-ietf-bmwg-ipflow-meth-01 with numerous 
comments inline (look for "PJ:").

I've made numerous small changes directly to the text. Hopefully you can 
see those with in the change history (see "track changes").

I anticipate an updated document and a further WGLC.

Cheers,
P.

---

From: Paul Aitken <[email-masked]>
Date: Mon, 20 Jun 2011 10:17:46 +0100

Jan,

In reviewing this draft, I objected to numerous places where you 
discussed the cache as holding Flow Records.

eg, "the cache doesn't hold flow records, because the cache is a 
function of the metering process while flow records are a product of the 
exporting process."

While RFC 5101 (IPFIX) doesn't specifically mention caches, it does say:

       The Metering Process generates Flow Records.

And

       The Metering Process consists of a set of functions that includes
       packet header capturing, timestamping, sampling, classifying, and
       maintaining Flow Records.

"maintaining Flow Records" could be interpreted as cache maintenance.

So I'll relax my objection because this isn't clearly defined in IPFIX.

Thanks,
P.

On 13/06/11 14:02, Paul Aitken wrote:
> Al, Jan,
>
> I've attached a version of draft-ietf-bmwg-ipflow-meth-01 with 
> numerous comments inline (look for "PJ:").
>
> I've made numerous small changes directly to the text. Hopefully you 
> can see those with in the change history (see "track changes").
>

---

From: "Jan Novak (janovak)" <[email-masked]>
Date: Wed, 22 Jun 2011 10:32:13 +0200

Paul,

I would like to thank you for a very detailed review including
the language and mainly for improving/introducing the use of 
correct terminology - I think it made the doc much better !!!

I have worked on the text since you first provided the review back
in May so I hope it reflects and satisfies all your comments.

I have agreed with the very most of changes you wanted but these
below which I consider substantial to mention separately. Otherwise
see some answers to your questions/concerns through the review
in the attached text file.

1) Maximum Flow Monitoring Throughput

>PJ: The actual, average or effective "Flow Monitoring Throughput" 
>may be much lower, so you should clearly name this quantity as
> a *maximum*.

There is no such a quantity as actual/average/effective Flow Monitoring
Throughput - there is simply no definition anywhere for those. Flow
Monitoring Throughput is a "MAximum" by definition - please see section
3.1 of the reviewed document. 
This is in an exact analogy with the section 3.17 of RFC1242 defining 
the packet forwarding throughput. 
One could look at your suggestion as just a change
of the name for the defined quantity but the "Maximum" here would be an
adjective to something else and you would have to define what is the
 rest behind the adjective ...

2) Export of options and templates

>Also, I didn't yet read anything about allowing for export templates
>and/or options. Should these be included or excluded from the 
>measurements?

I would like to strongly disagree here. We had extensive discussions 
about it already with one of the previous reviewers and I always
pointed to the definition of Control Information by RFC5470
 (and I think also other IPFIX documents) section 2 which in
my opinion covers for the export of options and templates but I never
got
any answer regarding that - neither from you yet.
The reviewed document has explicit statements about export of this
information
in several places unless my understanding of the RFC5470 definition is
wrong.
I hope not though since I wouldn't like to dive into the definitions of
what those are in IPFIX. I hope you can comfirm that.

3) Packet Sampling 

>PJ: I'd like to see a greater discussion of the relevance of sampling, 
>throughout this document. I've already indicated a few places where
sampling 
>would impact the test.

Packet sampling is out of the scope of this document. If you prefer I
will
replace section 4.5 of the reviewed document with an explicit statement
saying just that instead. It is a separate I would say research subject
which can be undertaken by a future work/document.

Regards, Jan

The climate of Edinburgh is such that the weak succumb young .... 
and the strong envy them.
                                 Dr. Johnson

-----Original Message-----
From: Paul Aitken (paitken) 
Sent: 20 June 2011 10:18
To: Jan Novak (janovak); Al Morton
Cc: [email-masked]
Subject: Re: WGLC: draft-ietf-bmwg-ipflow-meth-00

Jan,

exporting process."

And

Thanks,
P.

---

From: Brian Trammell <[email-masked]>
Date: Wed, 22 Jun 2011 11:10:48 +0200

Hi, Jan,

I've reviewed the -01 and -02 diff and agree that the document is greatly improved; this revision, after addressing Paul's comments, should be ready to go.

I have two points of discussion/clarifiction, inline, below.

Best regards,

Brian

> what those are in IPFIX. I hope you can comfirm that.

The issue here is that template and option export should (in the normal case) be negligible in terms of export bandwidth (i.e., data records should  far, far outnumber options records and templates), the performance of exporting and/or collecting processes may be significantly impacted by the number of _simultaneous_ templates or options in effect on a transport session at any given time. Template lookup should be O(log t) at worst (unless you're being incredibly lazy), but might need to be done for every set (which implies O(n log t)). So at the very least, there should be parameters for the number of active templates in the session during benchmarking -- even if that number is 1.

> which can be undertaken by a future work/document.

Packet/flow sampling, however, is one of the approaches often used in production networks when flow collection performance is insufficient... so at the very least there should be a strong statement that this document applies to situations without packet or flow sampling. 

> <bmwg-PJ-review-1.txt>_______________________________________________
> bmwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bmwg

---

From: "Jan Novak (janovak)" <[email-masked]>
Date: Wed, 22 Jun 2011 11:38:09 +0200

Hi,

Ok, thanks Brian for looking at it - will do.

Jan

-----Original Message-----
From: Brian Trammell [mailto:[email-masked]] 
Sent: 22 June 2011 10:11
To: Jan Novak (janovak)
Cc: Paul Aitken (paitken); Al Morton; [email-masked]
Subject: Re: [bmwg] WGLC: draft-ietf-bmwg-ipflow-meth-00 - New Version
draft-ietf-bmwg-ipflow-meth-02.txt

Hi, Jan,

I've reviewed the -01 and -02 diff and agree that the document is
greatly improved; this revision, after addressing Paul's comments,
should be ready to go.

Best regards,

Brian

> what those are in IPFIX. I hope you can comfirm that.

The issue here is that template and option export should (in the normal
case) be negligible in terms of export bandwidth (i.e., data records
should  far, far outnumber options records and templates), the
performance of exporting and/or collecting processes may be
significantly impacted by the number of _simultaneous_ templates or
options in effect on a transport session at any given time. Template
lookup should be O(log t) at worst (unless you're being incredibly
lazy), but might need to be done for every set (which implies O(n log
t)). So at the very least, there should be parameters for the number of
active templates in the session during benchmarking -- even if that
number is 1.

> which can be undertaken by a future work/document.

Packet/flow sampling, however, is one of the approaches often used in
production networks when flow collection performance is insufficient...
so at the very least there should be a strong statement that this
document applies to situations without packet or flow sampling.