Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt

From: [email-masked]
Date: Thu, 16 Jun 2011 02:21:10 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF.

	Title           : Monitoring Architectures for RTP
	Author(s)       : Qin Wu
                          Geoff Hunt
                          Philip Arden
	Filename        : draft-ietf-avtcore-monarch-03.txt
	Pages           : 23
	Date            : 2011-06-16

   This memo proposes an architecture for extending RTCP with a new RTCP
   XR (RFC3611) block type to report new metrics regarding media
   transmission or reception quality, as proposed in RFC5968.  This memo
   suggests that a new block should contain a single metric or a small
   number of metrics relevant to a single parameter of interest or
   concern, rather than containing a number of metrics which attempt to
   provide full coverage of all those parameters of concern to a
   specific application.  Applications may then &quot;mix and match&quot; to
   create a set of blocks which covers their set of concerns.  Where
   possible, a specific block should be designed to be re-usable across
   more than one application, for example, for all of voice, streaming
   audio and video.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt

---

From: Qin Wu <[email-masked]>
Date: Thu, 16 Jun 2011 17:29:15 +0800

Hi,:
In response to the recent comments and suggestion on the list, a new version of draft-ietf-avtcore-monarch is just submitted.
http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-03.txt
The diff is:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-03

Please check if your comments are addressed in this version.

Regards!
-Qin

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, June 16, 2011 5:21 PM
Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt

> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 21 Jun 2011 15:55:31 +0100

Qin,

This does address many of my comments on the earlier versions. Some quick comments on this draft:

- In Section 5.2, there is no need to report the CNAME, since this is redundant with RTCP SDES information. 

- Section 5.2 suggests reporting “the sequence number of the first packet of the RTP session”. A receiver cannot know what is the first packet of the session, only what was the first packet it received, so this should be clarified to “the sequence number of the first packet received in the RTP session”. The first sequence number received also becomes less useful after the sequence number space wraps around, so it might make sense to include a count of sequence number cycles since then.

- Section 5.3 discusses sending information that can be used to correlate an RTP source with non-RTP protocols. This seems like a reasonable thing to add. However, since it is describing the source, rather than providing a quality report, should this be an new RTCP SDES block type, rather than an RTCP XR block?

Colin

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

---

From: Qin Wu <[email-masked]>
Date: Wed, 22 Jun 2011 11:44:06 +0800

Hi,
----- Original Message ----- 
From: "Colin Perkins" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, June 21, 2011 10:55 PM
Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt

Qin,

[Qin] Agree, CNAME as the source of measured stream is overlapped with RTCP SDES.
I will remove CNAME as a example from this document. Also I think example for source of
measured stream could be other identity information in other non-RTP session.

- Section 5.2 suggests reporting “the sequence number of the first packet of the RTP session”. A receiver cannot know what is the first packet of the session, only what was the first packet it received, so this should be clarified to “the sequence number of the first packet received in the RTP session”. 

[Qin]: Yes, it looks reasonable to me.

The first sequence number received also becomes less useful after the sequence number space wraps around, so it might make sense to include a count of sequence number cycles since then.

[Qin]: Good suggestion. I am okay with this if there is no objection.

[Qin]: You ask a Good question, according to RFC5968, I am thinking which rule should be applied when choose the approprioate extension point.
It looks to me the information discussed in the section 5.3 is something like profile-specific extension to  RTCP SR and/or RR packets, so it seems 
both new RTCP XR and new RTCP message can be choosen. 

And the information here is something relevant to the quality report, So I am sure if it is better to choose to define new RTCP SDES instead of RTCP XR. 

Colin

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