Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

[Varun Singh <[e-mail]>]

Hi Qin,


> (as contributor)
>
>   So does that mean that in a single report block, early and late can co-exist
> when it is described as type "both" but you can't have "other" + early,
> "other" + late or "other" + both?
>
> [Qin]: Report early means reporting overflow, Report late means  reporting underflow.
> Therefore it make sense to report underflow + overflow in one measurement interval if in that interval, sometimes overflow, sometimes underflow.
> Also you can report "other" +both since report "other" + both means reporting the total discarded packet due to all the reasons.

An endpoint MAY send only one of the discard types (early, late,
combined) in one RTCP report. It MAY also choose to report early
(DT=0) and late (DT=1) in separate block OR send the combined early
and late discard type (DT=2), but not any other combination of the 3
Discard Types. The endpoint MAY report the miscellaneous (DT=3)
discard type with any other discard type.

> other+ both can be used to calculate Gap Discard Rate metric in the Burst/Gap Discard Summary Statistics Block defined in  the draft-zorn-xrblock-rtcp-xr-al-stat.

Quoting an earlier email for al-stat (around 20 June):
>       where "number of packets discarded" is obtained from the RTCP XR
>       Discard Block [DISCARD] with "Discard Type" field set to 2
>       (i.e.,packets are discarded due to both early to be played out and late to be played out.)

Note that DT=2 or combined early and late is sufficient for the
summary statistics. The endpoint doesn't need to report "others".

> However I think it doesn't make sense to report "other"+ early or "other"+late since we don't have such use case for such combination.

I think this is possible if you have FEC or duplication and only
underflow or overflow occurs in an RTCP interval.

>
>  Thus, for the same reporting period, you would have separate reporting
> block for the above discarded packets combination? If that is the case,
> I think this should be explicitly stated in the section where the type is
> described.
>
> [Qin]: Make sense. Do you have any proposed text?
>

I wrote a semi-proposal text above, which tries to limit the cases but
it can be improved.

Regards,
Varun



-- 
http://www.netlab.tkk.fi/~varun/