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

From: Roni Even <[email-masked]>
Date: Wed, 20 Jul 2011 10:19:00 +0300

Hi,
Looking at the tag mechanism I agree with Colin that using it just to reduce
the size of the packet is not the important. 
Still I can see a different use case for the tag in order to group XR
reports as one entity. The monitoring architecture suggest dividing large
reports to small blocks and the assumption is the by the SSRC you define a
group of blocks per an application. Using the tag may provide another level
of freedom allowing more than one tag per SSRC and the tag defines a
reporting unit. This is a change from the current usage of tags and I am
bringing it to see if this usage is useful.

As for the correlation with non-rtp protocols I agree that SDES may be used
for it.

Regards
Roni Even
As individual

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Colin Perkins
> Sent: Tuesday, June 21, 2011 5:56 PM
> To: Qin Wu
> Cc: [email-masked]
> Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt
> 
> 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
> 
> 
> On 16 Jun 2011, at 10:29, Qin Wu wrote:
> 
> > 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
> >
> >
> >> 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
> >> _______________________________________________
> >> Audio/Video Transport Core Maintenance
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/avt
> >>
> > _______________________________________________
> > Audio/Video Transport Core Maintenance
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> 
> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Qin Wu <[email-masked]>
Date: Thu, 21 Jul 2011 15:14:35 +0800

Hi,
I think using tag has both disadvantage and advantage.
please see my below.
----- Original Message ----- 
From: "Roni Even" <[email-masked]>
To: "'Colin Perkins'" <[email-masked]>; "'Qin Wu'" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 20, 2011 3:19 PM
Subject: RE: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-03.txt

> the size of the packet is not the important. 
[Qin]: 
Yes, Using tag to associate identity block with other small blocks doesn't reduce size of RTCP if
1. Each RTCP XR packet contains one or more identity block 
2. Each identity block contains SSRC.
Therefore using tag may introduce extra overhead when it is used to distinguish different stream to be reported
On the other hand,, using tag  is redundant comparing with using SSRC since SSRC also can be used to distinguish 
the different stream to be reported.

If the identity block is not carried in each RTCP XR packet, e.g., at the start of session, you still need to parse each 
small bock with tag included and mapping  the tag to SSRC when receiving RTCP XR packet. It introduces processing
complexity. This is Con part of using tag I know.

> bringing it to see if this usage is useful.

[Qin]: Good point. Using SSRC enables grouping per stream
However the Pro of Using tag is may provide more subtle granularity for grouping e.g., 
a. distinguish the video stream and audio stream with the same SSRC by using different tag 
b. distinguish the base layer video stream and enhancement layer video stream with the same SSRC by using different tag.
Does these two cases mentioned above make sense?