Subject: [AVT] draft-clark-avt-rtcpxr-video-02

From: Keith Lantz <[email-masked]>
Date: Tue, 11 Jul 2006 15:44:10 -0700

Alan & Amy:

As a follow up to my previous message re draft-clark-avt-rtcphr-02, 
here are some comments on rtcpxr-video-02, in page order:

- p. 1, Abstract: Much as I regret to say, you probably shouldn't use 
"VoIP" as a placeholder for "video over IP". It will inevitably lead 
to confusion with that other "V".

- pp. 2f., Section 2.1: My original comments on rtcphr-00 apply here, 
since this text was copied from that source. Those comments were as 
follows (with the caveat that the instances of "RTCP HR" below have 
been replaced by "RTCP XR" in the subject I-D):

>>        ----------->    --------RTP---------->   ------------->
>>    <A>             <B>                       <C>              <D>
>>        <-----------    <-------RTP----------- | <-------------
>>                                               |
>>                        <------RTCP HR---------|
>>
>>    With respect to RTCP HR report blocks generated by "C" in relation to
>>    the RTP stream from "B" to "C".
>
>Replace the period with a colon.
>
>>    (i) The term "External" is used to relate to the network connected to
>>    the other side of "this" endpoint (i.e. to the connection from "C" to
>>    "D").
>>
>>    (ii) The Local IP Endpoint is "this" endpoint (i.e. "C")
>
>Insert a period at the end of the sentence.
>
>>    (iii) The Remote IP Endpoint is the source for the RTP stream
>>    terminated at this endpoint, and for which packet/frame related
>>    metrics apply. (i.e. "B")
>
>Move period to after the ")" -- i.e. 'metrics apply. (i.e. "B")'
>  --> 'metrics apply (i.e. "B").'

- p. 3, Section 2.3: As above, all but the last sentence came from 
rtcphr-00. It should be updated consistent with the changes reflected 
in the equivalent section of rtcphr-02.

- p. 5, diagram Video/Audio Metrics sub-block: The two "A-V Delay" 
fields should be "A-V Skew". See below for an explanation.

         Section 3.2: "High Resolution Metrics" --> "Video Metrics"

- p. 6, Section 3.2.2: "An Map" --> "A Map"

- p. 7, Section 3.4.4: Insert period at end of sentence.

         Section 3.4.5: Ditto.

         Section 3.5.2: Ditto.

- p. 8, Section 3.5.5: Ditto.

         Section 3.5.6: Ditto.

- pp. 8f, Sections 3.6.3 thru 3.6.7: I'm a little leery of the 
definitions for these metrics, specifically the fact that they are 
all scores from 0 to 50. This doesn't correspond to any existing 
video quality metrics that I am aware of -- not that I know all of 
them. Where does this come from? VQmon/SA-VM? Some 
justification/reference/citation is in order.

         Also, "codec independent" --> "codec-independent" and
               "codec dependant" --> "codec-dependent"

- p. 9, Section 3.6.10: Insert period at end of sentence.

         Sections 3.6.11 & 3.6.12: These sections should be talking 
about "skew", not "delay" ... and should have periods at the end of 
their definitions. ;-)

         Section 3.7: "Playour" --> "Playout"

         Section 3.7.2: Insert period at end of sentence.

         Section 3.7.3: Ditto.

- p. 10, Section 3.7.4: Ditto.

- p. 11, Section 4.1.2: "An Map" --> "A Map"

         Section 4.2: This section is carried over from 
rtcpxr-video-00, but ... there is no reference to correlation tags in 
the diagrams for the configuration blocks. The text also refers to 
"high resolution VoIP metrics report blocks" rather than "video 
metrics blocks". So ... either this section is obsolete or the 
diagrams are incomplete.

