Return-Path: 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 B900621F847C for ; Fri, 17 Aug 2012 05:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaBVMP9UiTbI for ; Fri, 17 Aug 2012 05:02:35 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 398F821F8471 for ; Fri, 17 Aug 2012 05:02:35 -0700 (PDT) Received: from [193.184.126.114] (helo=[10.0.6.194]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1T2LG6-00029s-jH; Fri, 17 Aug 2012 12:02:34 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_EB012F61-A3A0-404A-A732-FAD8FECC8DF2" From: Colin Perkins X-Priority: 3 In-Reply-To: <53777A58EAB149DDA8395907307F29B0@china.huawei.com> Date: Fri, 17 Aug 2012 15:02:32 +0300 Message-Id: References: <53777A58EAB149DDA8395907307F29B0@china.huawei.com> To: Qin Wu X-Mailer: Apple Mail (2.1278) Cc: xrblock@ietf.org Subject: Re: [xrblock] proposed change to discard draft for the issue: duplication packet discards 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 12:02:36 -0000 --Apple-Mail=_EB012F61-A3A0-404A-A732-FAD8FECC8DF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 16 Aug 2012, at 06:26, Qin Wu wrote: > Hi, > Discard count metric block draft > (http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-05) > supports reporting discards due to packet duplication. > =20 > It was suggested on the list to provide backgound information for = duplication packet discards. > In the Vancouver meeting,we re-discussed duplication packet discards = issue. It was pointed out > RTP packet duplication is not standard method and may break RTCP rules = when we do RTCP > statistics reporting.=20 > =20 > Combining these comments and incorporated proposed change from Varun = earlier on the list, > I propose the following change to the defintion part of Discard Type. > =20 > OLD TEXT: > " > An endpoint MAY send only one of the discard types (early, late, > duplication packets discard) in one RTCP report or choose to > report early (DT=3D1) and late (DT=3D2), duplication packets = discard > (DT=3D0) in separate block. It MAY also send the combined early = and > late discard type (DT=3D2) in one RTCP compound packet, but not = any > other combination of the three Discard Types. The endpoint MUST > not report the the total number of discarded packets covering = all > three discard types. Instead, two separate report blocks should > be used to carry duplication packets discard and the combined > early and late discard respectively. > " > NEW TEXT: > " > An endpoint MAY report only one of the above four discard types > blocks in an compound RTCP report in a reporting interval. It MAY > also report a combination of discard types in a compound RTCP report > but not all combinations are valid. The endpoint MAY report > duplicate packet discard (DT=3D0) block with any other discard (DT=3D1, > 2, or 3) block. Additionally, an endpoint MUST NOT report combined > discard (DT=3D3) block with early discard (DT=3D1) or late discard = (DT=3D2) > report block. Note that duplicating RTP packets using RTP > replication may lead to breakage of RTP media streams or RTCP rules. > In order not to disrupt all the RTCP statistics, it is recommended > to duplicate RTP packets as described in = [draft-ietf-avtext-rtp-duplication-00] > which will not cause breakage. > " This last sentence might be better written "In order not to disrupt RTCP = statistics, systems MUST NOT blindly duplicate RTP packets. If it is = essential to use duplication for robustness, the mechanism described in = [draft-ietf-avext-rtp-duplication-00] MAY be used since it avoids = breakage; however duplication is expensive, and is best avoided." Colin > Also in the meeting, Kevin raised we should add some text to clarify = the use cases and suggest to put into the section 1.4 applicability = section. > I propose the following change to the section 1.4 as follows: > OLD TEXT: > " > 1.4. Applicability >=20 > This metric is believed to be applicable to a large class of RTP > applications which use a jitter buffer. > " > NEW TEXT: > " > 1.4. Applicability > =20 > This metric is believed to be applicable to a large class of RTP > applications which use a jitter buffer. For example, in one reporting > interval, when packets were received but dropped from the jitter = buffer > due to either buffer underflow or buffer overflow or both, the discard = count > metric can be used to report such packet discards. In some other = cases(e.g., > desktop video conferencing), duplicating RTP packets using RTP = replication > may be used by media receiver for error concealment. > These duplicated packets can be counted as discards when they are not = used and > dropped by application from jitter buffer, in such cases, the discard = count > metric can be used to report such packet discards due to packet = duplication. > =20 > " > Regards! > -Qin > =20 > _______________________________________________ > xrblock mailing list > xrblock@ietf.org > https://www.ietf.org/mailman/listinfo/xrblock --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_EB012F61-A3A0-404A-A732-FAD8FECC8DF2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,
Discard count = metric block draft
supports reporting discards due to packet = duplication.
 
It was = suggested on the list to provide backgound information for duplication = packet discards.
In the = Vancouver meeting,we re-discussed duplication packet discards issue. It = was pointed out
RTP = packet duplication is not standard method and may break RTCP rules when = we do RTCP
statistics = reporting. 
 
Combining = these comments and incorporated proposed change from Varun earlier on = the list,
I propose the = following change to the defintion part of Discard = Type.
 
OLD = TEXT:
"
      An endpoint MAY send only one of = the discard types (early, late,
      = duplication packets discard) in one RTCP report or choose = to
      report early (DT=3D1) and late = (DT=3D2), duplication packets discard
      = (DT=3D0) in separate block.  It MAY also send the combined early = and
      late discard type (DT=3D2) in one = RTCP compound packet, but not any
      = other combination of the three Discard Types.  The endpoint = MUST
      not report the the total number = of discarded packets covering all
      = three discard types.  Instead, two separate report blocks = should
      be used to carry duplication = packets discard and the combined
      early = and late discard respectively.
"
NEW = TEXT:
"
      An endpoint MAY report only one of the above four discard = types
 blocks in an compound RTCP = report in a reporting interval. It = MAY
 also report a combination of discard types in = a compound RTCP report
 but not all = combinations are valid. The endpoint MAY = report
duplicate packet discard (DT=3D0) block with any other discard = (DT=3D1,
2, or 3) block. Additionally, an endpoint MUST = NOT report combined
discard (DT=3D3) block with early discard = (DT=3D1) or late discard (DT=3D2)
report block. Note that = duplicating RTP packets using RTP
replication may lead to breakage = of RTP media streams or RTCP rules.
 In order not = to disrupt all the RTCP statistics, it is = recommended
to duplicate RTP packets as described in [ which will not cause = breakage.
"

This = last sentence might be better written "In order not to disrupt RTCP = statistics, systems MUST NOT blindly duplicate RTP packets. If it is = essential to use duplication for robustness, the mechanism described in = [draft-ietf-avext-rtp-duplication-00] MAY be used since it avoids = breakage; however duplication is expensive, and is best = avoided."

Colin



Also in the = meeting, Kevin raised we should add some text to clarify the use cases = and suggest to put into the section 1.4 applicability = section.
I propose the = following change to the section 1.4 as follows:
OLD TEXT:
"
1.4.  Applicability

   This metric is believed to be = applicable to a large class of RTP
   applications which = use a jitter buffer.
"
NEW = TEXT:
"
1.4.  Applicability
 
This metric is = believed to be applicable to a large class of = RTP
 applications which use a jitter buffer. For = example, in one reporting
 interval, when = packets were received but dropped from the jitter = buffer
due to either buffer = underflow or buffer overflow or both, the discard = count
 metric can be used to = report such packet discards. In some other = cases(e.g.,
desktop video = conferencing), duplicating RTP packets using RTP = replication
may be used by media = receiver for error concealment.
These duplicated packets can be counted as = discards when they are not used and
dropped by application from jitter buffer, in = such cases, the discard count
metric can be used to report such packet = discards due to packet = duplication.
 
"
Regards!
-Qin
 
_______________________________________________<= br>xrblock mailing list
xrblock@ietf.org
https://www.ietf.or= g/mailman/listinfo/xrblock



-- 
Colin Perkins
= --Apple-Mail=_EB012F61-A3A0-404A-A732-FAD8FECC8DF2--