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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 2 Jul 2012 12:52:47 +0200

Hi Qin,

Thank you for your response. 

I am fine with your proposed resolutions with the exception of item 3.
The resolution proposed by you suggests including packets 'thrown away
before playout (e.g., packet duplication or redundancy)' in the discard
count metric. This would make the discard count metric inconsistent to
the discard rate metric defined in section 4.7.1 of RFC 3611 which
explicitly excludes duplicate packet discards. 

Am I the only one (exaggeratedly) concerned by this inconsistency? I
would love to hear other opinions. 

Dan
(speaking as contributor)

> -----Original Message-----
> From: Qin Wu [mailto:[email-masked]]
> Sent: Friday, June 29, 2012 6:33 AM
> To: Romascanu, Dan (Dan); Shida Schubert; xrblock
> Cc: [email-masked]
> Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-
> discardandxrblock-rtcp-xr-discard-rle-metrics
> 
> Hi,Dan:
> Thank for your valuable review to draft-ietf-xrblock-rtcp-xr-discard.
> Please see my replies inline.
> 
> Regards!
> -Qin
> ----- Original Message -----
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Shida Schubert" <[email-masked]>; "xrblock" <[email-masked]>
> Cc: <[email-masked]>;
<draft-ietf-xrblock-
> [email-masked]>
> Sent: Thursday, June 28, 2012 8:02 PM
> Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-
> discardandxrblock-rtcp-xr-discard-rle-metrics
> 
> 
> > (as contributor)
> >
> > I read the documents and they look almost ready for submission to
the
> > IESG.
> >
> > Here are a few comments on draft-ietf-xrblock-rtcp-xr-discard:
> >
> > 1. It would be useful I think to say more about the relation between
> > this metric and the discard rate metric defined in section 4.7.1 of
> RFC
> > 3611. Maybe calling the metric here Discarded Packets metric would
> help,
> > as both RFC 3611 and this document refer to 'discard metric' but the
> two
> > are different (one is rate, the other packets).
> 
> [Qin]: Good point, I propose to change 'discard metric' in this
document
> into 'discard count  metric' since
> abstract in this draft also uses 'discard count metric'.
> 
> To make this consistent with SDP parameter defined in this document, I
> also like to propose to do the following change
> OLD TEXT:
> "
>    xr-format =/ xr-pd-block
> 
>     xr-pd-block = "pkt-dscrd"
> 
> "
> NEW TEXT:
> "
>    xr-format =/ xr-pdc-block
> 
>     xr-pdc-block = "pkt-dscrd-count"
> 
> 
> "
> 
> > 2. In Section 3.1 diagram we use NBGD for Block Type, while the text
> in
> > Section 3.2 refers to the ND constant. We should get to a consistent
> > representation
> 
> [Qin]: It is a typo and will fix this by changing NBGD into ND.
> >
> > 3.
> >
> > Section 2.1:
> >
> >      A packet that arrives within
> >      this time window but is too early or late to be played out
shall
> >      be regarded as discarded.  A packet shall be classified as one
of
> >      received (or OK), discarded or lost.  The Discard Metric counts
> >      only discarded packets.
> >
> > Section 3.1 however includes:
> >
> >         00: packets are discarded due to other reasons than late
> >         arrival, early arrival, or both (e.g., duplicate, redundant
> >         packets).
> >
> > This seems inconsistent.
> 
> [Qin]: Good question. To make them consistent, I propose do the
> following change to Section 2.1
> OLD TEXT:
> "
>      A packet that arrives within
>       this time window but is too early or late to be played out shall
>       be regarded as discarded.  A packet shall be classified as one
of
>       received (or OK), discarded or lost.  The Discard Metric counts
>      only discarded packets.
> 
> "
> NEW TEXT:
> "
> A packet that arrives within
> 
> this time window but is too early or late to be played out
> 
> or is thrown away before playout (e.g., packet duplication or
> redundancy)
> 
> shall be regarded as discarded.  A packet shall be classified as one
of
> 
> received (or OK), discarded or lost.  The Discard Count Metric counts
> 
> only discarded packets.
> "
> 
> > 4. Is there any reasons for the Interval Metric flag (I) to be 2
bits,
> > rather than one bit, with the other one reserved?
> 
> [Qin]: Good question, I remembered we got a suggestion on the list
> before from Kevin Gross which suggested to
> remove Sampled metric related description from the definition of
> Interval Metric flag. Since Sampled metric is
> measured only at a particular time instant however metrics defined in
> this document is
> measured over one or several reporting intervals.To get in line with
the
> defintion
> of the Interval Metric flag in other XR BLOCK drafts and address your
> comment,
> I propose the following change to the defintion of the interval metric
> flag:
> 
> OLD TEXT:
> "
>    Interval Metric flag (I): 2 bits
> 
>       This field is used to indicate whether the Discard metric is an
>       Interval or Cumulative metric, that is, whether the reported
>       values applies to the most recent measurement interval duration
>       between successive metrics reports (I=10) (the Interval
Duration)
>       or to the accumulation period characteristic of cumulative
>       measurements (I=11) (the Cumulative Duration).
> 
> "
> NEW TEXT:
> "
>    Interval Metric flag (I): 2 bits
> 
> 
> 
>       This field is used to indicate whether the Discard Count Metric
is
> an
> 
>       Interval or Cumulative metric, Sample metric,that is, whether
the
> reported
> 
>       values applies to the most recent measurement interval duration
> 
>       between successive metrics reports (I=10) (the Interval
Duration)
> 
>       or to the accumulation period characteristic of cumulative
> 
>       measurements (I=11) (the Cumulative Duration) or is a
> 
>       sampled instantaneous value (I=01) (Sampled Value). In this
> document,
> 
>       Discard Count Metric is not measured at a particular time
instant
> but over
> 
>       one or several reporting intervals. Therefore Discard Count
Metric
> MUST not
> 
>       be chosen as Sampled Metric.
> 
> "
> 
> 
> > 5. number of packets discarded:
> >
> >> If the measured value exceeds 0xFFFFFFFD, the value 0xFFFFFFFE
> >      SHOULD be reported to indicate an over-range measurement.
> 
> > Why is this a SHOULD and not a MUST? Are there any exceptions?
> 
> [Qin]: No,  I will use MUST based on your comment.
> 
> > 6. In the IANA Considerations section:
> >
> > s/ The contact information for the registrations is/ The following
> > contact information is provided for all registrations in this
> document/
> 
> [Qin]: Okay.
> 
> >

