Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-05.txt

[Alan Clark <[e-mail]>]

Colin

I agree that it is a very inefficient way to do error correction and does
the network no good at all - however some widely available commercial
desktop videoconferencing products do this (and I don't think they use
draft-ietf-avtext-rtp-duplication-00 as using the simplistic approach
requires no changes to the receiver).

It would be a good idea to refer to draft-ietf-avtext-rtp-duplication-00 as
an informative reference - however as I don't think this would result in any
duplicate packets being counted for the report (as the redundant stream uses
a separate SSRC) we should still identify that "non-standard" approaches may
give a high duplicate packet count. For example


(b) If the number of duplicate packets is very high then this may be due to
a simple and non standard form of RTP redundancy - simple RTP replication.
Properly architected RTP redundancy such as
draft-ietf-avtext-rtp-duplication-00 would not lead to a redundant packets
being reported as duplicates.
In the former (non-standard) case the number of duplicate packets can be
compared 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).

Regards

Alan

On 7/25/12 3:58 AM, "Colin Perkins" <[e-mail]> wrote:

> On 25 Jul 2012, at 07:49, Qin Wu wrote:
>> Based on Alan's proposal to the open issue mentioed below, we like to add one
>> new section after SDP signaling section as follows:
>> "
>> 6. Consideration for duplicate packets discards
>> 
>> Early/ late discards are usually regarded as a symptom of PDV due to
>> congestion (or route changes) however duplicate packets discards 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).
>> "
> 
> Duplicating RTP packets in this way for robustness is a very bad idea, since -
> as you note - it disrupts all the RTCP statistics. If you need to send
> duplicate streams, draft-ietf-avtext-rtp-duplication-00 describes how to do it
> without breakage. If you are going to mention duplication, I'd recommend
> including a reference to the working group draft to show how to do it right.