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

From: Qin Wu <[email-masked]>
Date: Tue, 10 Jul 2012 20:19:22 +0800

On 10 July , 2012 8:02 PM, [email-masked] wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Metric Blocks for use with RTCP's Extended Report Framework Working Group of the IETF.
> 
> Title           : RTCP XR Report Block for Discard Count metric Reporting
> Author(s)       : Geoff Hunt
>                          Alan Clark
>                          Glen Zorn
>                          Qin Wu
> Filename        : draft-ietf-xrblock-rtcp-xr-discard-05.txt
> Pages           : 13
> Date            : 2012-07-10
> 
> Abstract:
>   This document defines an RTCP XR Report Block that allows the
>   reporting of a simple discard count metric for use in a range of RTP
>   applications.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-discard
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-05
> 
> A diff from previous version is available at:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-discard-05

[Qin]: One update according to the comments received in the WGLC.
The main change to previous version is based on the recent discussion and agreement on the list with Shida, 
Dan, Alan, Varun and in the section 3.2, definition and description
about Discard Type. Some text is added to clarify how to report each of discard type or combination of 3 discard types.

One remaining issue is raised by Alan, which is about whether we should add some texts to explain 
the causes of duplicated packets discards in the draft.

---

From: Varun Singh <[email-masked]>
Date: Tue, 10 Jul 2012 16:30:59 +0300

> about Discard Type. Some text is added to clarify how to report each of discard type or combination of 3 discard types.

The explanation is not very clear on which "three discard types" to
ignore or consider. The "three discard types" occurs twice in the
sentence but I am not sure which three discard types it means.

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.

----
We have 4 discard types and 16 possible combinations, but we want to
limit the combination of (DT=3) to just with (DT=0), which brings the
number of valid cases to 9. I think the above text captures those 9
cases.

Regards,
Varun

> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

-- 
http://www.netlab.tkk.fi/~varun/

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Jul 2012 14:54:18 +0000

Hi,
________________________________________
发件人: Varun Singh [[email-masked]]
发送时间: 2012年7月10日 21:30
到: Qin Wu
Cc: [email-masked]
主题: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-discard-05.txt

NEW TEXT:

----

[Qin]: Your proposed change looks good to me.

Regards,
Varun

---

From: Qin Wu <[email-masked]>
Date: Wed, 25 Jul 2012 14:49:17 +0800

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).
"
Hope this can close the remaining issue. We will discuss this proposed new section in the Vancouver meeting but also good to listen to your opinion before the meeting.

Regards!
-Qin WU

---

From: Colin Perkins <[email-masked]>
Date: Wed, 25 Jul 2012 08:58:48 +0100

