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

From: Benoit Claise <[email-masked]>
Date: Mon, 01 Aug 2005 13:22:33 +0200

Hi Sven,

[Sorry for the delay]

> Hi Benoit,
>
> Benoit Claise schrieb:
>
>> If you take into account "All measurements must be conducted from the 
>> point of view of the observation point.", then it's the observation 
>> point will report what he thinks he's right after packet treatment (this 
>
>                             ^^^^^^
>
>> is solution 3 below). BTW, there is nothing more we can do from the 
>> observation point of view.
>
>
> I don't understand why you write "thinks". Either the treatment happens
> _inside_ of an observation "point" (a strange terminology in this 
> case, as
> a point has no dimension, but as you allow a point to be a group of
> points, it's possible), then it _knows_ what the packet looks like after,
> or it happens after the observation point, then pre and post is the same,
> whatever happens after.

Let me give an example.

A router composed of 2 line cards, each being an observation domain.
You observe the packets as they enter an interface of the line card. The 
DSCP is changed on the ingress line card.
So you export the DSCP (as observed), and the postDSCP (as changed by 
the middlebox function). The packets will now be forwarded to the egress 
line card.
Will the DSCP be again changed on the egress line card? Basically, from 
the "ingress line card" observation domain, you have no clue.
This is why I wrote "thinks". The metering process can only give 
information about what he knows.

Same thing for multicast. The multicast daemon, on the ingress line 
card, can tell you how many times the packet will be replicated. But 
will the packets be dropped on the outgoing interfaces (in a different 
observation domain), we don't know.

This is the meaning behind the sentence in RFC 3917:

   "All measurements must be conducted from the point of view of the
   observation point."
As the observation point definition is quite flexible, we can understand this:    
   "All measurements must be conducted from the point of view of the
   observation point or observation domain, but not outside the observation domain that contains the observation point."

>
>> No. Let me rephrase this.
>>  all flow properties that are exported represent the flow as it was
>>  when entering the _observation point_ 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, _from an observation point of view_.
>
>
> Ok, maybe now I get it, you are referring to the borders of the device? 

Border of the obsevation domain.
Does it make sense with my explaination before?

Regards, Benoit.

> So
> _if_ there is a post field, then the non-post/post field refers to how 
> the
> observation point guesses the packet looked like when entering/leaving 
> the
> device, and the real observed data is not necessarily reported? Do you
> mean that? Then the semantics of a field depends on the existence of
> another field... I'm not sure if I like that... ;-)
>
>
> Cheers,
>
> Sven
>

--
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: Sven Anderson <[email-masked]>
Date: Wed, 03 Aug 2005 20:36:35 +0200

Hi Benoit,

> observation domain), we don't know.

ok, thanks.

> Does it make sense with my explaination before?

I see, the observation domain defines the borders. So, for example,
sourceIPv4Address always refers to the state, when the packet is entering
the Observation Domain (means: measured at the first Observation Point),
even if the other exported Fields of the Flow refer to an Observation
Point after some NAT in the Observation Domain? Is this also true if there 
is no postSourceIPv4Address in the Flow-Template?

So if you just want to create flows from one observation point at one 
interface (e.g. libpcap/tcpdump), like the example Jürgen gave before, 
then you just reduce the OD to that single OP, and then the 
non-post-fields always refer to the state of the packet when passing that 
interface, no matter if it maybe entered the middlebox through another 
interface with a different state before?

Ok, but what if the DSCP changes _several_ times in a middlebox like in 
your example above, and I define the whole device as the OD and want to 
classify the flow by DSCP, postDSCP, post2DSCP, post3DSCP as seen on four 
different OPs? That's not possible then.

Thats why I would prefer a more flexible solution. The Template is a 
_ordered_ list of fields, so you could use that order to use the same 
Field several times for different OPs, for example. I think, I will 
explain my idea again as clear as possible in another mail to this list.

BTW: can somebody explain me, why it is useful, that an Observation Point 
can be a superset of other Observation Points?

Cheers,

Sven

-- 
Sven Anderson
Institute for Informatics - http://www.ifi.informatik.uni-goettingen.de
Georg-August-Universitaet Goettingen
Lotzestr. 16-18, 37083 Goettingen, Germany