---

From: Alan Clark <[email-masked]>
Date: Mon, 2 Jul 2012 07:49:24 -0400

Hi Dan

There are some implementations of RTP that send duplicate packets (in some
cases every packet) in order to provide a simple form of FEC. Reporting
duplicate packets as "duplicates" can allow the user to determine what
proportion of lost packets are being concealed by the process.  For example,
if I send 1000 packets but duplicate these in order to provide FEC - then
knowing that 900 duplicate packets were discarded tells me that the network
packet loss rate was 10%.

The reason that RFC3611 excluded duplicates was that the discard count was
intended to show what effect late/early arriving packets were having on the
quality perceived by the user.  Discarded duplicates have no effect whereas
a discarded late packet causes a "hole" in the decoded stream that has to be
repaired by PLC

It is useful to report discards of duplicate packets "separately from" the
early/late arrival discard count. They should not be combined into the same
counter.  This means that the early/late arrival discard count would be
consistent with RFC3611 but there is an additional count of discarded
duplicate packets

Best Regards

Alan

On 7/2/12 6:52 AM, "Dan (Dan)" <[email-masked]> wrote:

> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 2 Jul 2012 13:54:46 +0200

Thanks, Alan. I agree with you that discarded duplicates should be
reported separately. 

Regards,

Dan

> From: Alan Clark [mailto:[email-masked]]
> Sent: Monday, July 02, 2012 2:49 PM
> To: Romascanu, Dan (Dan); Qin Wu; Shida Schubert; xrblock
> intended to show what effect late/early arriving packets were having
on
> >> To make this consistent with SDP parameter defined in this
document,
> I

---

From: Qin Wu <[email-masked]>
Date: Tue, 3 Jul 2012 10:09:11 +0800

That's what I think, thank for your clarification.

Regards!
-Qin

---

From: Varun Singh <[email-masked]>
Date: Tue, 3 Jul 2012 17:48:09 +0300

Hi Dan,

Comments inline.

On Thu, Jun 28, 2012 at 3:02 PM, Romascanu, Dan (Dan)
<[email-masked]> wrote:
> (as contributor)
>
> I read the documents and they look almost ready for submission to the
> IESG.
>
[snip--discard draft, only keeping discard rle]

> Here are a few comments on
> draft-ietf-xrblock-rtcp-xr-discard-rle-metrics:
>
> 1. Runing idnits indicates that references to RFC 3551 and RFC 5760 are
> unused.

These have been removed. Also Discard and Burst Gap Discard are
changed to Informative References.

>
> 2. Section 3 - explain that the BT field MUST be assigned the DRLE value
> assigned by IANA as per the assignment required in the IANA
> Considerations section. Also there are three 'rsvd' bits in Figure 1,
> while the text mentions only 2.
>

The text should say 3 and the updated draft will correct that.

NEW TEXT:
     Block Type (BT, 8 bits) A Run-length encoded Discarded Packets Report
     Block is identified by the constant DRLE.
     [Note to RFC Editor: please replace DRLE with the IANA provided RTCP XR
     block type for this block.]

> 3. Section 4 - explain that the BT field MUST be assigned the BDR value
> assigned by IANA as per the assignment required in the IANA
> Considerations section.
>
NEW TEXT:
     Block Type (BT, 8 bits) A Run-length encoded Discarded Packets Report
     Block is identified by the constant BDR.
     [Note to RFC Editor: please replace BDR with the IANA provided RTCP XR
     block type for this block.]

> 4. Is there any reasons for the Interval Metric flag (I) to be 2 bits,

There is a question for consistency across documents. AFAIK the only place the
sampled metric is used is the PDV (Packet Delay Variation
http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-pdv-03) draft, but the
measurement-identity draft does not carry the sampled duration.
Moreover, we do not use the sampled metric so we could just use 1 bit
for the Interval metric.

If we use 1-bit I flag then, all other documents that do not use the
Sampled Metric
should also use 1-bit I flag, else we should use the 2-bit I flag and
mention that the
Sampled metric cannot be used.

An off-topic question: if the sampled value duration is not carried in the
measurement identity block, does it need to be specified somewhere
in the RFC or some reference?

