Subject: Re: [ipfix-info] "post" Information Elements: "can not necessarily be observed at the Observation Point of this flow"

From: Juergen Quittek <[email-masked]>
Date: Wed, 20 Jul 2005 01:21:36 +0200

Dear all,

Here is the problem description for the "pre" and "post" prefixes
that I promised last weekend.

I am sorry for the delay in sending this.  It is caused by my
inability to explain the issue briefly.  Please excuse that this
inability also is the reason why you have to read an awfully long
message in order to help solving the problem.

Let me start with a short introduction to the problem we have with
middleboxes and other boxes that change flow properties:

Some middleboxes change properties of a flow.  For example, a DiffServ
marker changes the value of the IPv4 TOS field, a network address
translator changes source or destination IP addresses, and a traffic
shaper changes the number of packets and bytes of a flow.

Consequently, on one side of a middlebox a traffic flow might have
properties that are different to its properties on the other side
of the middlebox.

Now, if an observation point stretches so far that it includes both
sides of the middlebox, we run into ambiguities.  In such a case,
there are two different values for packet count, byte count, DSCP,
source IP address, etc. to be observed at the observation point.
Which values should we export in such a situation?

We discussed this issue at our meeting in Seoul where Martin gave
a presentation that you can find in the proceedings:
<http://www.ietf.org/proceedings/04mar/slides/ipfix-3/index.html>
Also a draft discussing it is available in the archive:
<http://www.watersprings.org/pub/id/draft-quittek-ipfix-middlebox-00.txt>

I see two solutions for this problem and the discussion we need to
have is about selecting one of them or another solution suggested by
someone else.

Solution 1
  The recommendation that was made at the meeting and in the (already
  expired) draft was to avoid these ambiguities by avoiding to have an
  observation point that includes both sides of a middlebox.

  This solves the ambiguity problem. If it is clearly specified on which
  side of a middlebox we have our observation point, then we know which
  observed values to export.

  However, sometimes it might be very useful to ALSO export values from
  the other side of the middlebox.  These would be values that were not
  necessarily derived from direct observation of packets, but by other
  means available at the IPFIX device.

  Let's take a multicast daemon as an the example.  A multicast daemon
  is not necessarily a middlebox, but it causes the same problem.
  The daemon might be able to provide statistics on how many packets
  it sent out for a certain multicast address.

  If now our observation domain is restricted to the incoming traffic
  at a single network interface at the IPFIX device, then we will
  observe only the incoming multicast flow.  Still, it would be nice
  to report for this flow the number of outgoing multicast packets
  and octets.

  NetFlow version 9 supports this by fields MUL_DST_PKTS
  and MUL_DST_BYTES.  In the IPFIX info model they are called
  postMCastPacketDeltaCount and postMCastOctetDeltaCount.

  Note these objects report something that can not (necessarily)
  be observed at the flow's observation point.  The info model
  elements have the prefix 'post' in order to indicate the fact
  that these values do not necessarily result from an actual
  observation. In this case they result from the reporting of
  the multicast daemon.

  As second example we can look at a DiffServ packet marker. It
  changes the DSCP value of packets.  Following the approach of
  solution 1, the location of the observation point should be
  clearly specified to be at one or the other side of the marker.
  There it observes the DSCP value that is reported by information
  element classOfServiceIPv4 or classOfServiceIPv6.

  Also here, scenarios can easily be found for which it is desirable
  to report also the DSCP value that the flow has on the other side
  of the marker, that is not covered by the observation point.
  This is supported by NetFlow version 9 with the DST_TOS field and
  in our information model by the elements postClassOfServiceIPv4
  and postClassOfServiceIPv6.  As you see from the prefix of their
  name, we can only use them if the observation point is located
  on the path of the packet before it passes the marker.  If the
  observation point would be located somewhere on the path after
  the marker, we would need a different prefix for reporting from
  the other side.  The current version of the info model suggests
  prefix "pre" for this case, for example, "preClassOfServiceIPv4".
  We do not have any instance of an information element with prefix
  "pre" in the current version of our model, because common practice
  is measuring at the incoming interface of a router.  Still, we
  would need to add them at some time in the future if we follow
  solution one.  Please not that also for the 'post' prefix only a
  few instances are present.  We clearly expect to need more "post"
  elements if we start having IPFIX implementations on network
  address translators (postsourceIPv4Address, postTransportPort,
  etc.).

