Subject: [IPFIX] R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

From: "Salvatore D'Antonio" <[email-masked]>
Date: Tue, 9 Apr 2013 17:40:03 +0200

Dear all,

A new version of the Internet Draft on Flow Selection Techniques has been submitted. It contains the following changes:

-          A new section illustrating the difference between Intermediate Flow Selection Process and Intermediate Selection Process has been added,

-          The sentence "In order to be compliant with this document, at least the Property  Match Filtering MUST be implemented." has been removed in Section 1,

-          “MUST” has been replaced with “SHOULD” in Section 5.1,

-          “The flowSelectorAlgorithm registry is maintained by IANA." has been replaced with “IANA is requested to create the flowSelectorAlgorithm registry.”

-          The sentence "The registry can be updated when specifications of the new  technique(s) and any new Information Elements are provided." has been removed since it did not clarify how the registry will be managed.

-           Section 6.1.1 “Property Match Filtering” has been changed by adding some text on how Property Match Filtering can be  used by an Intermediate Flow Selection Process in the Metering Process, in the  Exporting Process and within an IPFIX Mediator.

Best regards,

Salvatore

Da: Benoit Claise [mailto:[email-masked]] 
Inviato: lunedì 8 aprile 2013 15:21
A: [email-masked]
Cc: [email-masked]
Oggetto: Fwd: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Dear authors,

The IETF last call has finished.
Can you please update your draft based on the feedback received.
Then I will progress it.

Regards, Benoit

-------- Original Message -------- 

Subject: 

Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Date: 

Mon, 01 Apr 2013 00:28:46 -0700

From: 

DraftTracker Mail System  <mailto:[email-masked]> <[email-masked]>

To: 

[email-masked], [email-masked], [email-masked]

CC: 

[email-masked]

Please DO NOT reply to this email.
 
I-D: <draft-ietf-ipfix-flow-selection-tech-14.txt>
ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/
 
IETF Last Call has ended, and the state has been changed to
Waiting for AD Go-Ahead.

 

  _____  

Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di rilascio: 07/04/2013

******************************************************************************	

IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO

Il 5 per mille all'Universita' degli Studi di Napoli "Parthenope" incrementa le borse di studio agli studenti - codice fiscale 80018240632

http://www.uniparthenope.it/index.php/5xmille 

http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille

Questa informativa e' inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.

---

From: S Moonesamy <[email-masked]>
Date: Tue, 09 Apr 2013 09:10:18 -0700

Hi Salvatore,
At 08:40 09-04-2013, Salvatore D'Antonio wrote:
>-          The sentence "The registry can be updated when 
>specifications of the new  technique(s) and any new Information 
>Elements are provided." has been removed since it did not clarify 
>how the registry will be managed.