> (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…

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.

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 26 Jul 2012 02:26:29 +0200

+1

... but (question to Colin) - do you believe that this reference needs
to be Normative? 

Dan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Colin Perkins
> Sent: Wednesday, July 25, 2012 10:59 AM
> To: Qin Wu
> Cc: [email-masked]
> Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-
> 05.txt
> 
> > Based on Alan's proposal to the open issue mentioed below, we like
to
> add one new section after SDP signaling section as follows:
> > "
> > 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.
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
>

---

From: Alan Clark <[email-masked]>
Date: Wed, 25 Jul 2012 21:00:27 -0400

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" <[email-masked]> 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:
>> "
>> 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.

---

From: Qin Wu <[email-masked]>
Date: Thu, 26 Jul 2012 09:02:15 +0800

I tend to agree, and I prefer to put it as one informative reference.
Otherwise I am wondering why should this draft support duplication packet discard?

Regards!
-Qin
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Colin Perkins" <[email-masked]>; "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 26, 2012 8:26 AM
Subject: RE: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-05.txt

+1

Dan

to
to
loss
useful
should
that

---

From: Qin Wu <[email-masked]>
Date: Thu, 26 Jul 2012 12:50:54 +0800

I can see duplicating RTP packets in this way is different from what draft-ietf-avtext-rtp-duplication-00 is doing.
Duplicated RTP packet in this way is just a copy of the RTP packet that is duplicated and has the same SSRC,seqence number and
the whole payload while duplicated stream described in draft-ietf-avtext-rtp-duplication-00 is not.
One one hand, as discussed on the list, these injected duplicated traffic can be useful for the user to determine what
proportion of lost packets are being concealed by the process and improve receiving quality, 

On the other hand, inject too much such duplicated traffic may
challenge or overload network  which looks to me, is also applicable to the draft-ietf-avtext-rtp-duplication-00.
What am I missing? 

Regards!
-Qin
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 25, 2012 3:58 PM
Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-05.txt

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

---

From: "Roni Even" <[email-masked]>
Date: Thu, 26 Jul 2012 08:10:13 +0200

Hi,
I think it will be good to add it as an informative reference.
Roni

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Qin Wu
Sent: 26 July, 2012 3:02 AM
To: Romascanu, Dan (Dan); Colin Perkins
Cc: [email-masked]
Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-05.txt

I tend to agree, and I prefer to put it as one informative reference.
Otherwise I am wondering why should this draft support duplication packet
discard?

Regards!
-Qin
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "Colin Perkins" <[email-masked]>; "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 26, 2012 8:26 AM
Subject: RE: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-discard-05.txt

+1

Dan

to
to
loss
useful
should
that

---

From: Glen Zorn <[email-masked]>
Date: Thu, 26 Jul 2012 13:11:40 +0700

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

Why is PDV mentioned here?  

...

---

From: Colin Perkins <[email-masked]>
Date: Thu, 26 Jul 2012 08:09:31 +0100

No, I think informative is fine. I wouldn't like to see this draft as encouraging the sort of duplication Alan Clark suggests is common, since it causes problem that are solved by using the rtp-duplication draft method.

Colin

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

---

From: Qin Wu <[email-masked]>
Date: Thu, 26 Jul 2012 18:04:27 +0800

In my understanding, PDV actually means "Jitter". The effects of PDV in RTP stream can be countered by a properly sized play-out buffer at the receiver. If the packet arrives too late or too late, this packet will not be played-out and then regarded as discard. In other words, if PDV or 'network jitter' is not smoothed out, then the effect of PDV can not be coutered by playout buffer. That is why we say Early/late discards are regarded as a symptom of PDV.

Regards!
-Qin

----- Original Message ----- 
  From: Glen Zorn 
  To: [email-masked] 
  Sent: Thursday, July 26, 2012 2:11 PM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-discard-05.txt

  ... 

------------------------------------------------------------------------------

---

From: Alan Clark <[email-masked]>
Date: Thu, 26 Jul 2012 07:25:05 -0400

Because packet discard often results from high levels of jitter/PDV

Alan

---

From: Glen Zorn <[email-masked]>
Date: Fri, 27 Jul 2012 08:51:00 +0700

> Because packet discard often results from high levels of jitter/PDV

Sorry, I guess that I was _way_ too terse :-(; please allow me to
explicate:

             1. The acronym "PDV" is not expanded or used anywhere else
                in this document; given this, it's usage seems more like
                an afterthought than an integral part of the draft.
             2. There is, however, another WG draft discussing PDV
                reporting in some detail (although the acronym is never
                explicitly expanded in that document, either).  The
                proposed text says "Early/ late discards are usually
                regarded as a symptom of PDV due to congestion (or route
                changes)" which suggests that at least sometimes such
                discards are not a result of PDV.  Might it not be a
                good idea to be able to check the correlation (if any)
                between the number of earl/late discards and the level
                of jitter?  If so, maybe it would be a good idea to both
                reference draft-ietf-xrblock-rtcp-xr-pdv and suggest
                sending along the Packet Delay Variation Metrics Block
                as well.

...