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

[Varun Singh <[e-mail]>]

Hi Qin,

Apologies for the delayed response. I have applied most of the changes
proposed by you. However, the ones with comments below are still open.

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)

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

>
> 11.Section 4, Paragraph 2,definition of Interval metric flag
>
> Do you think this metric could be sampled metric or not?
>

No Discard is not a sample metric. See earlier response to Dan's
email. I could put a similar statement to the one in the discard draft
or have Interval field as 1-bit. I am okay with either.

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

>
> 13.Section 4, Paragraph 3, definition of "E"flag
>
> The last sentence of this paragraph said:
>
> "In caseboth early and late discarded packets shall be reported, two Bytes
>
>    Discarded report blocks MUST be included.
>
> "
>
> Why not expand 1 bit E flag into 2 bits flag to support reporting bytes
> discarded due to
>
>  both early and late arrival?
>
>

See above and earlier email discussing this.

>
> 14. Section 4, Paragraph 7:
>
> Shouldn’t the measurement information block is followed by related metric
> blocks in the same RTCP compound packet?

I don't want to mandate the use of the measurement interval. For my use-case,
not having the measurement identity does not affect its use. Therefore
the two cases:
1) implicitly by the time between two RTCP report or 2) explicitly
using the measurement identity.

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

>
> 17.Section 5, Paragraph 1:
>
> Suggest to change RTP node into RTCP reporting node (media receiver )
>
> and change sender RTP node into RTCP report collector (Media Sener)
>

I am not sure if the Report Collector is a standard usage because
these metrics can go end-to-end.

NEW TEXT:
This section describes the behavior of the reporting (= receiver) node
and the media sender.

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

So the reporting endpoint should be able to scale the reporting
interval. If this is not possible then how can we do it?

>
>
> 19.Section 5.2, last paragraph:
>
> Do we have compound RTCP RR? Did you mean
>
>  this report block is received with RR in the same RTCP compound packet?
>

I want to convey the following:
Keep the report block if the receiver
1. can calculate the interval between two compound RTCP reports, or
2. receives the measurement interval with the report block
in all other circumstances it should ignore the block.

Cheers,
Varun


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