Regard,
Varun

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

---

From: Varun Singh <[email-masked]>
Date: Tue, 3 Jul 2012 20:18:22 +0300

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 <[email-masked]> 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

---

From: Qin Wu <[email-masked]>
Date: Wed, 4 Jul 2012 16:33:26 +0800

Hi,Varun:
----- Original Message ----- 
From: "Varun Singh" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "xrblock" <[email-masked]>
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,

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

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

[Qin]: Okay.

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" 

[Qin]: Okay.

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

NEW TEXT:

[Qin]: Looks good to me.

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

[Qin]: Big question,:-)

[Qin]: Okay, I see.

Cheers,
Varun

---

From: Varun Singh <[email-masked]>
Date: Wed, 4 Jul 2012 13:06:02 +0300

Hi Qin,

Comments inline.

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

> the packet is thrown away due to duplication and redundancy should also

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 the chunks should be replaced with "number of bytes discarded field"

Okay.

> My proposal is to remove the first sentence.

Okay.

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

> interval. If this is not possible then how can we do it?

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

Cheers,
Varun

---

From: Qin Wu <[email-masked]>
Date: Thu, 5 Jul 2012 10:21:35 +0800

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

[Qin]: Looks good to me.

> No packet should appear in both early and lost Discard RLE.

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

---

From: Varun Singh <[email-masked]>
Date: Thu, 5 Jul 2012 17:38:55 +0300

Hi Qin,

Comments inline.

Cheers,
Varun

> such scale degree is very limited if the available bandwidth is below miminal level.

Based on my implementation, the reporting interval of RFC4585 over two
consecutive RTCP intervals averages to the RTCP interval of RFC3550.
For example: X marks the instant the RTCP report was sent, in RFC4585,
the RTCP interval following an early report compensates for the early
feedback.

RFC3550: X----------X----------X
RFC4585: X-----X---------------X

However, after re-reading the text in the draft:
      The receiver MAY send the Discard RLE Reports as part of the
      regularly scheduled RTCP packets as per RFC3550.  It MAY also
      include Discard RLE Reports in immediate or early feedback
      packets as per RFC4585.

I do not think the text requires a change:
The text proposes to the implementor that the receiver may send the
RTCP compound packet immediately/early if the two sides support it
else it should use the regular RTCP interval.

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

Consider an AVPF session which also supports XR report blocks.
If the receiver for whatever reason decides to send the compound RTCP
packet early
then the receiver can add the XR report block to the compound RTCP packet.

I dont see what forbids the endpoint supporting AVPF to not be able to
send XR blocks early.
Especially, since the size of the RTCP report affects the reporting
interval even in RFC4585.

---

From: Shida Schubert <[email-masked]>
Date: Fri, 6 Jul 2012 18:07:38 +0900

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

 Also, the draft reads like it is dependent on Measurement Identity based  
on the sub-section "number of packets discarded". If that is the case, the 
Mesurement Identity should become a Normative Reference. 
  
 Regards
  Shida

---

From: Qin Wu <[email-masked]>
Date: Fri, 6 Jul 2012 17:46:29 +0800

Hi,Shida:
Thank for your comments, please see my replies inline.

Regards!
-Qin
----- Original Message ----- 
From: "Shida Schubert" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Alan Clark" <[email-masked]>; "Dan (Dan)" <[email-masked]>; "xrblock" <[email-masked]>; <[email-masked]>
Sent: Friday, July 06, 2012 5:07 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

(as contributor)

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

[Qin]: Make sense. Do you have any proposed text?

[Qin]: Just to clarify, as described in the definition of "number of packets discarded",
"
Note that the number of packets expected in the period covered by

the metric (whether interval or cumulative) is available from the

difference between a pair of extended sequence numbers in the

Measurement Information block [MEASI], so need not be repeated in

this block.

