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

[Varun Singh <[e-mail]>]

Hi Qin,

Comments inline.

On Wed, Jul 4, 2012 at 11:33 AM, Qin Wu <[e-mail]> wrote:
> Hi,Varun:
> On Thu, Jun 14, 2012 at 10:24 AM, Qin Wu <[e-mail]> wrote:
>> Hi,
>> I have reviewed RLE discard draft. It will be good to see RLE discard draft
>> getting in line with Discard draft.
>> Here are my comments to draft-ietf-xrblock-rtcp-xr-discard-rle-metrics:
>>
>
>> 9.Section 3, Paragraph 4:
>>
>> Discard draft support report packets discarded due to both early and late
>> arrival.
>>
>>  It is better for this draft to get in line with Discard draft. If it is in
>> this case, I suggest
>>
>>  to allocate 2bits for E flag and using 2 bits flag to support reporting
>> discarded due to
>>
>>  both early and late arrival.
>>
>>
>
> I sent an email about a month ago justifying why 1 bit maybe enough
> for discarded bytes. comment on that thread
> (http://www.ietf.org/mail-archive/web/xrblock/current/msg00550.html)
>
> [Qin]: I am wondering if the byte discarded due to packet duplication will be counted as "Discard".
> or the packet discarded due to duplicated RTP packets  will be counted as "Discard".
> If not, I agree with your clarification and proposal  in the email, i.e.,
> add more clarification in the introduction section to say when Discard RLE or byte Discard is used.
>

IMO, the Discard RLE and Bytes provides very high granularity of
information which is only needed for discard due to late and early
arrival. If an endpoint wants to report discard due to duplication etc
then it should consider using the Discarded Packets draft and not the
RLE draft.

I can clarify this in the introduction section.

>>
>> 10. Section 3, Paragraph 4:
>>
>> Are you emphasizing that packets reported in this block should be the
>> packets that is not
>>
>> properly received but discarded? If not, please clarify.
>>
>>
>
> The paragraph elaborates that two different blocks should be sent if
> the receiver wants to report both early discards and late discards.
> While a packet should not appear in both RLEs, but If it does then it
> may have been discarded due to some other reason and the reason is
> unknown.
>
> [Qin]: In the last sentence of Paragraph 4, you said:
> "
> Packets reported in both MUST be considered as
>  discarded without further information available, packets reported in
>  neither are considered to be properly received and not discarded.
>
> "
> I think the seond half of this sentence is not consistent with what we described
> in Discard and Burst Gap draft serials, i.e.,
> "
> A packet shall be classified as one of received (or OK), discarded or lost.
> "
> and what we agreed in the Discard draft, i.e.,
> the packet is thrown away due to duplication and redundancy should also
> be regarded as Discard.

The Discard RLE and bytes only classify as received (if not reported
in both early or late), discarded (if reported in either or both). To
report loss the endpoint should use Loss RLE.

Perhaps changing the last line to say (NEW TEXT):
No packet should appear in both early and lost Discard RLE.


> I think it is time to make this right.

>>
>> 12.Section 4, Paragraph 3, definition of "E"flag
>>
>> I think chunk is not defined in this report block format and should be
>> removed or replaced.
>>
>>
>
> clarified the sentence.
>
> [Qin]: Please see the following sentence in the section 4:
> "
>    The 'E' bit is introduced to distinguish between packets discarded
>    due to early arrival and those discarded due to late arrival.  The
>    'E' bit MUST be set to '1' if the chunks represent packets discarded
>    due to too early arrival and MUST be set to '0' otherwise.
> "
> I think the chunks should be replaced with "number of bytes discarded field"
>

Okay.

>>
>> I suggest remove "If the XR block is not preceded by a measurement identity
>> block
>> " with the following change:
>>
>> OLD TEXT:
>>
>> "
>>
>>    If the XR block is not preceded by a measurement identity block
>>    [I-D.ietf-xrblock-rtcp-xr-meas-identity] then the value indicates the
>>    bytes lost from from the start of the session (I=11), or the number
>>    of bytes discarded since the last RTCP XR Bytes Discarded block was
>>    received (I=10).
>>
>> "
>>
>> NEW TEXT:
>>
>> "
>>
>> If Interval Metric flag (I=11) is set, the value in the field indicates the
>>
>> bytes lost from the start of the session, if Interval Metric
>>
>> flag (I=01) is set, it indicates the number of bytes discarded since the
>>
>>  last RTCP XR Byte Discarded Block was received.
>>
>> "
>>
>
> Because of the two cases: I didn't make the suggested changes.
>
> [Qin]: My point is whatever XR block is preceded or not preceded,
> the value indication should always support two case ( interval and cumulative case).
> My proposal is to remove the first sentence.

Okay.

>
>> 18.Section 5.1, Paragraph 2:
>>
>> I think XR report is for regular RTCP reporting not used for timely
>> feedback.
>>
>> Therefore I am not sure Discard RLE report can be included in immediate or
>> early feedback packets as per RFC4585.
>
> IMO, the RFC3550 (Section 6.2) rules do not forbid shortening the RTCP
> reporting interval.
> From RFC3550: The RECOMMENDED value for the reduced minimum in seconds is 360
>       divided by the session bandwidth in kilobits/second.  This minimum
>       is smaller than 5 seconds for bandwidths greater than 72 kb/s.
>
> [Qin]: RFC3550 doesn't say you can change timing rule for RTCP XR.
> I think XR should follow the same timing rule as RTCP SR/RR.
>

I meant to say: XR follows timing rules of RFC3550, which allows
scaling of reporting interval (it does not allow sending early or
immediately as in RFC4585 but allows scaling).


> So the reporting endpoint should be able to scale the reporting
> interval. If this is not possible then how can we do it?
>
> [Qin]: Big question,:-)
>

Perhaps someone can clarify if the XRBLOCK can vary the RTCP interval.


Cheers,
Varun