Subject: Re: [IPFIX] WGLC for 'flow selection' draft

From: Brian Trammell <[email-masked]>
Date: Tue, 1 Mar 2011 16:05:09 +0100

Hi, Nevil, all,

I have reviewed the Flow Selection draft for WGLC, and have identified several significant issues with it that, in my opinion, must be addressed before the document is sent to the IESG in fulfillment of point 5 of the WG's current charter.

My first issue is a structural one. Much of the text in this document deals with a very specific subset of flow selection, that which has to do with measurement-edge flow sampling in order to handle resource exhaustion. This is a very useful case, but kind of ancillary to content-based flow selection at a mediator, which in my understanding is the most widely useful application of flow selection, and the hardest to get right. I would have expected to see a smaller section 4, a much larger section 5 (containing much of the content of section 4.3), and a greatly expanded section 6.1.

The difference in flow selection between the metering and recording process is unclear. This "flow recording" is a new architectural concept, and one which is only implicitly defined. If this is a useful concept, it must be explicitly defined (in terminology), and explicit reasons must be given for superceding the IPFIX Architecture and Mediator framework.

That said, the point of this distinction is not clear with respect to the problem the authors are trying to solve here. Why is flow recording not just a function of the metering process? What is the use of distinguishing flows that the MP simply never metered as opposed to those it metered but never wrote? 

Third, the selection of flow keys for key-based selection in the subsections of section 7 seems arbitrary. Specifically, why can't I select flows based on protocolIdentifier? It is also unclear how to apply this flow selection system for selecting the set of flows for any but a very simplistic set of keys. A good example: all flows involving a given set of networks: "All flows which belong to Organization Foo", where Foo controls the netblocks 130.229.0.0/16, 199.38.128.0/17, and 199.57.198.0/23. Also, keep in mind that _any_ IE, basically, may be a Flow Key field. What if I only want to select 3-packet TCP flows (i.e., zero content complete handshakes)?

I would submit that this case -- arbitrary key space subsets -- must be handled by any flow selection draft that comes out of the WG; it's fairly common especially at the mediator level. If, instead, the scope of this document really is intended only to handle flow sampling use cases for resource constraint avoidance, that is certainly useful, but I would suggest in that case that it should be made Informational, and that an updated working group charter reflect a need to handle generalized flow selection in a separate document.

Fourth, how do the timestamp-range information elements work with _multiple_ periods of selection in the resource-restriction use case? Let's say I get two spikes of length epsilon - a few seconds - at time T and time U = T+k where k is long (say, a day). Then we say the selection period was k long, when it was actually epsilon at both T and U. Are there timeouts for differentiating these selection events from each other? It's not clear from the document what I can do with timestamps + counts that I can't do with counts alone. 

The following are specific technical or editorial issues with the draft:

1. In section 4.3, "The selection of the flow records to be exported implies performing a
  complete scanning of the memory area where flow information is
  stored, thus jeopardizing the efficiency of the overall exporting
  process" is not correct.

Efficient decision algorithms need not scan each flow completely as it passes the EP. If you've designed your templates right, you can generate buffer offset lists for random access, for example. This statement seems very implementation-specific.

2. The redefinition of information element names in the subsections of Section 7 is not allowed. Please refer to the IANA Information Element registry.

3. "Export" is the preferred noun form in English, not "exporting".

4. "At Mediators' level" -> "on an IPFIX Mediator".

5. The name of the selectorMethod IE is not prefixed to make it clear this is specific to flow selection.

6. I have not reviewed the details of the other timestamp and count IEs, since it's not clear what they're for. However, the names are uncharacteristically cryptic for IPFIX.

Best regards,

Brian

On Feb 27, 2011, at 11:58 PM, Nevil Brownlee wrote:

> 
> Hi all:
> 
> A little while ago, Benoit commented "I didn't see the WGLC notice for
> this draft."  Looking back through my notes, I see that at IETF 79 in
> Maastricht we agreed that "it would be ready for WGLC after its Editors
> had published a new draft."  Its -03 draft was published on 7 December
> 2010, so I started on its writeup, but failed to send out its WGLC
> note.  Ditto for its -04 draft.  I apologise for that.
> 
> On 14 Feb I called for reviews of it; Benoit has posted a review,
> thanks very much.  I still need one or two more reviews, and I'm -
> at last - starting its WG Last Call now.  It will end on 14 March.
> 
> Cheers, Nevil
> 
> -- 
> ---------------------------------------------------------------------
> Nevil Brownlee                    Computer Science Department | ITS
> Phone: +64 9 373 7599 x88941             The University of Auckland
> FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix