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: <[e-mail]>; <[e-mail]>; "xrblock" <[e-mail]>
Sent: Wednesday, July 04, 2012 1:18 AM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics


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)

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

>
> 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.
I think it is time to make this right.

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

[Qin]: Okay.

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

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

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

[Qin]: Looks good to me.

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

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,:-)

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

[Qin]: Okay, I see.

Cheers,
Varun


-- 
http://www.netlab.tkk.fi/~varun/
_______________________________________________
xrblock mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/xrblock