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

Qin Wu <bill.wu@huawei.com> Mon, 09 July 2012 05:42 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D76611E8079 for <xrblock@ietfa.amsl.com>; Sun, 8 Jul 2012 22:42:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.642
X-Spam-Level:
X-Spam-Status: No, score=-4.642 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IAkG1FNOB5SS for <xrblock@ietfa.amsl.com>; Sun, 8 Jul 2012 22:42:12 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE6711E8073 for <xrblock@ietf.org>; Sun, 8 Jul 2012 22:42:12 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHO92263; Mon, 09 Jul 2012 01:42:36 -0400 (EDT)
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Jul 2012 22:41:59 -0700
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 8 Jul 2012 22:42:00 -0700
Received: from w53375 (10.138.41.149) by szxeml403-hub.china.huawei.com (10.82.67.35) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 9 Jul 2012 13:41:53 +0800
Message-ID: <A242B1A8CD4F4EF4AEEF1ACF7031C5F4@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Varun Singh <vsingh.ietf@gmail.com>
References: <CC170304.4745A%alan.d.clark@telchemy.com> <0E26DF73786C4186B0425F6A1C60191E@china.huawei.com> <FE289044-1933-420F-BFA6-A38B0B089D4A@ntt-at.com> <2D71AFAB4B0F4C688A6B1A5AA12F20FC@china.huawei.com> <CAEbPqrw6N6Li3oAbQHdMK6p_gBQeLZB9+zEVeB72vPzEMOJpKA@mail.gmail.com>
Date: Mon, 09 Jul 2012 13:41:52 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Cc: xrblock <xrblock@ietf.org>, draft-ietf-xrblock-rtcp-xr-discard@ietf.org
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Jul 2012 05:42:13 -0000

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

Regards!
-Qin
----- Original Message ----- 
From: "Varun Singh" <vsingh.ietf@gmail.com>
To: "Qin Wu" <bill.wu@huawei.com>
Cc: "Shida Schubert" <shida@ntt-at.com>; <draft-ietf-xrblock-rtcp-xr-discard@ietf.org>; "xrblock" <xrblock@ietf.org>
Sent: Friday, July 06, 2012 7:30 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discardandxrblock-rtcp-xr-discard-rle-metrics


> Hi Qin,
> 
> 
>> (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?
>>
>> [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.
> 
> 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.

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

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


>> 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]:Yes, possible, however the question do we need to enumerate all these combination if we don't have a clear use case.

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

[Qin]: Thanks, see above.

> 
> Regards,
> Varun
> 
> 
> 
> -- 
> http://www.netlab.tkk.fi/~varun/