Solution 2
  The other way of solving the ambiguities is declaring that all
  flow properties that are exported represent the flow as it was
  when entering the IPFIX device except, if their name has the
  prefix "post".  Information elements without the prefix would
  describe flows of incoming packets and elements with that
  prefix would describe flows of outgoing packets.

  In case of the multicast daemon, the packetDeltaCount would be
  the number of incoming packets and the postMCastPacketDeltaCount
  would be the number of outgoing multicast packets.

  For the packet marker, classOfServiceIPv4 would deliver the value
  of the DSCP before marking and preClassOfServiceIPv4 would deliver
  the value after marking.

  This solution allows a more relaxed specification of the
  observation point.  It may be the entire device.  Ambiguities
  are avoided for this case, because every element is marked to
  concern either incoming or outgoing traffic.

Discussion
  {Please note that I am biases and have a preference for solution 1.
   Please contribute arguments for solution 2 or against solution 1
   that are missing in the lists below because I am too ignorant to
   see them.}

  Advantages of solution 2:
  - the concept is simpler.
  - We only need one prefix.

  Disadvantages of solution 2:
  - The concept is simple but not always clear.
    What about traffic observed at a network interface card in
    promiscuous mode. This traffic would be neither incoming nor
    outgoing.
  - A generic flow meter using libpcap typically observes incoming
    traffic as well as outgoing traffic.  This meter would need to
    check for all packets if they are incoming or outgoing (probably
    by checking the MAC addresses) and use elements without prefix
    for reporting the incoming packets and elements with "post"
    prefix for reporting the outgoing traffic.
  - We must define an information element with a "post" prefix for
    almost all the non-post elements in sections
      - 5.3 IP Header Fields (31 elements)
      - 5.4 Transport Header Fields (16 elements),
      - 5.5  Sub-IP Header Fields (19 elements)
      - 5.7  Min/Max Flow Properties (11 elements)
      - 5.9  Per-Flow Counters (12 elements)
    currently, only 13 of them are defined.
  - We cannot report bidirectional flows anymore, if our observation
    point does not cover all interfaces.  If we measure at a single
    interface, then we cannot aggregate the packet and octet counters
    of a bi-directional flow, because for one direction we must use
    the non-prefix counter and for the other direction we must use
    the prefix counter.

  Advantages of solution 1:
  - The concept is clean: no prefix for actually measured traffic
    prefixes for flow properties that are obtained by other means.
  - We need prefixes only if middleboxes are involved and supported
    by the metering process.  We do not need prefixes in all other
    cases, particularly not for for simple bidirectional measurements
    or for unidirectional measurements of outgoing traffic.

  Disadvantages of solution 2:
  - We need two prefixes
  - We might end up with a higher total number of elements

Thanks,

    Juergen
-- 
Juergen Quittek        [email-masked]       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

--On 7/17/2005 8:24 PM +1200 Nevil Brownlee wrote:

> Hi Juergen et al:
>
>> There is a problem with the semantics of 'post' in the info model.
>> The additional text tries to select one of them.  It applies well
>> to postMCastPacketDeltaCount, postMCastOctetDeltaCount,
>> postMCastPacketTotalCount, and postMCastOctetTotalCount.
>>
>> However, it does not fit well to the semantics we had so far for
>> postOctetDeltaCount, postOctetTotalCount, packetDeltaCount,
>> postPacketDeltaCount.
>>
>> I expect this to become a longer discussion.  I will try to describe
>> my point of view in another email.
>
> I get the feeling that this issue needs to be resolved before we submit
> the draft to IESG, alas.  Juergen, Benoit, Paul, et al., can we try
> to get a new consistent pair of drafts (protocol and info) done this
> week, please?  We're into the 2-week draft cutoff for the Paris IETF now,
> so they'll have to be published on the IPFIX web site - i.e., please
> email them to Dave, as well as internet-drafts.
>
> Cheers, Nevil
>
> -----------------------------------------------------------------------
>    Nevil Brownlee                 Computer Science Department | ITSS
>    Phone: +64 9 373 7599 x88941           The University of Auckland
>    FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand
>
>
> -------------------------------------------------
> This mail sent through University of Auckland
> http://www.auckland.ac.nz/

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Benoit Claise <[email-masked]>
Date: Wed, 20 Jul 2005 14:01:00 +0200

Juergen and all,

Thanks for the detailed email. It will ease the discussion.

You see this pre and post prefix problem from the point of view of the 
observation point only.
This is fine because we have in RFC 3917:

   "All measurements must be conducted from the point of view of the
   observation point."
Btw, I think that this statement should appear in [IPFIX-ARCH]. I took me quite some time to locate this sentence as I thought it was in one of current draft already.

However, I see the problem differently: before and after the packet 
treatment at the observation point.
I will show that this view exclude the solution 1, leads to the natural 
selection of slightly modified solution 2, i.e. solution 3

