Re: [IPFIX] review of draft-scholz-ipfix-rtp-audio-quality-00

Andrew Feren <[email protected]>
Newsgroups gmane.ietf.ipfix
Message-ID <[email protected]>
If in doubt just go with the unsigned64.  It is always possible for an 
implementation to use reduced length encoding and send fewer bytes if 
that implementation doesn't need all 8 bytes.

-Andrew


On 08/06/2012 08:14 AM, Michael Krüger wrote:
> Hi Hendrik,
>
>>>> 3.2.  rtpMOSClass1
>>>>
>>>>      Description:  Number of seconds the monitored stream had a MOS
>>>>         quality lower than 3.10
>>>>
>>>>      Data Type:  float32
>>> It's unusual to represent time as a float in IPFIX. Could you pick a
>>> suitable resolution (eg, milliseconds or microseconds) and export an
>>> integer?
>>>
>> The purpose of these IE items is to report the amount of full seconds
>> VoIP streams have been in either one of these 5 MOS classes. So I
>> suggest to change the type to unsigned64.
>>
>> Regards,
>> Michael
>>
> I did some math and really believe this should be an unsigned 64-bit
> value. Since the purpose of this IE is to provide an aggregation over
> all flows carried e.g. over a SIP trunk / carrier-interconnection the
> worst case would be potentially many millions of flows aggregated.
> Reporting the quality like this for a single flow is possible, but
> likely not the general application.
> A 32-bit resolution to report quality distribution of full day would
> only be sufficient for 49k flows or 24k bi-flows / calls. That doesn't
> seem to be a lot for quality reporting on a daily basis on a
> carrier-interconnection. Therefore unsigned64 with units = seconds seems
> for me the way to go.
>
> Regards,
> Michael
>
> _______________________________________________
> IPFIX mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipfix

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.