Re: [IPFIX] Flow-state dependent packet selection techniques -- draft update

[ramki Krishnan <[e-mail]>]

Dear All,

A gentle reminder, your review and comments are most welcome.

Thanks,
Ramki

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of ramki Krishnan
Sent: Tuesday, June 18, 2013 8:38 AM
To: IPFIX Working Group; Juergen Quittek
Cc: Ning So ([e-mail])
Subject: [IPFIX] Flow-state dependent packet selection techniques -- draft update

Dear Juergen,

Many thanks for your advice on positioning the draft.

Dear All,

We have updated the draft according to Juergen's advice and looking forward to your review and comments.

http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet-sampling/

Thanks,
Ramki

-----Original Message-----
From: Juergen Quittek [mailto:[e-mail]]
Sent: Friday, June 07, 2013 4:39 AM
To: ramki Krishnan
Cc: Ning So ([e-mail]); Benoit Claise; 'Nevil Brownlee'
Subject: RE: [IPFIX] R: R: Last Call Expired: <draft-ietf-ipfix-flow-selection-tech-14.txt>

Dear Ramki,

My advice to you would be to
1. Position your method compared to packet sampling (RFC547X) and to flow sampling (http://datatracker.ietf.org/doc/draft-ietf-ipfix-flow-selection-tech/).
2. Identify what needs to be added to the IPFIX/PSAMP information models that are maintained by IANA

An update of your draft clarifying these two issues would be helpful to understand your value proposition.

Kind regards,
    Juergen

> -----Original Message-----
> From: ramki Krishnan [mailto:[e-mail]]
> Sent: Montag, 27. Mai 2013 16:45
> To: Juergen Quittek
> Cc: Ning So ([e-mail])
> Subject: RE: [IPFIX] R: R: Last Call Expired:
> <draft-ietf-ipfix-flow-selection- tech-14.txt>
>
> Hi Juergen,
>
> Following up on this topic, we would like to add the information
> model/IANA considerations for Multistage filters [EsVa01] to the flow
> aware packet sampling draft (link below). Multistage filters is an
> intermediate flow selection technique and helps in filtering only the long-lived large flows.
>
> http://datatracker.ietf.org/doc/draft-krishnan-ipfix-flow-aware-packet
> -
> sampling/
>
> The value proposition of flow aware packet sampling draft can be
> summarized as follows
> - A practical use case for Multistage filters in security threat
> detection; simulation results/operational considerations will also be
> elaborated
> - Information model/IANA considerations for Multistage filters which
> are not addressed in the current flow selection draft
>
> Please advise so that we can proceed further.
>
> Thanks,
> Ramki
>
> -----Original Message-----
> From: ramki Krishnan
> Sent: Sunday, April 28, 2013 9:15 PM
> To: 'Nevil Brownlee'
> Cc: Salvatore D'Antonio; [e-mail]; [e-mail];
> IPFIX Working Group; Ning So
> Subject: RE: [IPFIX] R: R: Last Call Expired:
> <draft-ietf-ipfix-flow-selection- tech-14.txt>
>
> 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:[e-mail]]
> Sent: Sunday, April 28, 2013 7:10 PM
> To: ramki Krishnan
> Cc: Salvatore D'Antonio; [e-mail]; [e-mail];
> 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.
>
> 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:
> > 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.
> >
> >  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
> >
> > 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-pack
> > et
> > -sampling/?include_text=1
> >
> > Thanks,
> > Ramki
> >
> > From: [e-mail]<mailto:[e-mail]>
> > [mailto:[e-mail]] On Behalf Of ramki Krishnan
> > Sent: Wednesday, April 24, 2013 8:13 AM
> > To: Salvatore D'Antonio; [e-mail]<mailto:[e-mail]>;
> > [e-mail]<mailto:[e-mail]>
> > Cc: IPFIX Working Group
> > Subject: Re: [IPFIX] R: R: Last Call Expired:
> > <draft-ietf-ipfix-flow-selection-tech-14.txt>
> >
> > 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-pack
> > et
> > -sampling/?include_text=1
> >
> > Thanks,
> > Ram (aka Ramki)
> > From: [e-mail]<mailto:[e-mail]>
> > [mailto:[e-mail]] On Behalf Of Salvatore D'Antonio
> > Sent: Saturday, April 20, 2013 5:06 PM
> > To: 'Benoit Claise'
> > Cc: 'IETF discussion list'; draft-ietf-ipfix-flow-selection-
> [e-mail]<mailto:draft-ietf-ipfix-flow-selection-
> [e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> 'General Area Review Team'; 'S Moonesamy'; ipfix-
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>;
> 'Joel M. Halpern'; 'A. Jean Mahoney'
> > Subject: [IPFIX] R: R: Last Call Expired:
> > <draft-ietf-ipfix-flow-selection-tech-14.txt>
> >
> > 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:[e-mail]]
> > Inviato: lunedì 15 aprile 2013 11:43
> > A: Salvatore D'Antonio
> > Cc:
> > [e-mail]<mailto:draft-iet
> > f- [e-mail]>;
> > [e-mail]<mailto:[e-mail]>; 'S
> > Moonesamy'; [e-mail]<mailto:[e-mail]>;
> > [e-mail]<mailto:[e-mail]>; 'Joel M. Halpern'; 'A. Jean
> > Mahoney'; 'General Area Review Team'; 'IETF discussion list';
> > [e-mail]<mailto:[e-mail]>;
> > [e-mail]<mailto:[e-mail]>
> > Oggetto: Re: R: Last Call Expired:
> > <draft-ietf-ipfix-flow-selection-tech-14.txt>
> >
> > 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:[e-mail]]
> > Inviato: lunedì 8 aprile 2013 15:21
> > A:
> > [e-mail]<mailto:draft-iet
> > f- [e-mail]>
> > Cc: [e-mail]<mailto:[e-mail]>
> > 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
> > <[e-mail]><mailto:[e-mail]>
> >
> > To:
> >
> > [e-mail]<mailto:[e-mail]>,
> > [e-mail]<mailto:[e-mail]>,
> > [e-mail]<mailto:draft-iet
> > f- [e-mail]>
> >
> > CC:
> >
> > [e-mail]<mailto:[e-mail]>
> >
> >
> >
> > 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<http://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'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-pro
> > ve
> > nti-del-5-per-mille
> >
> >
> > Questa informativa è inserita in automatico dal sistema al fine
> > esclusivo
> della realizzazione dei fini istituzionali dell'ente.
> >
> >
> >
> >
> >
> **********************************************************
> ************
> > *********************************
> >
> > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO
> >
> >
> >
> > 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-pro
> > ve
> > nti-del-5-per-mille
> >
> >
> > Questa informativa è inserita in automatico dal sistema al fine
> > esclusivo
> della realizzazione dei fini istituzionali dell'ente.
> >
> >
> >
> >
> >
> >
> >
> **********************************************************
> ************
> > *********************************
> >
> > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO
> >
> >
> >
> > 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-pro
> > ve
> > nti-del-5-per-mille
> >
> >
> > Questa informativa è inserita in automatico dal sistema al fine
> > esclusivo
> della realizzazione dei fini istituzionali dell'ente.
> >
> >
> >
> >
> >
> >
> **********************************************************
> ************
> > *********************************
> >
> > IL MERITO DEGLI STUDENTI VIENE RICONOSCIUTO
> >
> >
> >
> > 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-pro
> > ve
> > nti-del-5-per-mille
> >
> >
> > Questa informativa è inserita in automatico dal sistema al fine
> > esclusivo
> della realizzazione dei fini istituzionali dell'ente.
> >
> >
> >
> >
> >
> > _______________________________________________
> > IPFIX mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ipfix
> >
>
>
> --
> ---------------------------------------------------------------------
>   Nevil Brownlee                          Computer Science Department
>   Phone: [phone] x88941             The University of Auckland
>   FAX: [phone]   Private Bag 92019, Auckland 1142, New Zealand
_______________________________________________
IPFIX mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ipfix