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

[Qin Wu <[e-mail]>]

Hi, Varun:
----- Original Message ----- 
From: "Varun Singh" <[e-mail]>
To: "Qin Wu" <[e-mail]>
Cc: "xrblock" <[e-mail]>
Sent: Wednesday, July 04, 2012 6:06 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics


> 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.

[Qin]: Looks good to me.

> 
>>>
>>> 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.

[Qin]: Make sense.
> 
>> 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).

[Qin]: I think the scale level is up to bandwidth allocated for XR and the number of  receiver,
such scale degree is very limited if the available bandwidth is below miminal level.
> 
>> 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.

[Qin]: I think your should ask how much the XRBLOCK can vary the regular RTCP interval?

> 
> Cheers,
> Varun
>