[xrblock] Fw: Ralph Droms' Discuss on draft-ietf-xrblock-rtcp-xr-summary-stat-08:(with DISCUSS)

[Qin Wu <[e-mail]>]

Hi,
One issue raised in IESG review is about how to represent burst loss rate using 16-bit and how to
report total loss or burst lost rate of 1.0. In the current version -v08, we take OPTION1.
However Option1 introduces expensive multiply/divide operations by using 2^15-1 as multiplier,
Option 2 and Option 3 are proposed to avoid such expensive multiply/divide operations, i.e.,
using 2^15 or 2^16 as mutiplier and therefore only shift is needed.

However Option 3 just use 65535/65536 to approximate burst loss rate of 1.0 and can not be used to represent burst loss rate of 1.0.
Option 2 allow maximum value of 32768 and can use 32368/32368 to represent total loss.

Based on this discusion, I think we should go with Option 2. 
Please speak if you disagree or have other ways to address this. Thanks.

Regards!
-Qin
----- Original Message ----- 
From: "Barry Leiba" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: "Ralph Droms" <[e-mail]>; "The IESG" <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Wednesday, February 20, 2013 1:12 AM
Subject: Re: Ralph Droms' Discuss on draft-ietf-xrblock-rtcp-xr-summary-stat-08:(with DISCUSS)


> draft-ietf-xrblock-rtcp-xr-summary-stat-08
> 
> I've been thinking more about Ralph's and my DISCUSSes, and I see that
> there've been three suggested resolutions; I want to be sure we're all
> clear about what we're using and what the consequences of the change
> are.
> 
> There have been three suggestions: one that just fixes the text and
> leaves alone the algorithms for filling in the fields; one that
> changes the algorithms to multiplying by 32768 instead of 32767; and
> one that changes the algorithms to multiplying by 65536 instead of
> 32767.  Here are the proposed texts:
> 
> 
> OPTION 1 (fix text only):
> 
> NEW
>      The fraction of packets lost during bursts since the beginning of
>      reception, expressed as a fixed point number with the binary point
>      immediately to the right of the leftmost bit.  This value is
>      calculated by dividing Packets Lost in Bursts by Total Packets
>      Expected in Bursts, multiplying the result of the division by
>      32767 (0x7FFF), and keeping only the integer part.  The maximum
>      value is thus 7FFF.  Representing this as a formula:
> 
>      integer-part( (Packets Lost in Bursts / Total Packets Expected in
>                    Bursts) * 0x7FFF )
> 
>      If the measurement is unavailable, the value 0x8000 MUST be
>      reported.
> END
> 
> 
> OPTION 2 (fix text and multiply by 32768):
> 
> NEW
>      The fraction of packets lost during bursts since the beginning of
>      reception, expressed as a fixed point number with the binary point
>      immediately to the right of the leftmost bit.  This value is
>      calculated by dividing Packets Lost in Bursts by Total Packets
>      Expected in Bursts, multiplying the result of the division by
>      32768 (0x8000), and keeping only the integer part.  The maximum
>      value is thus 0x8000.  Representing this as a formula:
> 
>      integer-part( (Packets Lost in Bursts / Total Packets Expected in
>                    Bursts) * 0x8000 )
> 
>      If the measurement is unavailable, the value 0xFFFF MUST be
>      reported.
> END
> 
> 
> OPTION 3 (fix text and multiply by 65536):
> 
> NEW
>      The fraction of packets lost during bursts since the beginning of
>      reception, expressed as a fixed point number with the binary point
>      at the left edge of the field.  This value is calculated by
>      dividing Packets Lost in Bursts by Total Packets Expected in
>      Bursts, multiplying the result of the division by 65536 (0x10000),
>      limiting the maximum value to 65535 (to avoid overflow),
>      and keeping only the integer part.  The maximum value is thus
>      0xFFFF.
> 
>      integer-part( min(Packets Lost in Bursts / Total Packets Expected
>                    in Bursts) * 0x10000 )
> 
>      This field MUST be populated and MUST be set to zero if no packets
>      have been received.
> END
> 
> 
> Notes:
> 
> For option 1, this is just clarifying the text and not changing the
> algorithm, so there will be no effect on implementations, and the
> working group has already agreed to the algorithm.  On the other hand,
> the bit about the binary point isn't really correct because of the odd
> multiplier.
> 
> For option 2, the change in the multiplier makes the binary point
> accurate.  Because it's a change in the algorithm, it will make
> existing implementations slightly wrong and will require the working
> group to approve the change.  The degree of "wrong" is so small as to
> not really be significant, but the value for "unavailable" changes.
> 
> For option 3, the change in the multiplier makes the binary point
> accurate except in the case of total packet loss, and there's another
> bit of granularity in the value.  Because it's a change in the
> algorithm, it will make existing implementations slightly wrong and
> will require the working group to approve the change.  The degree of
> "wrong" is significant and the value for "unavailable" changes and is
> no longer distinguishable from "no packet loss".
> 
> Do I have the proposed text options correct?
> Which option are we going with (any of the three are OK with me)?
> Has the working group been consulted, and does it approve?
> 
> Barry