Remember the flow definition, in which the packet treatment is clearly 
mentioned:

      A Flow is defined as a set of IP packets passing an Observation
      Point in the network during a certain time interval.  All packets
      belonging to a particular Flow have a set of common properties.
      Each property is defined as the result of applying a function to
      the values of:

      1.  One or more packet header field (e.g. destination IP address),
          transport header field (e.g. destination port number), or
          application header field (e.g.  RTP header fields RTP-HDRF
          [5].

      2.  One or more characteristics of the packet itself (e.g. number
          of MPLS labels)

      3.  _One or more fields derived from packet treatment_ (e.g. next
          hop IP address, output interface)

I see the "packet treatment" as the typical function of a middlebox. The 
definition could have been extended with for example the modified DSCP 
value.

So let me propose the solution 3 (let me refer to "solution 3" later on 
in this email):
 all flow properties that are exported represent the flow as it was
 when entering the IPFIX device except, if their name has the
 prefix "post".  Information elements without the prefix would
 describe flows characteristics of incoming packets and information 
elements with the "post"
 prefix would describe flows characteristics after packet treatment.

See inline.

>  means available at the IPFIX device.

I would say that it's not only useful, but it's a requirement.
If you don't allow to export after treatment I.E., you run into problems 
such as:
- exporting two records, from the ingress point and the egress 
observation points of your middlebox
- trying to combine the records, to match the initial flow. You're going 
to tell me that we could use the flow keys, but we don't always want to 
export the flow keys. Alternatively, we could use a flow ID, but this 
becomes way too complex.

>  observation. In this case they result from the reporting of

If you apply solution 3, it's up to the metering process at the 
observation point to evaluate whether or not he can report any "post" 
information.
All routers/switches/middlebox will have a different architecture (one 
metering process per interface, per combination of interfaces, per line 
card, per router, etc...) so the only solution is to trust the metering 
process based on its capabilities. Is the metering process able to 
report some after packet treatment info?

>  the other side.  

Not really. Remember "All measurements must be conducted from the point 
of view of the observation point."
So the observation point is not supposed to know that there is a 
previous observation point in the path.
 From the observation point point of view, it must report what is seen. 
Hence no "pre" prefixes are needed. Next question: is there any packet 
treatment at this observation point? If no, we don't export any "post" 
prefix I.E. If yes, and if we can report the values, we export some 
"post" prefix I.E.

> The current version of the info model suggests
>  is measuring at the incoming interface of a router.

The solution 3 would also apply if you would monitor traffic at 
different points in the forwarding path of your device.

> Still, we

Note that, in solution 3, I changed outgoing packets by "after packet 
treatment"

>  would be the number of outgoing multicast packets.

Yes.

>  of the DSCP before marking and preClassOfServiceIPv4 would deliver

Typo -> postClassOfServiceIPv4

>  observation point.  It may be the entire device.  

Exactly, this is a great advantage.

> Ambiguities

Advantage of "solution 3"
- the concept is simpler
- we only need one prefix

As solution 2 and 3 are almost similar, let me reply to the 
"disadvantage of solution 2" section

>    promiscuous mode. This traffic would be neither incoming nor

I don't see a problem, neither with solution 2 or solution 3. The NIC is 
the observation point, and

   "All measurements must be conducted from the point of view of the
   observation point."
So the traffic which is entering the observation point is considered as as incoming.
With solution 3, there is no packet treatment, so no "post" I.E.s are exported.
With solution 2, there is no outgoing packets, so no "post" I.E.s are exported.

>    prefix for reporting the outgoing traffic.

Is this a drawback? All the traffic entering the observation point is 
metered.
" The observation point is a location in the network where IP packets 
can be observed."
I don't consider this as a drawback for solution 2 and 3

>    currently, only 13 of them are defined.

Yes, this is true for solution 2 and solution 3.
What we agreed in the past is that people will request those as they 
need them.

>    the non-prefix counter and for the other direction we must use

True for solution 2 and solution 3 but I don't see how it's possible 
with the solution 1

>    or for unidirectional measurements of outgoing traffic.

This is a big drawback.
If I have a router forwarding traffic, I export a template with 
no-prefix. My monitoring application is happy.
Now, the operational team decides to add some DSCP re-marking 
capabilities in the router. Now my templates export the "pre" I.E. for 
the same information. Not sure my monitoring application will be happy.
Basically, depending on the (middlebox) features enabled on the router, 
I will export different I.E.s. This solution doesn't work.

>  - We need two prefixes

Basically we need "pre", "post" and no prefix. So we have 3 series of I.E.s

>  - We might end up with a higher total number of elements

- Another disadvantage. The choice of these pre, post, no prefix series 
of I.E.s depend so much on the architecture of the device and that you 
will have interoperability problem first of all, and the collector will 
have to know the architecture of the exporter in order to benefit from 
the exported I.E.s

The [IPFIX-INFO] draft has always been (almost) in line with solution 3 
until the recent addition in the version 8.

Regards, Benoit.