"
So it is not ""number of packets discarded" but "the number of packets expected " that depends
on Measurement Identity. I propose to change subsection """number of packets discarded as follows:
OLD TEXT:
"
      Note that the number of packets expected in the period covered by

      the metric (whether interval or cumulative) is available from the

      difference between a pair of extended sequence numbers in the

      Measurement Information block [MEASI], so need not be repeated in

      this block.

"
NEW TEXT:
"
      Note that the number of packets expected in the period associated with

      this metric (whether interval or cumulative) is available from the

      difference between a pair of extended sequence numbers in the

      Measurement Information block [MEASI], so need not be repeated in

      this block.

"
  
 Regards
  Shida

---

From: Alan Clark <[email-masked]>
Date: Fri, 6 Jul 2012 06:51:42 -0400

Shida

You could have all three types of discard occurring within a single stream.
For example - if RTP replication is used for resilience then every interval
would have the same number of duplicate/other packets as data packets and if
there is a high level of jitter then there would also be late packets, early
packets or both.

Best Regards

Alan

On 7/6/12 5:07 AM, "Shida Schubert" <[email-masked]> wrote:

>> To: "Dan (Dan)" <[email-masked]>; "Qin Wu" <[email-masked]>; "Shida
>> Schubert" <[email-masked]>; "xrblock" <[email-masked]>
>> Subject: Re: [xrblock] WGLC for
>> draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics
>> 
>> 
>>> Hi Dan
>>>

---

From: Varun Singh <[email-masked]>
Date: Fri, 6 Jul 2012 14:30:06 +0300

Hi Qin,

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

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.

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

---

From: Varun Singh <[email-masked]>
Date: Fri, 6 Jul 2012 14:34:35 +0300

> there is a high level of jitter then there would also be late packets, early

I agree that one of early, late or others or any combination of the
three is a valid reporting case.
Perhaps there needs to be only a clarification on when to use early
and late or combined early and late.

Regards,
Varun

---

From: Shida Schubert <[email-masked]>
Date: Sat, 7 Jul 2012 09:13:45 +0900

So my question was..

 From what I can read, currently we have four types. 

 1. early ony
 2. late only
 3. both (late / early)
 4. other (discarded to duplicate etc.)

 According to my understanding based on Qin's response.

 When there is an occurrence of 4 along with 1,2 or 3, you 
need to have 2 report blocks.

 1 and 4, 2 and 4 or 3 and 4.. since we don't have a way 
to express these combination currently.. 

 This is based on my assumption that other is distinguished 
from early or late Or is it used when duplicate packet arrives 
early or late? 

 Regards
  Shida

---

From: Qin Wu <[email-masked]>
Date: Mon, 9 Jul 2012 12:38:20 +0800

Hi, Alan and all:
In the current version, we have already supported reporting the total number of discarded packets covering all three types,
i.e.,
(a). report both+ other(i.e.,duplication)

Besides, we also in this version support 
(b). reporting early
(c). reporting late
(d). reporting both early and late

Now the issue raised by Shida is:
Do we need to support other combination including 
(e). report other + early
(f). report other + late
also we may support
(g). report other independently.

My understanding is e, f, g are possible. But my concern is
Do we need to enumerate all the possible combination of all these three types
and support all these cases (i.e., from a to g)?

I think 'a' and 'd' are two most valuable use cases, since they both report 
1. the total number of discarded packet in case discards of duplicate packets are taken into account
2. the total number of discarded packet in case discards of duplicate packets are not taken into account.
Maybe the metric in both 'a' and 'd' can be used to calculate Gap Discard Rate metric, which is currently 
defined in another XR draft.

Regards!

---

From: Qin Wu <[email-masked]>
Date: Mon, 9 Jul 2012 13:41:52 +0800

Hi,Varun:
Thank for your proposal. Please see my replies inline.

Regards!
-Qin
----- Original Message ----- 
From: "Varun Singh" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Shida Schubert" <[email-masked]>; <[email-masked]>; "xrblock" <[email-masked]>
Sent: Friday, July 06, 2012 7:30 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

> discard type with any other discard type.

[Qin]: I am wondering whether we need to report the total number of discarded packets covering 'early','late' and 'other' or
just report 'other'  (i.e.,'discards of duplicate packets ') independently.
If we need to support both, does it mean we should expand 2 bits Discard type into 3 bits Discard Type?
So If we agree to support 'other' independently, I propose the following change to your proposal:
OLD TEXT:
"
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.
"
NEW TEXT:
"
An endpoint MAY send only one of the discard types (early, late, 
duplications packets discard) in one RTCP report. It MAY also choose to report early
(DT=0) and late (DT=1), duplication packets discard (DT=?) 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 the total number of discarded packets 
covering all three discard types.
"
If we agree not to support other indepently, I propose the following changes:
OLD TEXT:
"
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.
"
NEW TEXT:
"
An endpoint MAY send only one of the discard types (early, late, 
combine) 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).  The endpoint MAY report report the the 
total number of discarded packets combing early, late and duplication packets discard.
but not any other combination of the 3 Discard Types with duplication packets discard.
"
> summary statistics. 

[Qin]: It looks to me both DT =2 (combined early and late ) and 3 (combined early and late and other)
can be used to calculate Gap Discard Rate in the Summary statistics.
Please see forumlation of Gap Discard Rate

Gap Discard Rate =
      (number of packets discarded - Packets Discarded in Bursts) /
      (Packets Expected - Total Packets expected in Bursts)

If the "number of packets discarded" includes "discards of duplication packets",
"Packets Discarded in Bursts" should also include "discards of duplication packets".

If the "number of packets discarded" doesn't include "discards of duplication packets",
"Packets Discarded in Bursts" should also not include "discards of duplication packets".

In this way, we have two use case to calculate Gap Discard Rate.

>The endpoint doesn't need to report "others".

[Qin]: If we have this assumption, I agree with you DT =2 is sufficient for summary statistics.
Do we have this assumption that the endpoint doesn't report 'others' together with 'both', i.e., report both + others?

> underflow or overflow occurs in an RTCP interval.

[Qin]:Yes, possible, however the question do we need to enumerate all these combination if we don't have a clear use case.

> I wrote a semi-proposal text above, which tries to limit the cases but

[Qin]: Thanks, see above.

---

From: Qin Wu <[email-masked]>
Date: Mon, 9 Jul 2012 13:59:58 +0800

Hi,Shida:
Yes, currently we have four types. but the the 4 th type has been replaced with combine early, late and discarded due to duplication) in the current draft.
You are right, if we combine discards due to duplication with either 1, or 2, we need to have two report blocks.
My question, do we have the clear use case for such combinations you identify?

Regarding the assumption on whether it is used when duplicate packet arrives early or late,
I think you should also consider one duplicated packet arrives on  time and how is discareded due to that it is duplicated packet.

Regards!
-Qin
----- Original Message ----- 
From: "Shida Schubert" <[email-masked]>
To: "Varun Singh" <[email-masked]>
Cc: "Alan Clark" <[email-masked]>; "Qin Wu" <[email-masked]>; "xrblock" <[email-masked]>
Sent: Saturday, July 07, 2012 8:13 AM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

So my question was..

 1. early ony
 2. late only
 3. both (late / early)

 Regards
  Shida

---

From: Shida Schubert <[email-masked]>
Date: Mon, 9 Jul 2012 16:31:15 +0900

Qin;

 I was just simply asking a question that came up while I was reviewing the draft 
and I have no position on this. 

 So what you have currently is fine with me.  

 Regards
  Shida

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 9 Jul 2012 09:49:01 +0200

I agree. 

What is important as a result of this discussion is that the each metric
be identified and described in an accurate and detailed manner, and the
differences between what each metric comprises (and what is measured by
the RFC 3611 metric) are clearly articulated. To ensure interoperability
we must avoid confusions. 

Dan

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Shida Schubert
> Sent: Monday, July 09, 2012 10:31 AM
> To: Qin Wu
> Cc: xrblock
> Subject: Re: [xrblock] WGLC fordraft-ietf-xrblock-rtcp-xr-
>  I was just simply asking a question that came up while I was
reviewing
> the draft
> > Yes, currently we have four types. but the the 4 th type has been
> replaced with combine early, late and discarded due to duplication) in
> the current draft.
> > You are right, if we combine discards due to duplication with either
> 1, or 2, we need to have two report blocks.
> > I think you should also consider one duplicated packet arrives on
> time and how is discareded due to that it is duplicated packet.
> >
> > Regards!
> > -Qin
> > Cc: "Alan Clark" <[email-masked]>; "Qin Wu"
> <[email-masked]>; "xrblock" <[email-masked]>
> >>> You could have all three types of discard occurring within a
single
> stream.
> >>>> So does that mean that in a single report block, early and late
can
> co-exist
> >>>> Also, the draft reads like it is dependent on Measurement
Identity
> based
draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-
> metrics
> >>>>>
> >>>>>
> >>>>>> Hi Dan
> >>>>>>
> >>>>>> There are some implementations of RTP that send duplicate
packets
> (in some
> >>>>>> duplicate packets as "duplicates" can allow the user to
determine
> what
> >>>>>> The reason that RFC3611 excluded duplicates was that the
discard
> count was
> >>>>>> It is useful to report discards of duplicate packets
"separately
> from" the
> >>>>>>> before playout (e.g., packet duplication or redundancy)' in
the
> discard
> >>>>>>>>> I read the documents and they look almost ready for
submission
> to
draft-ietf-xrblock-rtcp-xr-discard:
> document, I
> >>>>>>>> received (or OK), discarded or lost.  The Discard Count
Metric
> counts
> >>>>>>>>
> >>>>>>>> only discarded packets.
> >>>>>>>> "
> >>>>>>>>
> >>>>>>>>> 4. Is there any reasons for the Interval Metric flag (I) to
be
> 2
> >>>>>>>> measured over one or several reporting intervals.To get in
line
> with
> >>>>>>>> I propose the following change to the defintion of the
interval
> metric
> >>>>>>>>    This field is used to indicate whether the Discard metric
is

---

From: Qin Wu <[email-masked]>
Date: Mon, 9 Jul 2012 15:59:26 +0800

Hi, Shida:
Just to clarify, the question you ask is very good question.
That's why Varun and I both proposed some text on the list try to fix the issue you raised.
Currently, one thing I am not sure is whether we should report 
(a) discards of duplication packets independently (As Alan suggested) 
or
(b) report discards of duplication packets combined with early and discard (i.e.,As I proposed in the current draft, DT=3 for all discard types). 

or we take both (a) and (b) in the draft.

Regards!
-Qin
----- Original Message ----- 
From: "Shida Schubert" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Varun Singh" <[email-masked]>; "Alan Clark" <[email-masked]>; "xrblock" <[email-masked]>
Sent: Monday, July 09, 2012 3:31 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

Qin;

 Regards
  Shida

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 9 Jul 2012 10:19:46 +0200

Speaking as contributor - I believe that taking both (a) and (b) would
be redundant. I have a slight preference for (a) but can use (b) as
well. 

Regards,

Dan

> Behalf Of Qin Wu
> Sent: Monday, July 09, 2012 10:59 AM
> To: Shida Schubert
> Cc: xrblock
> (b) report discards of duplication packets combined with early and
> discard (i.e.,As I proposed in the current draft, DT=3 for all discard
> types).
> 
> Cc: "Varun Singh" <[email-masked]>; "Alan Clark"
> <[email-masked]>; "xrblock" <[email-masked]>
reviewing
single
can
Identity
packets
determine
discard
"separately
the
submission
Metric
be
line
interval
is

---

From: Qin Wu <[email-masked]>
Date: Mon, 9 Jul 2012 17:33:38 +0800

Hi, Dan:
I tend to agree with you, since discards of duplication packets is measured based on both timing 
(i.e.,packet arrive time) and sequence number (i.e., identify duplication based on SN)while
the number of discards packets due to early, late or combining early and late is measured only based on timing.

Report combination of discards of duplication packets with any other discard type (i.e., early, late, combine) 
that use different measurement schemes seems to add complexity for measurment, report each discard type 
corresponding to single measurement sheme seems more straightfoward.

From this pespective, it seems as Varun said, DT=2 or combined early and late is sufficient for the
summary statistics. including "discards of duplication packets in the "Packets Discarded in Bursts" metric
add complexity to calculate Gap Discard Rate.

Regards!
-Qin
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; "Shida Schubert" <[email-masked]>
Cc: "xrblock" <[email-masked]>
Sent: Monday, July 09, 2012 4:19 PM
Subject: RE: [xrblock] WGLC fordraft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

Regards,

Dan

reviewing
single
can
Identity
packets
determine
discard
"separately
the
submission
Metric
be
line
interval
is

---

From: Varun Singh <[email-masked]>
Date: Mon, 9 Jul 2012 13:39:13 +0300

Hi Qin,

I thought the agreement for some time has been that the "others"
category was not a summation of everything but an independent category
for discards. That was one of the reasons why I had originally
proposed the order of discard types to be misc (DT=0) and then early
(DT=01), late (DT=10) and both (DT=11). However, I have no strong
opinion in the ordering.

I prefer the proposal (a) because there is the duplicate RTP streams
draft (http://tools.ietf.org/html/draft-ietf-avtext-rtp-duplication)
and while I have not implemented it, but an RTP monitors might want to
know which streams duplicate packets were discarded independently of
late/early arrivals.

Cheers,
Varun

---

From: Shida Schubert <[email-masked]>
Date: Tue, 10 Jul 2012 09:59:46 +0900

Hi Qin;

 I also think (a) is more useful. (b) seems to merge 
4 different semantics into 1 (discard + early, discard  + late, 
discard + both, discard only).

 I think all we need to do, is to add some text describing 
that misc and other 3 can not be in a same reporting 
block, but you can convey them by using 2 reporting 
blocks instead for the same reporting period. 

 Regards
  Shida

---

From: Alan Clark <[email-masked]>
Date: Mon, 9 Jul 2012 21:32:50 -0400

The key is that from a performance perspective you would need to look at
early/ late discards as a symptom of PDV due to congestion (or route
changes) however duplicate packets have quite different causes.

(a) A few duplicate packets can indicate some form of Layer 1/2 LAN problem.
This would not need to be an accurate measure - more of a general barometer.

(b) If the number of duplicate packets is very high then this may be due to
RTP replication - and if this is the case then you would want to compare the
number of duplicate packets to the number of received packets in the same
time interval. If the duplicate packet count is X% of the received packet
count this indicates that a (100-X)% packet loss rate is being "hidden" by
the replicated packets, and it is very useful to know the actual loss rate
(useful to indicate that replication should be kept "on" and helpful to know
that there are some network issues that need to be investigated).

It may be useful to explain this in the draft to provide some background

Regards

Alan 

On 7/9/12 8:59 PM, "Shida Schubert" <[email-masked]> wrote:

>>> (b) report discards of duplication packets combined with early and discard
>>> (i.e.,As I proposed in the current draft, DT=3 for all discard types).
>>> 
>>>> Yes, currently we have four types. but the the 4 th type has been replaced
>>>> with combine early, late and discarded due to duplication) in the current
>>>> draft.
>>>> I think you should also consider one duplicated packet arrives on  time and
>>>> how is discareded due to that it is duplicated packet.
>>>> 
>>>> Regards!
>>>> -Qin
draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metric>>>>>>>>
s
>>>>>>>>> on the

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Jul 2012 17:23:57 +0800

Hi,Varun:
----- Original Message ----- 
From: "Varun Singh" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "xrblock" <[email-masked]>
Sent: Monday, July 09, 2012 6:39 PM
Subject: Re: [xrblock] WGLC fordraft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

> for discards. 

[Qin]: Yes, you are right. 
I thought report everything in  some cases is very useful, e.g., calculate burst discard rate.
However I tend to agree with you report the combination of ealry and late is sufficient
for summary statistics merics calculation.

>That was one of the reasons why I had originally

[Qin]: Based on the agreement on the list, I think your proposed change looks reasonable to me now.
I will incorporate this change into the new version.

> I prefer the proposal (a) 

[Qin]: Good. 

>because there is the duplicate RTP streams

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Jul 2012 17:26:57 +0800

----- Original Message ----- 
From: "Shida Schubert" <[email-masked]>
To: "Varun Singh" <[email-masked]>
Cc: "Qin Wu" <[email-masked]>; "Alan Clark" <[email-masked]>; "xrblock" <[email-masked]>
Sent: Tuesday, July 10, 2012 8:59 AM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

Hi Qin;

[Qin]: Great, it seems now we have consensus to pick (a).

[Qin]: Good suggestion, I will see how to incorporate this
into the draft.

 Regards
  Shida

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Jul 2012 19:46:40 +0800

Hi, Alan:
Quoting what you said:
"
If the duplicate packet count is X% of the received packet
 count this indicates that a (100-X)% packet loss rate is being "hidden" by
the replicated packets
"
I am wondering how this packet loss rate is calculated or just a probability estimation?

As described in RFC3611, the packet loss rate is
" calculated by dividing the total number of packets lost  by
 the total number of packets expected
"
Would you like to clarify if packet loss rate you proposed conflict with RFC3611?

Also I am wondering how to incorporate your concept into this draft?
Maybe have a new section to talk about "Consideration for duplicated packets discard".
I am not sure. 

Regards!
-Qin
'----- Original Message ----- 
From: "Alan Clark" <[email-masked]>
To: "Shida Schubert" <[email-masked]>; "Varun Singh" <[email-masked]>
Cc: "Qin Wu" <[email-masked]>; "xrblock" <[email-masked]>
Sent: Tuesday, July 10, 2012 9:32 AM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

---

From: Varun Singh <[email-masked]>
Date: Tue, 10 Jul 2012 15:35:29 +0300

Hi Qin,

> Would you like to clarify if packet loss rate you proposed conflict with RFC3611?

Quoting the RFC3611 (Sec 4.7.1):

   loss rate: 8 bits
         The fraction of RTP data packets from the source lost since the
         beginning of reception, expressed as a fixed point number with
         the binary point at the left edge of the field.  This value is
         calculated by dividing the total number of packets lost (after
         the effects of applying any error protection such as FEC) by
         the total number of packets expected, multiplying the result of
         the division by 256, limiting the maximum value to 255 (to
         avoid overflow), and taking the integer part.  The numbers of
         duplicated packets and discarded packets do not enter into this
         calculation. (..)

Since the duplicate stream might reduce the number of lost packets the
loss rate is going to be lower. As per Alan's example, the X% loss
rate would disappear due to the redundant stream.

So what will appear in the discard rate for the two streams is:
Stream1: 0% discard rate (because this is baseline and all the packets
received here are played out)
Stream2 (redundant): (100-X)% discarded rate, because X% was used by
Stream1 for error-resilience and the rest of the packets were
discarded

Regards,
Varun

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Jul 2012 21:28:35 +0800

Hi, Varun:
----- Original Message ----- 
From: "Varun Singh" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Alan Clark" <[email-masked]>; "Shida Schubert" <[email-masked]>; "xrblock" <[email-masked]>
Sent: Tuesday, July 10, 2012 8:35 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

>         duplicated packets and discarded packets do not enter into this

[Qin]: RFC3611 (Sec 4.7.1), that's what I quoted above as well.
Based on how to calculate loss rate in the Sec4.7.1 of RFC3611,
the loss rate depends on the total number of packets **expected** rather than
the total number of packets **received**.
The total number of packet expected should include packets recieved, + packets lost + packets discarded.

> rate would disappear due to the redundant stream.

[Qin]: I fully understand the concept proposed by Alan. However what I am a little confused  is
in what he said, whether (100-X)% is "packet discard rate" or "packet loss rate".

> Stream1 for error-resilience and the rest of the packets were
 
[Qin] So you confirm that (100-X)% is discard rate rather than loss rate?
Also it seems here you are talking about FEC stream are transmitted with
main stream. The main stream will be repaired by the FEC stream.
In this case, I am wondering if we use the same method to calculate
loss rate or discard rate.

Also I am not sure if the number of packet in the FEC stream should be same
as the number of packets in the main streams?

---

From: Varun Singh <[email-masked]>
Date: Tue, 10 Jul 2012 17:02:44 +0300

> The total number of packet expected should include packets recieved, + packets lost + packets discarded.

The *expected* packets is just a difference in HSN sequence numbers of
the last and current reporting interval and not sum of received, lost,
and discarded (note the last line of the quoted paragraph, the
duplicate and discarded packets are ignored by the calculation).

So if X packets were lost, and the duplicate stream removed the X
losses. The loss rate may be 0, if the receiver interprets the
redundant stream as providing error resilience. I think the statement
in the RFC says "such as FEC", but it does not limit it to FEC.

> [Qin] So you confirm that (100-X)% is discard rate rather than loss rate?

Yes: (100-X)% is the discard rate and X% is the loss rate but may
appear as 0% loss rate.
However, this draft only reports discard packet counts and not discard rates.

But the rates can be calculated by the monitor=
Stream1: 0 duplicate packets discarded
Stream2: M-N duplicate packets discarded. M were the packets in the
interval and N were the packets used by Stream1, If the discard count
is sent in conjunction with the Measurement Identity block then the
monitor can calculate the discarded/expected which should be (100-X)%.

---

From: Qin Wu <[email-masked]>
Date: Wed, 11 Jul 2012 11:48:15 +0800

Hi, Varun:
One confusion I have is which discard rate or loss rate is applied to which stream 
when we talk about two streams ( i.e., duplicated stream and basic stream)? 
Please see my followup comments inline.

Regards!
-Qin
----- Original Message ----- 
From: "Varun Singh" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Alan Clark" <[email-masked]>; "Shida Schubert" <[email-masked]>; "xrblock" <[email-masked]>
Sent: Tuesday, July 10, 2012 10:02 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

> and discarded 

[Qin]: I think if there is no duplicated packet, the total number of packet expected should
 be equivalent to the sum of received,lost and discarded.

>(note the last line of the quoted paragraph, the

[Qin]: In my understanding, if duplicate packets are not ignored by the calculation.
packet expected will not be equivalent to the sum of received,lost and discarded.

Regarding why discarded packets are ignored, based on the same paragraph you quoted
"
         The numbers of
         duplicated packets and discarded packets do not enter into this
         calculation.  Since receivers cannot be required to maintain
         unlimited buffers, a receiver MAY categorize late-arriving
         packets as lost. 
"
I think the reason is the discarded packet due to late arriving is regarded as packet lost.
That's why they the discard packet are ignored.

> losses. The loss rate may be 0, 

[Qin]: I think 0% loss rate is applied to basis stream or main stream rather than duplicate stream.
I am wondering whether we also need to measure the loss rate of duplicate stream?
Do we assume there is no packet loss for duplicate stream?

>if the receiver interprets the

[Qin]: Agree.

> Yes: (100-X)% is the discard rate and X% is the loss rate but may

[Qin]: Again, I think (100-X)% discard rate is applied to duplicate stream.
X% of duplicate stream is used to conceal packet loss for main stream or 
basic stream.

This may make the loss rate of basic stream decreased into 0%. but maybe not since
some packet loss can not be concealed.

Also I think people may not care about the loss rate of duplicated stream or just assume packet loss in duplicated stream is zero.

> monitor can calculate the discarded/expected which should be (100-X)%.
[Qin]: If my understanding is correct, in your use case:
discard rate =(M-N)/M =(100-X)% 
(100-X)% discard rate is again applied to duplicated stream 2 rather than basic stream 1.
I am wondering how loss rate of stream 1 is affected X% duplicated stream 2?
What's the relationship between discard rate of stream 2 and loss rate of stream 1?
Also It is not clear to me if before stream 1 and stream 2 are sent to the receivers,
if the number of packets in the stream 1 is same as the number of packets in the stream 2?

---

From: Varun Singh <[email-masked]>
Date: Wed, 11 Jul 2012 14:41:56 +0300

Hi Qin:

Clarifications inline.

> That's why they the discard packet are ignored.

Yes, I think we both agree with each other. HSN_now - HSN_last =
received + lost + discarded, and ignore the duplicates.

> Do we assume there is no packet loss for duplicate stream?

yes for the example my assumption was that there is no packet loss in
the duplicate stream. There can be packet loss in the duplicate stream
as well.

> some packet loss can not be concealed.

Sure. if the same packet gets lost on both streams or the duplicate
stream is time-shifted and its packets arrive after playout.

I think the design assumption is that 1) packets of the two RTP
streams take different Internet paths, or 2) the duplicate stream is
timeshifted and interleaved with the base stream, thus the probability
of the same packet getting lost in both RTP streams is reduced.

> (100-X)% discard rate is again applied to duplicated stream 2 rather than basic stream 1.

If there is no loss on either path, all the packets in Stream1 will be
played out, but none of the packets in Stream2 will be played out.
i.e., all the Packets in Stream2 will be discarded because the
application believes they are duplicated. Perhaps at the RTP-level
there are no losses or discards but at the application level: Stream1
is loss=0, discard=0, while Stream2 is loss=0 but application level
discard due to duplication=100%.

If some packets in Stream1 got lost and they were not lost in Stream2,
the application use those packets from Stream2 and discard the rest. I
think that is what my above illustration was trying to capture.
Perhaps what needs more clarification is if the packets discarded by
the application in the RTP duplication case are reported as discarded
or not because the duplication is not by the network.

> if the number of packets in the stream 1 is same as the number of packets in the stream 2?

Some of the proposals are highlighted in
http://tools.ietf.org/html/draft-ietf-avtext-rtp-duplication-00

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Jul 2012 14:16:14 +0800

Hi, Varun:
Your clarification looks good to me. We are now on the same page.
See inline below.

Regards!
-Qin
----- Original Message ----- 
From: "Varun Singh" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Alan Clark" <[email-masked]>; "Shida Schubert" <[email-masked]>; "xrblock" <[email-masked]>
Sent: Wednesday, July 11, 2012 7:41 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics

> or not because the duplication is not by the network.

[Qin]: I think this issue you mentioned above that need to be clarified has been clarified by Alan in June 10 on the list.
http://www.ietf.org/mail-archive/web/xrblock/current/msg00618.html

The basic idea I interpret is:
(a). If the packet duplication is trivial and duplication is not due to RTP replication, 
the duplication should be ignored  in the calculation of loss rate.
(b) If the number of duplication packet is larger and RTP replication is used for error-resilience, 
the duplication should not be ignored by calculation of loss rate.
In either case (a) or (b), duplication packets discard should be reported since it may affect the actual loss rate
and we don't when it will happen. It is useful to report duplication packet discards.

> http://tools.ietf.org/html/draft-ietf-avtext-rtp-duplication-00

[Qin]: It seems not matter whether the number of packets in the stream 1 is same as the number of packets in the stream 2 or not.
Suppose the stream 2 is FEC stream, the number of packets in the stream 2 is not same as the number of packets in the stream 1
but may still be proportional to  the number of packets in the stream 1.

So if (100-X)% duplicated stream 2 compensates the total loss of stream 2, it seems  (100-X)% discard rate of stream 2 indicate actual loss 
rate of stream1. I guess this is what Alan said:
"
If the duplicate packet count is X% of the received packet
count this indicates that a (100-X)% packet loss rate is being "hidden" by
the replicated packets
"
and tend to agree with this.