Subject: [IPFIX] [RFC 3917]Overload & Reliability requirements of Metering process

From: Sujay Gupta <[email-masked]>
Date: Thu, 1 Oct 2009 13:38:51 +0530

Hi,

While I do understand the need for reliability and overload requirements from Metering process as in Section 5.1./5.3 RFC 3917

Specifically these IE's;
ignoredPacketTotalCount, ignoredOctetTotalCount, notSentFlowTotalCount, notSentPacketTotalCount

Are there collector app's in the market interpreting them?

BR,
-Sujay

---

From: sujay gupta <[email-masked]>
Date: Wed, 21 Oct 2009 01:36:09 -0700

Hi All,

I have been trying to collect information from about the usage of IE's
for Overload/Reliability by collector apps.

I have not received any response till now.

Internally (for the OEM I work for) I had communicated with our Collector app's
design team asking them the same, there response is in the negative,
ie they do not make sense out of this data even if my switch sends it.

On the switch side, as an implementor  I have a problem to get these
parameters when my system is under O/L (ex: parameters like
ignoredcount or notsentcount)
Under O/L the system is not capable of keeping these counts.

In a similar lines, when my system is undergoing a soft restart (
control  layer restart) I would not be able to keep track of packets
not counted etc.

So what I am proposing ( and is possible) is that under these
conditions like O/L , soft restart the system (switch/router) can
easily send to the collector  at least the "duration under which it
was in the O/L/reset condition" . This information I am thinking would
be useful as a rough estimate of monitoring lost, canbe converted in
to number of packets not accounted for or may be used as an
unaccounted period by the collector.

Any thoughts from the group?

BR,
-Sujay

---------- Forwarded message ----------
From: Sujay Gupta <[email-masked]>
Date: Thu, Oct 1, 2009 at 1:08 AM
Subject: [IPFIX] [RFC 3917]Overload & Reliability requirements of
Metering process
To: "[email-masked]" <[email-masked]>

Hi,

While I do understand the need for reliability and overload
requirements from Metering process as in Section 5.1./5.3 RFC 3917

Specifically these IE’s;

ignoredPacketTotalCount, ignoredOctetTotalCount,
notSentFlowTotalCount, notSentPacketTotalCount

Are there collector app’s in the market interpreting them?

BR,

-Sujay

_______________________________________________
IPFIX mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: Gerhard Muenz <[email-masked]>
Date: Wed, 21 Oct 2009 10:56:16 +0200

Hi Sujay,

If you did not get an answer to
 > Are there collector app’s in the market interpreting them?
the answer is probably "no".

What you are proposing is a new Information Element, right?

IANA maintains the registry of standard IEs:
http://www.iana.org/assignments/ipfix/ipfix.xhtml

RFC5102 explains the procedure of adding new standard IEs:
http://tools.ietf.org/html/rfc5102#section-7
So, if you think that additional IEs are useful to be standardized, you 
can write a short Internet-Draft describing them.

Furthermore, you are free to define and use enterprise-specific IEs.

Regards,
Gerhard

-- 
Dipl.-Ing. Gerhard Münz
Chair for Network Architectures and Services (I8)
Technische Universität München - Department of Informatics
Boltzmannstr. 3, 85748 Garching bei München, Germany
Phone:  +49 89 289-18008       Fax: +49 89 289-18033
E-mail: [email-masked]    WWW: http://www.net.in.tum.de/~muenz

---

From: sujay gupta <[email-masked]>
Date: Wed, 21 Oct 2009 04:11:14 -0700

Thanks Gerhard,
That would be my intent.

BR,
-Sujay

On Wed, Oct 21, 2009 at 1:56 AM, Gerhard Muenz <[email-masked]> wrote:
> So, if you think that additional IEs are useful to be standardized, you can
> write a short Internet-Draft describing them.
>

---

From: Paul Aitken <[email-masked]>
Date: Wed, 21 Oct 2009 12:52:51 +0100

sujay,

> to number of packets not accounted for

No, it can't.

There are too many variables which the collecting process would have to 
know. eg how many active monitoring processes are there on the exporting 
device, and how much traffic are they each measuring on average?

The delay between measuring and exporting, and the flow lifetime on the 
switch will also be relevant, since you'll export some partially filled 
flows for some period of time after the reset.

> or may be used as an unaccounted period by the collector.

I think that's the only possibility. Let's not try to guess how much 
traffic was lost.

Cheers,
P.

-- 
Paul Aitken
Cisco Systems Ltd, Edinburgh, Scotland.

---

From: sujay gupta <[email-masked]>
Date: Wed, 21 Oct 2009 23:23:48 +0530

Hi Paul,

Thanks,

IMO it is safer to call the period as an outage period.
But then if the reset period is short, and the collector has
sufficient data points it may
very well model and interpolate the missing data. And if it does this
it may as well choose
to ignore the partial flows residing during the reset period, even if
the switch attempts to send it.

But then your email is helpful to point out collectors may not resort
to stats modeling.

BR,
-Sujay

On Wed, Oct 21, 2009 at 5:22 PM, Paul Aitken <[email-masked]> wrote:
> I think that's the only possibility. Let's not try to guess how much traffic
> was lost.
>
> Cheers,
> P.
>
> --
> Paul Aitken

---

From: Paul Aitken <[email-masked]>
Date: Wed, 21 Oct 2009 21:43:59 +0100

Sujay,

> sufficient data points it may very well model and interpolate the missing data.

You mean it will guess. That wouldn't be appropriate for many applications.

> And if it does this it may as well choose

My point is that it might be difficult for the collector to know which 
flows are partial, since those flows may have started before or during 
the outage and may be exported during or some time after the outage.

So, the implication is that the collecting process builds a model, 
receives notification of a monitoring outage, decides that certain flows 
are lower than expected, and adjusts them to fit the model.

If you propose sending such an outage notification, I'd be very 
interested to see a proposal for how the CP should model the EP - 
ideally backed up by some experimental evidence.

Cheers,
P.

---

From: "Juergen Quittek" <[email-masked]>
Date: Thu, 22 Oct 2009 21:26:40 +0200

Hi Paul,

Certainly, you cannot make a precise estimation how many packets
have been lost.

But as consumer of the exported flow information I would be
highly interested how long a router was restarting. Whether or
noit I can use this information for an estimate depends a lot
on the scenario.

Sujay,

Do you assume that the router is still forwarding packets
while restarting ?

Thanks,

    Juergen

---

From: sujay gupta <[email-masked]>
Date: Fri, 23 Oct 2009 01:00:08 -0700

Hi Juergen,

I am assuming a control plane restart, with the forwarding plane
running in the while. This would be probably a planned restart,
And in the overload condition where i would throttle the monitoring &
other features to keep the
essentials (like forwarding/switching/hello exchange) alive.
Of course there may be platforms with coupled forwarding / control
plane where seperation is not possible.

BR,
-Sujay