Re: [xrblock] proposed change to discard draft for the issue: duplication packet discards

[Colin Perkins <[e-mail]>]

Alan,

In that case: "It is not appropriate for systems to duplicate RTP packets for robustness, since this disrupts RTCP statistics. If it is essential to use packet duplication for robustness, the mechanism described in [draft-ietf-avext-rtp-duplication-00] can be used since they avoid breakage; however duplication is expensive, and is best avoided."

Colin



On 17 Aug 2012, at 15:30, Alan Clark wrote:
> Colin
> 
> Since this draft is simply reporting measurements it may not be the right place to make normative statements about the generation of RTP packets, although it could of course comment on the approach.  The “MUST NOT” should probably be incorporated in your draft related to RTP redundancy or into the next rev of RFC3550.
> 
> Best Regards
> 
> Alan
> 
> 
> 
> On 8/17/12 8:02 AM, "Colin Perkins" <[e-mail]> wrote:
> 
>> 
>> 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.
>>> 
>>> 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=1) and late (DT=2), duplication packets discard
>>>       (DT=0) in separate block.  It MAY also send the combined early and
>>>       late discard type (DT=2) 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=0) block with any other discard (DT=1,
>>> 2, or 3) block. Additionally, an endpoint MUST NOT report combined
>>> discard (DT=3) block with early discard (DT=1) or late discard (DT=2)
>>> 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 <http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-05#section-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
>>> 
>>> _______________________________________________
>>> xrblock mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/xrblock
>> 
>> 



-- 
Colin Perkins
http://csperkins.org/