Subject: Re: [xrblock] Fw: I-D Action:draft-wu-xrblock-rtcp-xr-quality-monitoring-08.txt

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 9 Jan 2012 15:44:27 -0800

(As an individual)

Hi Qin,
 
I read the draft and have the following comments:

Section 3.2.1-3, the descriptions of segment type, media type, and MoS
type are not consistent. Section 3.2.1 is missing the media type, and
the length of the MoS type field is not consistent.

Section 3.2.2, I agree with the editor's note that additional
information on the sub stream id field is needed.

Section 3.2.3, it is not clear to me how the Channel identifier will be
used. With 4 bits, you can identify the channel, but how do you express
how many channels there are. For example, don't you need to be able to
say, this is channel 2 of 5, or 1 or 2, etc.? Is the assumption that you
will always have a segment for each channel; therefore, the number of
channels is always defined implicitly by the number of channel segments?

As a general comment, I too would like to hear comments from those who
are doing application MoS calculations.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Qin Wu
> Sent: Friday, December 30, 2011 7:53 PM
> To: [email-masked]
> Subject: [xrblock] Fw: I-D Action:draft-wu-xrblock-rtcp-xr-quality-
> monitoring-08.txt
> 
> One more update to QoE metric reporting draft.
>  http://www.ietf.org/internet-drafts/draft-wu-xrblock-rtcp-xr-quality-
> monitoring-08.txt
> 
> This draft defines three segment type to support the following three
> different cases:
> 1. multimedia session where each type of media are sent in a separate
>    RTP stream or the layered video session where each layer video are
> sent in a separate RTP
>    stream.
> 2. the layered video session where multi-layer video are carried in
the
> same RTP stream
> 3. the multi-channel audio session where multi-channel voice data are
> carried in the same RTP stream
> 
> Comparing with the first case, the second and third cases more focus
on
> application specific MoS value reporting
> and but deal with the situation where the case 1 canot  deal with.
> 
> Comments and suggestions are welcome. It will be good to also hear the
> opinion from people
> who are doing VOIP application MoS calculation.
> 
> Regards!
> -Qin
> ----- Original Message -----
> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Saturday, December 31, 2011 11:38 AM
> Subject: I-D Action:
draft-wu-xrblock-rtcp-xr-quality-monitoring-08.txt
> 
> 
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >
> > Title           : RTCP XR Blocks for QoE metric reporting
> > Author(s)       : Geoff Hunt
> >                          Alan Clark
> >                          Qin Wu
> >                          Roland Schott
> >                          Glen Zorn
> > Filename        : draft-wu-xrblock-rtcp-xr-quality-monitoring-08.txt
> > Pages           : 18
> > Date            : 2011-12-30
> >
> >   This document defines an RTCP XR Report Block and associated SDP
> >   parameters that allow the reporting of QoE metrics for use in a
> range
> >   of RTP applications.
> >
> >
> > A URL for this Internet-Draft is:
> >
http://www.ietf.org/internet-drafts/draft-wu-xrblock-rtcp-xr-quality-
> monitoring-08.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-wu-xrblock-rtcp-xr-quality-
> monitoring-08.txt
> >
> > _______________________________________________
> > I-D-Announce mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Qin Wu <[email-masked]>
Date: Tue, 10 Jan 2012 13:05:46 +0800

Hi, Charles:
Thank for your detailed review, please see my replies inline.
----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Tuesday, January 10, 2012 7:44 AM
Subject: RE: [xrblock] Fw: I-D Action:draft-wu-xrblock-rtcp-xr-quality-monitoring-08.txt

(As an individual)

Hi Qin,

[Qin]: Unlike Multi-layer per SSRC segment and Multi-Channel per SSRC segment,
single stream per SSRC segment applies to all the media types or all the applications.
Thefore in the format of single stream per SSRC segment, we don't allocate one bit to 
distinguish between different media type.

As for the length of the MoS type field,  I am not sure I catch your comment.
since we allocate 4 bit for MoS type in all three type of segments we defined in this document.

[Qin]: I think the movtiation to define Sub stream identifier is to identify each layer using SSID from base layer, 
enhancement layer 1, enhancement layer 2, etc since SSRC is not sufficient to identify each of them when they 
share the same SSRC.

Maybe we can directly assign each layer with the integer value from 0 to n using the following mapping:
SSID     SSID description
 0           base layer
1            enhancement layer 1
2            enhancement layer 2
...............
n            enhancement layer n

[Qin]: That's a good question.
I think the number of channel should be indicated in SDP signaling to each associated RTP payload type.
One example is RFC3640 "RTP Payload Format for Transport of MPEG-4 Elementary Streams"
Please see the section 3.3.1 of RFC3640
"
3.3.  Usage of this Specification

3.3.1.  General

The general form of an rtpmap attribute is:

   a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
             parameters>]

   For audio streams, <encoding parameters> specifies the number of
   audio channels: 2 for stereo material (see RFC 2327 [5]) and 1 for
   mono.
"
.

Cheers,
Charles

the
on

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 11 Jan 2012 10:50:32 -0800

One more comment inline.

> From: Qin Wu [mailto:[email-masked]]
> Sent: Monday, January 09, 2012 9:06 PM
> To: Charles Eckel (eckelcu); [email-masked]
> Subject: Re: [xrblock] Fw: I-D
Action:draft-wu-xrblock-rtcp-xr-quality-
> Subject: RE: [xrblock] Fw: I-D
Action:draft-wu-xrblock-rtcp-xr-quality-
> defined in this document.

I was assuming the intent was for the segment structures defined in
sections 3.2.1 - 3.2.3 to share the same exact format for the fields up
to and including the CAlg field.  
This could be achieved by allocating space for the Media Type field for
the single stream per SSC segment even though would not be used.

Cheers,
Charles
 
> [Qin]: I think the movtiation to define Sub stream identifier is to
> identify each layer using SSID from base layer,
> enhancement layer 1, enhancement layer 2, etc since SSRC is not
> sufficient to identify each of them when they
> share the same SSRC.
>

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Jan 2012 10:04:47 +0800

Hi,
----- Original Message ----- 
From: "Charles Eckel (eckelcu)" <[email-masked]>
To: "Qin Wu" <[email-masked]>; <[email-masked]>
Sent: Thursday, January 12, 2012 2:50 AM
Subject: Re: [xrblock] Fw: I-DAction:draft-wu-xrblock-rtcp-xr-quality-monitoring-08.txt

> to and including the CAlg field.  

[Qin]: That is a good point if we need to include single stream per SSRC segment
with other segment types using the common format in the same draft. But these different 
segment type will not be present in the same XR Block since they deal with different use case
and has distinct usage.

> the single stream per SSC segment even though would not be used.

[Qin]: I like this proposal if we agree one draft is sufficient to 
address the single milestones.