Subject: [rohc] ROHC statistics

From: Juergen Quittek <[email-masked]>
Date: Mon, 24 Jun 2002 23:11:15 +0200

Dear all,

I am still looking for suggestions on the statistics
to be collected for monitoring ROHC systems with the
ROHC MIB module:

  - What statistics do you collect with your
    implementation?
  - What statistics would be desirable to provide for
    ROHC operation and maintenance?
  - What statistics would be helpful for fault analysis?
  - What statistics were useful at ROHC interop events?

Please provide your input!

The current version of the MIB module collects the
following statistics:

Per compressor:
    total number of sent packets
        number of sent packets per header type
    number of received ACKs
    number of received NACKs
    number of received SNACKs
    mean compression ratio over all packets
    mean compression ratio over the last 16 packets

Per decompressor:
    number of received packets
        number of received packets per header type
    number of sent ACKs
    number of sent NACKs
    number of sent SNACKs

Collecting the number of packets per header type might
not be a good idea in some cases. Do you have better
ideas?

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

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Tue, 25 Jun 2002 09:12:42 +0100

Hi Juergen,

At least some partial answers, inline...

Cheers,

Mark.

>  - What statistics do you collect with your

Not many!  Packet counts; average compressed packet size; decompression 
failures / context repairs; that sort of thing.  We tend to maintain 
these per-CID, but then for the sort of testing we're doing at the 
moment, we don't tend to have many active CIDs.

>    ROHC operation and maintenance?

Probably ought to be something about CID usage -- number of flows and/or 
a high water mark?

I'll think about this one a bit more...

>  - What statistics would be helpful for fault analysis?

Hmmm... I suppose the most obvious one is the number of packets in and 
out (which at least tells you whether or not your ROHC instance is doing 
*something*)!  Counts of failed decompressions / received nacks gives 
some additional information.

I think knowing about failed decompression

Not so much a 'fault', but it might help to know the number of IR/IR-DYN 
packets per flow -- a high number of IR-DYN packets could indicate that 
the wrong profile is being used?

>  - What statistics were useful at ROHC interop events?

To be honest (and I can only spesak for myself, obviously), we haven't 
had the luxury of such abstract notions as statistics!  Generally we've 
been working with log-files; often at the level of individual bits...

If I were to extrapolate from the sorts of things that we look for in a 
logfile (at a relatively high level), then I suppose that this would be 
things like different packet types used (however, I'm not sure that this 
is actually a useful statistic to collect -- plus, see below...)

> Please provide your input!

It's not much, but it's a start...

> not be a good idea in some cases. Do you have better

I agree that collecting stats per header-type is probably not a good 
idea (or, at least, could lead to a very large amount of data with 
questionable value).  As suggested above, though, a more coarse-grained 
approach might be useful, e.g. to see how many IR/IR-DYN/CO packets have 
been sent.

At the decompressor, I think that it would useful to information about 
decompression failures (and context repair attempts) as well as the 
counts of acks/nacks/snacks.

I wonder if 'compression ratio' is the most useful statistic? 
Uncompressed headers can be variable length, so it might be hard to tell 
from just the ratio what my actual header overhead was.  Maybe 'mean 
uncompressed size' and 'mean compressed size' would be useful instead of 
/ as well?

>    Juergen

Just my immediate thoughts, to get the ball rolling!

More later...

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 27 Jun 2002 23:11:09 +0200

Mark,

Thank you very much for your input. Below please find new suggestion for
the revised set of statistics to be collected by the ROHC RTP MIB module.

If anybody has comments or requests for changes,
please give me your input.

    Juergen

ROHC MIB RTP statistics

Per channel:
    number of active flows
    total number of flows
    total number of packets coming out of the decompressors
    total number of packets sent to the compressors

Per RTP compressor:
    total number of sent packets
    number of sent IR packets
    number of sent IR-DYN packets
    number of received ACKs
    number of received NACKs
    number of received SNACKs
    mean compression ratio over all packets
    mean compressed packet size over all packets
    mean compression ratio over the last 16 packets
    mean compressed packet size over the last 16 packets

Per RTP decompressor:
    number of received packets
    number of received IR packets
    number of received IR-DYN packets
    number of decompression failures
    number of context repairs
    number of sent ACKs
    number of sent NACKs
    number of sent SNACKs

--On 25 June 2002 09:12 +0100 "West, Mark (ITN)" <[email-masked]> wrote:

> Not many!  Packet counts; average compressed packet size; decompression failures / context repairs; that sort of thing.  We tend to maintain these per-CID, but then for the sort of testing we're doing at the moment, we don't tend to have many active
> CIDs.
>
> Probably ought to be something about CID usage -- number of flows and/or a high water mark?
>
> Hmmm... I suppose the most obvious one is the number of packets in and out (which at least tells you whether or not your ROHC instance is doing *something*)!  Counts of failed decompressions / received nacks gives some additional information.
>
> Not so much a 'fault', but it might help to know the number of IR/IR-DYN packets per flow -- a high number of IR-DYN packets could indicate that the wrong profile is being used?
>
> To be honest (and I can only spesak for myself, obviously), we haven't had the luxury of such abstract notions as statistics!  Generally we've been working with log-files; often at the level of individual bits...
>
> If I were to extrapolate from the sorts of things that we look for in a logfile (at a relatively high level), then I suppose that this would be things like different packet types used (however, I'm not sure that this is actually a useful statistic to
> collect -- plus, see below...)
>
>
>>
> I agree that collecting stats per header-type is probably not a good idea (or, at least, could lead to a very large amount of data with questionable value).  As suggested above, though, a more coarse-grained approach might be useful, e.g. to see how
> many IR/IR-DYN/CO packets have been sent.
>
> At the decompressor, I think that it would useful to information about decompression failures (and context repair attempts) as well as the counts of acks/nacks/snacks.
>
> I wonder if 'compression ratio' is the most useful statistic? Uncompressed headers can be variable length, so it might be hard to tell from just the ratio what my actual header overhead was.  Maybe 'mean uncompressed size' and 'mean compressed size'
> would be useful instead of / as well?
>
>
>>    Juergen
>
>
> (Yes, I do know that my disclaimer is in an attachment.  And, no, I didn't ask for it to be that way)