- pp. 12f, Section 4.3: As per my comments on rtcphr-02, I find this 
section dissatisfying -- even more so than rctphr-02, in fact. 
Specifically, in addition to the same weak example as in rtcphr-02, 
there isn't sufficient explanation of why MOS-LQ, MOS-CQ, R-LQ, R-CQ, 
and "Audio Monitoring Algorithm" are included in a *video* metrics 
block. Nor is there sufficient explanation -- here or elsewhere, such 
that it can be leveraged -- of the distinction between "Video 
Quality" and "Transmission Quality". Sure, Telchemy, QoSmetrics, 
Psytechnics, et al. may all make this distinction, but you shouldn't 
rely on readers' knowledge of those (incompatible) products to fill 
in the blanks.

- Finally, also as per my comments on rtcphr-02:

>... a *complete* nit: There are many occurrences of "<text> however 
><more text>", where either (a) the "however" is not set off with 
>commas and/or (b) where "but" would seem more appropriate. Similarly 
>for "hence", "for example" and "finally". Edit as desired. ;-)

Regards, Keith

----------------
Keith Lantz, Ph.D.                        Voice: +1 (408) 902-3302
Cisco Distinguished Engineer              FAX:   +1 (408) 525-4971
Voice & Video Systems Architecture        Email: klantz (at) cisco.com
Cisco Systems, Inc.

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Wed, 12 Jul 2006 15:29:22 -0400

Comments on draft-clark-avt-rtcphr-02:

More discussion as to how this is used and what it is used for is needed.

"Cumulative" and "Interval" are defined.  However what duration should
be used in reporting values for "Alert" is not.  ("Alert" in general is
not specified).

	3.5.8 Burst duration
           The duration of bursts of lost and discarded Transport Units
           expressed in milliseconds.

Is that total, mean, median, ???  The gap value specifies 'The mean
duration' which I assume has the mathematical definition of 'arithmetic
mean'. 

>- pp. 8f, Sections 3.6.3 thru 3.6.7: I'm a little leery of the definitions
>for these metrics, specifically the fact that they are all scores from 0 to
>50. This doesn't correspond to any existing video quality metrics that I am
>aware of -- not that I know all of them. Where does this come from?
>VQmon/SA-VM? Some justification/reference/citation is in order.

Also, why are (all of) these required anyways?  That's just asking for
endpoints to fudge the results and drop random/fixed values in.  Quite
honestly, I have no idea how I'd calculate them, or why they'd (all) be
useful, let alone why I should throw lots of cycles at calculating them.

Most rate values don't mention how they're expressed (some specify
"binary fraction in 0:16 format", others "expressed as a binary fraction",
and others don't specify at all).

    3.6.8 Reserved

This should indicate what value "Reserved" should be set to.

Audio - There should be some discussion as to what audio is referred to by
audio values in this rtcp unit.  Since the rtcp is presumably (again I
don't think it's specified) on the video channel's rtcp port, it's not
clear which audio channel is being referred to, if there is more than one.
Shouldn't audio quality reports be on the audio RTCP?  Something should
define it in this spec - main audio channel, first audio channel, any audio
channel at the discretion of the receiver, Nth audio channel (and pass N),
etc.  Also, specify what to do if there is no audio.  0?  50?

>         Sections 3.6.11 & 3.6.12: These sections should be talking about
>"skew", not "delay" ... and should have periods at the end of their
>definitions. ;-)

Again, this ties into the "which audio" comments above.

As for RTCP timing, AVPF/early-RTCP should be mentioned, even if indirectly
("or other negotiated RTCP timing").

In 4.2 it references "correlation sub-block" but none is defined.  I think
you mean an algorithm sub-block with a map field indicating a correlation
tag.

It appears that there can only be a single correlation tag per RTCP, though
you can have 8 algorithm descriptors.  This seems ungainly and problematic
(what if you want an IMS identity and a SIP call-id both?)  Why not use
a more RTCP-like mechanism where blocks are self-describing instead of
using fixed bitmaps?  It does use more bits (in some cases, if there are
a lot of entries) but it's far more flexible and in many cases just
as efficient or close to.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]