This is a follow-up to the APPSDIR review of 
draft-ietf-ipfix-flow-selection-tech ( 
http://www.ietf.org/mail-archive/web/apps-discuss/current/msg09239.html )

 From Section 9.1.1 of draft-ietf-ipfix-flow-selection-tech-15:

   "New assignments for the registry will be administered
    by IANA and are subject to Expert Review [RFC5226]."

draft-ietf-ipfix-flow-selection-tech-15 defines a sub-registry.  It 
does not provide any relevant details about the sub-registry.  What 
documentation is required and which criteria will be used for 
assignments in the new sub-registry?

Regards,
S. Moonesamy

---

From: "Salvatore D'Antonio" <[email-masked]>
Date: Wed, 10 Apr 2013 09:38:31 +0200

Dear S. Moonesamy,

I did not adequately addressed your comment because I thought that the
guidelines specified in RFC 5226 were sufficient to deal with the issues
concerning the management of the sub-registry.
I would greatly appreciate if you could provide me with the reference to a
Draft where documentation and criteria for managing assignments are
specified so that I may use such Draft as an example.

Thanks a lot in advance.

Best regards,

Salvatore   

-----Messaggio originale-----
Da: S Moonesamy [mailto:[email-masked]] 
Inviato: martedì 9 aprile 2013 18:10
A: Salvatore D'Antonio;
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Oggetto: Re: R: Last Call Expired:
<draft-ietf-ipfix-flow-selection-tech-14.txt> (APPSDIR review)

Hi Salvatore,

Regards,
S. Moonesamy 
-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.3272 / Database dei virus: 3162/6234 -  Data di rilascio:
09/04/2013
-----
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com
Versione: 2013.0.3272 / Database dei virus: 3162/6234 -  Data di rilascio:
09/04/2013

---

From: S Moonesamy <[email-masked]>
Date: Wed, 10 Apr 2013 01:24:28 -0700

Hi Salvatore,
>concerning the management of the sub-registry.

Ok.

>specified so that I may use such Draft as an example.

Section 4.1 of RFC 5226 points to Sections 6 and 7.2 in RFC 3748 as 
an example about Expert Review.  Section 7.1 of RFC 5102 is another 
example.  I suggest discussing the proposed change with the document 
shepherd or the Area Director to see whether it is appropriate.

Regards,
S. Moonesamy

---

From: Benoit Claise <[email-masked]>
Date: Mon, 15 Apr 2013 11:42:47 +0200

Salvatore
>
> Dear all,
>
> A new version of the Internet Draft on Flow Selection Techniques has 
> been submitted. It contains the following changes:
>
> -A new section illustrating the difference between Intermediate Flow 
> Selection Process and Intermediate Selection Process has been added,
>
> -The sentence "In order to be compliant with this document, at least 
> the Property  Match Filtering MUST be implemented." has been removed 
> in Section 1,
>
> -“MUST” has been replaced with “SHOULD” in Section 5.1,
>
Actually, the feedback was:

    In Section 1:

       "In order to be compliant with this document, at least the Property
        Match Filtering MUST be implemented."

    The above text is repeated in Section 5.1.  I suggest removing this
    sentence as it does not seem related to scope.

    My reading of the "MUST" is that it is being used for compliance
    instead of the reasons described in RFC 2119.  I suggest reviewing
    the usage of RFC 2119 key words in Section 5.1.

So the solution is not to change MUST to SHOULD.
The question is whether "MUST" versus "must" must be used.
I understand the concern. For compliance reason with the PSAMP RFC 5475 
(which is closely related) ...

        7 <http://tools.ietf.org/html/rfc5475#section-7>. Parameters for
        the Description of Selection Techniques

        This section gives an overview of different alternative selection
        schemes and their required parameters.  In order to be compliant with
        PSAMP, at least one of proposed schemes MUST be implemented.

... I would keep the initial "MUST" from the previous draft version.

> -“The flowSelectorAlgorithm registry is maintained by IANA." has been 
> replaced with “IANA is requested to create the flowSelectorAlgorithm 
> registry.”
>
> -The sentence "The registry can be updated when specifications of the 
> new  technique(s) and any new Information Elements are provided." has 
> been removed since it did not clarify how the registry will be managed.
>
> - Section 6.1.1 “Property Match Filtering” has been changed by adding 
> some text on how Property Match Filtering can be  used by an 
> Intermediate Flow Selection Process in the Metering Process, in the 
>  Exporting Process and within an IPFIX Mediator.
>
When publishing a new version, please correct this editorial issue.

  " ... and Flow duration. in
    the An example is the selection of the largest ..."

> Best regards,
>
> Salvatore
>
> *Da:*Benoit Claise [mailto:[email-masked]]
> *Inviato:* lunedì 8 aprile 2013 15:21
> *A:* [email-masked]
> *Cc:* [email-masked]
> *Oggetto:* Fwd: Last Call Expired: 
> <draft-ietf-ipfix-flow-selection-tech-14.txt>
>
> Dear authors,
>
> *Subject: *
> *Date: *
> *From: *
> DraftTracker Mail System <[email-masked]> 
> <mailto:[email-masked]>
>
> *To: *
>
> 	
>
> [email-masked] <mailto:[email-masked]>, [email-masked] 
> <mailto:[email-masked]>, 
> [email-masked] 
> <mailto:[email-masked]>
>
> *CC: *
>
> 	
>
> [email-masked] <mailto:[email-masked]>
>
> ID Tracker URL:http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/
>   
> ------------------------------------------------------------------------
>
> Controllato da AVG - www.avg.com <http://www.avg.com>
> *******************************************************************************************************
>
> Il 5 per mille all'Università degli Studi di Napoli 
> "Parthenope"incrementa le borse di studio agli studenti - codice 
> fiscale *80018240632*
>
> _http://www.uniparthenope.it/index.php/5xmille_
>
> _http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille_
>
>
> Questa informativa è inserita in automatico dal sistema al fine 
> esclusivo della realizzazione dei fini istituzionali dell'ente.
>
>
>
>
> *******************************************************************************************************
>
> Il 5 per mille all'Università degli Studi di Napoli 
> "Parthenope"incrementa le borse di studio agli studenti - codice 
> fiscale *80018240632*
>
> _http://www.uniparthenope.it/index.php/5xmille_
>
> _http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille_
>
>
> Questa informativa è inserita in automatico dal sistema al fine 
> esclusivo della realizzazione dei fini istituzionali dell'ente.
>
>
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 15 Apr 2013 12:21:00 +0200

Salvatore, document shepherd,
> Section 4.1 of RFC 5226 points to Sections 6 and 7.2 in RFC 3748 as an 
> example about Expert Review.  Section 7.1 of RFC 5102 is another 
A similar example is http://tools.ietf.org/html/rfc5476#section-8.2, 
which refers to http://tools.ietf.org/html/rfc5477#section-8.2.1

Combining this text with your IANA considerations, this should be...
Document shepherd and authors, please double-check, it's easy to make a 
mistake.

            9.1.1
            <http://tools.ietf.org/html/draft-ietf-ipfix-flow-selection-tech-15#section-9.1.1>.
            flowSelectorAlgorithm

        Description:

           This Information Element identifies the Intermediate Flow
           Selection Process technique (e.g., Filtering, Sampling) that is
           applied by the Intermediate Flow Selection Process.

           Most of these techniques have parameters.  Its configuration
           parameter(s) MUST be clearly specified.  Further Information
           Elements are needed to fully specify packet selection with these
           methods and all their parameters.

           Further method identifiers may be added to the list below.  It
           might be necessary to define new Information Elements to specify
           their parameters.

           The flowSelectorAlgorithm registry is maintained by IANA.  New
           assignments for the registry will be administered by IANA, on a
           First Come First Served basis [RFC5226  <http://tools.ietf.org/html/rfc5226>], subject to Expert Review
           [RFC5226  <http://tools.ietf.org/html/rfc5226>].

           The registry can be updated when specifications of the new
           method(s) and any new Information Elements are provided.

           The group of experts must double check the flowSelectorAlgorithm
           definitions and Information Elements with already defined
           flowSelectorAlgorithm and Information Elements for completeness,
           accuracy, and redundancy.  Those experts will initially be drawn
           from the Working Group Chairs and document editors of the IPFIX
           and PSAMP Working Groups.

           The following Intermediate Flow Selection Process Techniques
           identifiers are defined here:

               +----+------------------------+--------------------------+
               | ID |        Technique       |      Parameters          |
               +----+------------------------+--------------------------+
               | 1  | Systematic count-based | flowSamplingInterval     |
               |    | Sampling               | flowSamplingSpacing      |
               +----+------------------------+--------------------------+
               | 2  | Systematic time-based  | flowSamplingTimeInterval |
               |    | Sampling               | flowSamplingTimeSpacing  |
               +----+------------------------+--------------------------+
               | 3  | Random n-out-of-N      | samplingSize             |
               |    | Sampling               | samplingPopulation       |
               +----+------------------------+--------------------------+
               | 4  | Uniform probabilistic  | samplingProbability      |
               |    | Sampling               |                          |
               +----+------------------------+--------------------------+
               | 5  | Property Match         | Information Element      |
               |    | Filtering              | Value Range              |
               +----+------------------------+--------------------------+
               |   Hash-based Filtering      | hashInitialiserValue     |
               +----+------------------------+ hashFlowDomain           |
               | 6  | using BOB              | hashSelectedRangeMin     |
               +----+------------------------+ hashSelectedRangeMax     |
               | 7  | using IPSX             | hashOutputRangeMin       |
               +----+------------------------+ hashOutputRangeMax       |
               | 8  | using CRC              |                          |
               +----+------------------------+--------------------------+
               | 9  | Flow-state Dependent   | No agreed Parameters     |
               |    | Intermediate Flow      |                          |
               |    | Selection Process      |                          |
               +----+------------------------+--------------------------+

                   Intermediate Flow Selection Process Techniques

        Abstract Data Type: unsigned16

        ElementId: TBD1

        Data Type Semantics: identifier

        Status: Current

Regards, Benoit.

---

From: "Salvatore D'Antonio" <[email-masked]>
Date: Sun, 21 Apr 2013 02:06:14 +0200

Dear Benoit, all

I submitted v16 of the Internet Draft.

I modified section 9.1.1 on the maintenance of the flowSelectorAlgorithm registry and fixed the editorial issue in section  6.1.1

I have also used MUST in section 6.1

Best regards,

Salvatore

Da: Benoit Claise [mailto:[email-masked]] 
Inviato: lunedì 15 aprile 2013 11:43
A: Salvatore D'Antonio
Cc: [email-masked]; [email-masked]; 'S Moonesamy'; [email-masked]; [email-masked]; 'Joel M. Halpern'; 'A. Jean Mahoney'; 'General Area Review Team'; 'IETF discussion list'; [email-masked]; [email-masked]
Oggetto: Re: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Salvatore

Dear all,

In Section 1: 

The above text is repeated in Section 5.1.  I suggest removing this sentence as it does not seem related to scope. 

My reading of the "MUST" is that it is being used for compliance instead of the reasons described in RFC 2119.  I suggest reviewing the usage of RFC 2119 key words in Section 5.1. 

So the solution is not to change MUST to SHOULD.
The question is whether "MUST" versus "must" must be used.
I understand the concern. For compliance reason with the PSAMP RFC 5475 (which is closely related) ...

 <http://tools.ietf.org/html/rfc5475#section-7> 7.  Parameters for the Description of Selection Techniques

 

Best regards,

Salvatore

Dear authors,

Regards, Benoit

-------- Original Message -------- 

Subject: 

Date: 

From: 

To: 

CC: 

[email-masked]

 

 

  _____  

Il 5 per mille all'Università degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632 

 <http://www.uniparthenope.it/index.php/5xmille> http://www.uniparthenope.it/index.php/5xmille 

 <http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille> http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille

Questa informativa è inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.

Il 5 per mille all'Università degli Studi di Napoli "Parthenope"incrementa le borse di studio agli studenti - codice fiscale 80018240632 

 <http://www.uniparthenope.it/index.php/5xmille> http://www.uniparthenope.it/index.php/5xmille 

 <http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille> http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la-parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-proventi-del-5-per-mille

Questa informativa è inserita in automatico dal sistema al fine esclusivo della realizzazione dei fini istituzionali dell'ente.

---

From: ramki Krishnan <[email-masked]>
Date: Wed, 24 Apr 2013 08:13:11 -0700

Dear Authors,

I had a good discussion with Juergen on this topic. He suggested that I reach out to you folks.

Suggested changes to Section 6.4
An example is the  "Sample and Hold" algorithm [EsVa01], or similar techniques, that try to prefer long-lived large volume flows in the selection. When a packet arrives, these packet selection techniques are applied only if a flow record for the packet does not exist. These packet selection techniques could have false positives but no false negatives; i.e. flows which are not long-lived large flows may be selected and learnt in the flow cache. The flows which are not long-lived large flows are later purged from the flow cache.

Suggested changes to Section 7.2
For techniques similar to “Sample and Hold”, the two parameters -- the observation interval, and the minimum bandwidth threshold over that observation interval -- should be programmable in a networking device to facilitate handling of different use cases and traffic characteristics.

From a bandwidth and time duration perspective, in order to identify long-lived large flows, we define an observation interval and observe the bandwidth of the flow over that observation interval. A flow that exceeds a certain minimum bandwidth threshold over that observation interval
would be considered a long-lived large flow.

For example, a flow which is at or above 10 Mbps for a time period of at least 30 seconds could be declared a long-lived large flow.

Suggested changes to Section 8 and Section 9
The parameters described in section 7.2.

The parameters I described above are captured in section 2.1.2 of the draft below. Other details are also captured in the draft below.
http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-sampling/?include_text=1

Thanks,
Ram (aka Ramki)
From: [email-masked] [mailto:[email-masked]] On Behalf Of Salvatore D'Antonio
Sent: Saturday, April 20, 2013 5:06 PM
To: 'Benoit Claise'
Cc: 'IETF discussion list'; [email-masked]; [email-masked]; 'General Area Review Team'; 'S Moonesamy'; [email-masked]; [email-masked]; [email-masked]; 'Joel M. Halpern'; 'A. Jean Mahoney'
Subject: [IPFIX] R: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Dear Benoit, all

Best regards,

Salvatore

Da: Benoit Claise [mailto:[email-masked]]
Inviato: lunedì 15 aprile 2013 11:43
A: Salvatore D'Antonio
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 'S Moonesamy'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 'Joel M. Halpern'; 'A. Jean Mahoney'; 'General Area Review Team'; 'IETF discussion list'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Oggetto: Re: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Salvatore
Dear all,

7<http://tools.ietf.org/html/rfc5475#section-7>.  Parameters for the Description of Selection Techniques

Best regards,

Salvatore

Da: Benoit Claise [mailto:[email-masked]]
Inviato: lunedì 8 aprile 2013 15:21
A: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Oggetto: Fwd: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Dear authors,

Regards, Benoit

-------- Original Message --------
Subject:

Date:

From:

DraftTracker Mail System <[email-masked]><mailto:[email-masked]>

To:

[email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

CC:

[email-masked]<mailto:[email-masked]>

Waiting for AD Go-Ahead.

________________________________
Nessun virus nel messaggio.
Controllato da AVG - www.avg.com<http://www.avg.com>
Versione: 2013.0.3272 / Database dei virus: 3162/6231 - Data di rilascio: 07/04/2013

---

From: ramki Krishnan <[email-masked]>
Date: Wed, 24 Apr 2013 19:02:35 -0700

Dear Authors,

The technique I am suggesting is “Multistage Filters” in [EsVa01] and not “Sample and Hold”. Apologies for the error. I have fixed the text – my suggested changes will be in an addition to what is there currently.

I had a good discussion with Juergen on this topic. He suggested that I reach out to you folks at the earliest.

Probably a separate sub-section in section 6 ???
An example is “Multistage Filters” [EsVa01], or similar techniques, that try to prefer long-lived large volume flows in the selection. When a packet arrives, these packet selection techniques are applied only if a flow record for the packet does not exist. These packet selection techniques could have false positives but no false negatives; i.e. flows which are not long-lived large flows may be selected and learnt in the flow cache. The flows which are not long-lived large flows are later purged from the flow cache.

Suggested changes to Section 7
For techniques similar to “Multistage Filters”, the two parameters -- the observation interval, and the minimum bandwidth threshold over that observation interval -- should be programmable in a networking device to facilitate handling of different use cases and traffic characteristics.

Suggested changes to Section 8 and Section 9
The parameters described in section 7

The parameters I described above are captured in sections 2.1.2/6.1 of the draft below. Other details are also captured in the draft below.
http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-sampling/?include_text=1

Thanks,
Ramki

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ramki Krishnan
Sent: Wednesday, April 24, 2013 8:13 AM
To: Salvatore D'Antonio; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: IPFIX Working Group
Subject: Re: [IPFIX] R: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Dear Authors,

Thanks,
Ram (aka Ramki)
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Salvatore D'Antonio
Sent: Saturday, April 20, 2013 5:06 PM
To: 'Benoit Claise'
Cc: 'IETF discussion list'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 'General Area Review Team'; 'S Moonesamy'; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; 'Joel M. Halpern'; 'A. Jean Mahoney'
Subject: [IPFIX] R: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Dear Benoit, all

Best regards,

Salvatore

Salvatore
Dear all,

Best regards,

Salvatore

Dear authors,

Regards, Benoit

-------- Original Message --------
Subject:

Date:

From:

To:

CC:

Waiting for AD Go-Ahead.

---

From: Nevil Brownlee <[email-masked]>
Date: Mon, 29 Apr 2013 14:10:02 +1200

Hi Ramki et al:

The IETF Last Call for this draft finished on 8 April 13, it's
been revised following feedback since then.

It already has short sections about flow-dependent packet selection,
including a reference to
[EsVa01]   Estan, C. and G,. Varghese, "New Directions in Traffic
               Measurement and Accounting: Focusing on the Elephants,
               Ignoring the Mice", ACM SIGCOMM Internet Measurement
               Workshop 2001, San Francisco (CA), November 2001
I regard that as the seminal paper for this particular topic; it was
followed in 2004 by a SIGCOMM paper, "Building a better NetFlow" by
Estan, Keys, Moore and Varghese.

At this point I'd like to see this draft carried through its IESG
consideration without the distraction (and delay) brought on by
attempting to define parameters for flow-dependent selection in the
draft at this very late stage.  Better to continue discussion on the
list so as to reach a firm consensus on them.  When we have that,
they could be easily added as requests to IANA for Information Elements.

Again, I note that an IPR has been declared for
   draft-krishnan-opsawg-large-flow-load-balancing-07.
That draft seems to cover much the same material as that in
   draft-krishnan-ipfix-flow-aware-packet-sampling
but there's no IPR declared (so far) for the -ipfix- draft.
Can you comment on that, please?

Cheers, Nevil  (IPFIX co-chair)

On 25/04/13 2:02 PM, ramki Krishnan wrote:
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix
>

-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

---

From: ramki Krishnan <[email-masked]>
Date: Sun, 28 Apr 2013 21:15:11 -0700

Hi Nevil,

Thanks for the response, I will follow up separately on this item.

After further discussions in OPSAWG, all IPR related material has been removed from "draft-krishnan-opsawg-large-flow-load-balancing". The latest draft, version 8, reflects this. The IPR update, which will happen in the next couple of days, will reflect this.

I have also made sure that all IPR related material has been removed from draft-krishnan-ipfix-flow-aware-packet-sampling.

Thanks,
Ramki

-----Original Message-----
From: Nevil Brownlee [mailto:[email-masked]]
Sent: Sunday, April 28, 2013 7:10 PM
To: ramki Krishnan
Cc: Salvatore D'Antonio; [email-masked]; [email-masked]; IPFIX Working Group
Subject: Re: [IPFIX] R: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Hi Ramki et al:

The IETF Last Call for this draft finished on 8 April 13, it's been revised following feedback since then.

It already has short sections about flow-dependent packet selection, including a reference to
[EsVa01]   Estan, C. and G,. Varghese, "New Directions in Traffic
               Measurement and Accounting: Focusing on the Elephants,
               Ignoring the Mice", ACM SIGCOMM Internet Measurement
               Workshop 2001, San Francisco (CA), November 2001 I regard that as the seminal paper for this particular topic; it was followed in 2004 by a SIGCOMM paper, "Building a better NetFlow" by Estan, Keys, Moore and Varghese.

At this point I'd like to see this draft carried through its IESG consideration without the distraction (and delay) brought on by attempting to define parameters for flow-dependent selection in the draft at this very late stage.  Better to continue discussion on the list so as to reach a firm consensus on them.  When we have that, they could be easily added as requests to IANA for Information Elements.

On 25/04/13 2:02 PM, ramki Krishnan wrote:
> Dear Authors,
>
> The technique I am suggesting is "Multistage Filters" in [EsVa01] and not "Sample and Hold". Apologies for the error. I have fixed the text - my suggested changes will be in an addition to what is there currently.
>
> An example is "Multistage Filters" [EsVa01], or similar techniques, that try to prefer long-lived large volume flows in the selection. When a packet arrives, these packet selection techniques are applied only if a flow record for the packet does not exist. These packet selection techniques could have false positives but no false negatives; i.e. flows which are not long-lived large flows may be selected and learnt in the flow cache. The flows which are not long-lived large flows are later purged from the flow cache.
>
> For techniques similar to "Multistage Filters", the two parameters -- the observation interval, and the minimum bandwidth threshold over that observation interval -- should be programmable in a networking device to facilitate handling of different use cases and traffic characteristics.
>
>  From a bandwidth and time duration perspective, in order to identify
> long-lived large flows, we define an observation interval and observe the bandwidth of the flow over that observation interval. A flow that exceeds a certain minimum bandwidth threshold over that observation interval would be considered a long-lived large flow.
>
> Suggested changes to Section 8 and Section 9 The parameters described
> in section 7
>
> From: [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]] On Behalf Of ramki Krishnan
> To: Salvatore D'Antonio; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> Cc: IPFIX Working Group
> Subject: Re: [IPFIX] R: R: Last Call Expired:
> For techniques similar to "Sample and Hold", the two parameters -- the observation interval, and the minimum bandwidth threshold over that observation interval -- should be programmable in a networking device to facilitate handling of different use cases and traffic characteristics.
>
>  From a bandwidth and time duration perspective, in order to identify
> long-lived large flows, we define an observation interval and observe the bandwidth of the flow over that observation interval. A flow that exceeds a certain minimum bandwidth threshold over that observation interval would be considered a long-lived large flow.
>
> Suggested changes to Section 8 and Section 9 The parameters described
> in section 7.2.
>
> From: [email-masked]<mailto:[email-masked]>
> [mailto:[email-masked]] On Behalf Of Salvatore D'Antonio
> Subject: [IPFIX] R: R: Last Call Expired:
> I modified section 9.1.1 on the maintenance of the
> flowSelectorAlgorithm registry and fixed the editorial issue in
> section  6.1.1
>
> Cc:
> [email-masked]<mailto:draft-ietf-
> [email-masked]>;
> [email-masked]<mailto:[email-masked]>; 'S
> Moonesamy'; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; 'Joel M. Halpern'; 'A. Jean
> Mahoney'; 'General Area Review Team'; 'IETF discussion list';
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> -          "MUST" has been replaced with "SHOULD" in Section 5.1,
> -          "The flowSelectorAlgorithm registry is maintained by IANA." has been replaced with "IANA is requested to create the flowSelectorAlgorithm registry."
>
> -           Section 6.1.1 "Property Match Filtering" has been changed by adding some text on how Property Match Filtering can be  used by an Intermediate Flow Selection Process in the Metering Process, in the  Exporting Process and within an IPFIX Mediator.
> A:
> [email-masked]<mailto:draft-ietf-
> [email-masked]>
> Oggetto: Fwd: Last Call Expired:
> DraftTracker Mail System
> <[email-masked]><mailto:[email-masked]>
>
> To:
>
> [email-masked]<mailto:[email-masked]>,
> [email-masked]<mailto:[email-masked]>,
> [email-masked]<mailto:draft-ietf-
> [email-masked]>
>
> CC:
>
> ID Tracker URL:
> http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/
>
>
>
> fiscale 80018240632
> http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la
> -parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-prove
> nti-del-5-per-mille
>
>
> fiscale 80018240632
> http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la
> -parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-prove
> nti-del-5-per-mille
>
>
> fiscale 80018240632
> http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la
> -parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-prove
> nti-del-5-per-mille
>
>
> fiscale 80018240632
> http://www.uniparthenope.it/index.php/it/avvisi-sito-di-ateneo/2943-la
> -parthenope-premia-il-tuo-voto-di-diploma-ed-il-tuo-imegno-con-i-prove
> nti-del-5-per-mille
>
>