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

[Kevin Gross <[e-mail]>]

I don't think it is necessary or appropriate to include this sort of value
judgement. What is expensive? What is necessary? At best, this is getting
tangential. I support the original wording of Qin's note though I think it
should be a separate paragraph and perhaps marked as a note.

As for the applicability discussion, what I'm looking for is: how will this
information be used by the entity or entities receiving it? It is already
clear from the other text in the draft _what_ is being reported. We don't
need to repeat that here. What needs to be clarified and justified is _why_
and to _whom_ this information is useful.

Clearly the information is useful to receivers who may adjust their jitter
buffers based on the information. But they can do this internally and I
don't see a need for them to transmit the raw information on which they're
acting.

Clearly the information is useful to network managers who may wish to tune
or troubleshoot their networks based on this feedback. But isn't SNMP, a
more appropriate reporting channel for these purposes?

To justify RTCP reporting of this information, I think it needs to be
demonstrably useful to the sender(s) and other receivers in the session. I
personally can't think of a direct use for this information by these
entities. If there is one (or two...), that's what I wish to see included
in the applicability discussion. If there isn't one, it calls into question
the need to finish this work.

Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org



On Fri, Aug 17, 2012 at 6:49 AM, Colin Perkins <[e-mail]> wrote:

> 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/
>
>
>
>
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock
>
>