Subject: [AVT] I-D ACTION:draft-ietf-avt-rtcp-non-compound-01.txt

From: [email-masked]
Date: Tue, 04 Dec 2007 14:15:01 -0500

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

	Title		: Support for non-compound RTCP, opportunities and consequences
	Author(s)	: I. Johansson, M. Westerlund
	Filename	: draft-ietf-avt-rtcp-non-compound-01.txt
	Pages		: 17
	Date		: 2007-12-4
	
This memo discusses benefits and issues that arise when allowing RTCP
   packets to be transmitted as non-compound packets, i.e not follow the
   rules of RFC 3550.  Based on that analysis this memo proposes changes
   to the rules to allow feedback messages to be sent as non-compound
   RTCP packets when using the RTP AVPF profile (RFC 4585) under certain
   conditions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtcp-non-compound-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-avt-rtcp-non-compound-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-avt-rtcp-non-compound-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Tue, 04 Dec 2007 17:33:26 -0500

95% of these are wording/english/clarity fixes.  The last one is a
paragraph that has me totally confused as to what is being discussed
(it's part of 5.4, one of the use-cases).

I had to stop before getting to the meat of the draft (section 6).

>From the text (1.x)
>The use of non-compound packets is not without issues.  This is
>discussed in Section 4.  These issues needs to be considered and is
>one motivation for this document.

Replace with:
The use of non-compound packets is not without issues.  These are
discussed in Section 4.  These issues needs to be considered and are
part of the motivation for this document.

>The connection to AVPF is motivated by the fact that non-compound
>RTCP is mainly intended for event driven feedback purposes and that
>the AVPF early and immediate modes makes this possible.
                                    ^^^^^
                                    make

>2.  RTCP Compound Packets
>
>   Section 6.1 in RFC3550 [RFC3550] specifies that an RTCP packet must
>   be sent in a compound packet consisting of at least two individual
>   packets, first an Sender Report (SR) or Receiver Report (RR),
>   followed by an SDES packet containing at least a CNAME Item for the
>   transmitting source identifier (SSRC).

SDES containing a CNAME is required, but it does NOT have to be the
second packet of the compound as strongly implied above.  At minimum, you
can have multiple RR's after the initial SR/RR, and in addition while
there's an implication that SDES should be before all non-SR/RR/SDES items,
it's arguable, and I would say that the spec does *not* mandate SDES come
after the SR/RR's.

Proposed:
   Section 6.1 in RFC3550 [RFC3550] specifies that an RTCP packet must be
   sent in a compound packet consisting of at least two individual packets,
   first an Sender Report (SR) or Receiver Report (RR), followed by
   additional packets including a mandatory SDES packet containing a
   CNAME Item for the transmitting source identifier (SSRC).

>  3.  The CNAME SDES item (See Section 6.5.1 of RFC 3550 [RFC3550])
>       exist to allow receivers to determine which media flows that
        ^^^^^
        exists
>       should be synchronized with each other between different RTP
>       sessions carrying different media types.  Thus it is important to
>       quickly receive this for each media sender in the session when
>       joining an RTP session.

>   4.  Sender Reports (SR) is used in combination with the above SDES
>       CNAME mechanism to establish inter media synchronization.  
                                     ^^^^^^^^^^^
                                     inter-media

or perhaps better:
   4.  Sender Reports (SR) is used in combination with the above SDES
       CNAME mechanism to synchronize multiple RTP streams, such as audio
       and video.

>3.  Benefits with non-compound packets
>
>   As mentioned in the introduction, most advantages of using non-
>   compound packets exists in cases when the available RTCP bit-rate is
>   limited.  This because non-compound packets will be substantially
                                                ^^^^
                                                are
>   smaller than a compound packet. 
                 ^^^^^^^^^^^^^^^^^^
                 compound packets.

>   2.  For links where the packet loss rate grows with the packet size,
>       smaller packets will be less likely to be dropped.  Example of
                                                          ^^^^^^^^^
                                                          An example
>       such links are radio links.  In the cellular world there exist
>       links that are optimized to handle RTP packets with speech and
>       these packets common sizes, the rationale behind this is to be
>       able to increase the capacity and coverage for voice services.

Very awkward.  How about:
       such links are radio links.  In the cellular world there exist links
       that are optimized to handle RTP packets sized for carrying
       compressed speech, which increases the capacity and coverage for
       voice services in a given wireless network.

>       Compound RTCP packets commonly are 2-3 times the size of a RTP
>       packet with compressed speech.  If the speech packet over such a
               ^^^^
               carrying
>       bearer have a packet loss probability of p, then the RTCP packet
               ^^^^
               has
>       will experience 1- (1-p)^x where x is the number of fragments the
                       ^^^^^^^^^^^
                       loss probability of 1-((1-p)^x),
>       compound packet will be split on the link layer, i.e. 2 or 3 commonly.
                                     ^                   ^^^        ^^^^^^^^^
                                     into                commonly   .

>   3.  In fixed links there are also benefits with sending feedback in
                                               ^^^^
                                               for
>       small non-compound RTCP.  One such application is those that use
>       RTCP AVPF in early or immediate mode to send frequent event
>       driven feedback.  Under these circumstances the use of non-
>       compound RTCP minimizes the risk that the RTCP bandwidth becomes
                                              ^^^               ^
                                              (remove)          use
>       too high during periods of intense adaptation feedback signaling.
                                   ^^^^^^^^^^^^^^^^^^
                                   heavy

>   4.  In cases when regular feedback is need, like in the profile under
                                          ^^^^^^^^^^
                                          needed, such as
>       development for TCP friendly rate control (TFRC) for RTP
>       [I-D.ietf-avt-tfrc-profile].  The size of compound RTCP can
                                   ^^^^^^
                                   , the
>       result in very high bandwidth requirements for the feedback in
                                                   ^^^^^^^^^^^^^^^^^^^
                                                   (remove)
>       case the round trip time is short.  For this particular
        ^^^^
        if
>       application non-compound RTCP gives a very substantial
>       improvement.

>   In cases when non-compound packets carry important and time sensitive
>   feedback both shorter serialization time and the lower loss
>   probability are important to enable the best possible functionality.
>   Having a packet loss rate that is much higher for the feedback
>   packets compared to media packets is not advantageous when for
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                                      hurts when
>   example trying to perform media adaptation to handle the e.g changed
    ^^^^^^^                                   ^^^^^^^^^^^^^^^^^^          
    (remove)                                  , for example to handle the
>   performance present at the cell border in cellular system.

In discussion of high-bandwidth streams:
>The benefit of non-compound packets in this case is limited, but exist. 
                                                                       ^
                                                                       s

>4.1.  Middle boxes
>
>   Middle boxes in the network may discard RTCP packets that does not
                                                              ^^^^
                                                              do
>   follow the rules outlined in section 6.1 of RFC3550.  The effect of
>   this might for instance be that compound RTCP packets makes its way
                                                          ^^^^^^^^^^^^^
                                                          would get
>   through while the non-compound feedback packets are lost.
                                                    ^^^
                                                    would be

>4.2.4.  Computation of avg_rtcp_size
>
>   Long intervals between compound RTCP packets and many non-compound
>   RTCP packets in between may lead to a computation of the value
                                                         ^^^      ^^^^
                                                         a         for
>   avg_rtcp_size that varies greatly over time.  A solution to this is
>   presented in Section 6.2.

>4.4.  RTP and RTCP multiplex on the same port
>
>   In applications that multiplexes RTP and RTCP on the same port, as
                    ^^^^^^^^^^^^^^^^
                    which multiplex
>   defined in [I-D.ietf-avt-rtp-and-rtcp-mux], care must be taken to
>   ensure that the de multiplexing is done properly even though RTCP
                    ^^^^^^^^^^^^^^^
                    de-multiplexing
>   packets are non-compound.

>5.  Use cases for non-compound RTCP
>
>   Below are listed a few use cases for non-compound RTCP.  It is worth
>   notice here that the current use of non-compound RTCP and the
>   applications is thoroughly specified in other standardization bodies
>   and for services that have a meaning inside each standardization
>   forum and is limited to a specific service such as PoC or 3GPP-MTSI.
>   A general definition of the use of non-compound RTCP for e.g control
>   plane or codec control signaling would probably need to be specified
>   inside the IETF.

Awkward.  Try:
5.  Use cases for non-compound RTCP

   Below are listed a few use cases for non-compound RTCP.  It is worth
   noting here that the current uses of non-compound RTCP are thoroughly
   specified in other standardization bodies and are limited to specific
   services such as PoC or 3GPP-MTSI.  A general definition of the use of
   non-compound RTCP for e.g control plane or codec control signaling would
   probably need to be specified inside the IETF.

>5.2.  Codec control signaling
>
>   Examples of codec control usage for non-compound RTCP is found in
                                                          ^^
                                                          are
>   [3GPP-MTSI].
>
>   Another example that can be used with non-compound RTCP are e.g the
>   TMMBR messages as specified in [I-D.ietf-avt-avpf-ccm] that signals a
>   request for a change in codec bitrate.  The benefit with transmitting
>   these messages is that the likelihood that they are transmitted
>   successfully in bad channel conditions can in some cases be
>   considerably higher than if they are put in larger compound RTCP.
>   This is critical as these messages predominantly occurs when channel
>   conditions are poor.

Awkward, needs many small changes.  Try:
   Another example of where non-compound RTCP is useful is e.g TMMBR
   messages as specified in [I-D.ietf-avt-avpf-ccm] which signal a request
   for a change in codec bitrate.  The benefit of non-compound RTCP for
   these messages is that in bad channel conditions, a non-compound RTCP
   can be considerably more likely to be received than larger compound RTCP
   messages.  This is critical as these messages predominantly occur when
   channel conditions are poor.

>5.3.  Feedback
>
>   The feedback scenario is best presented e.g as Video with generic
>   NACK.  In cases where the RTT is shorter than the receiver buffer
>   depth, generic NACK can be used to request retransmission of missing
>   information, thus improving play out quality considerably.  If the
>   generic NACK packets are transmitted non-compound the bandwidth
>   requirement will be minimal, enabling more frequent feedback.  Like
>   in the Codec control case it is crucial that these packets can be
>   transmitted as non-compound RTCP and also in some cases with as
>   little delay as possible.

   The feedback scenario is best presented as a Video stream with generic
   NACK.  In cases where the RTT is shorter than the receiver buffer depth,
   generic NACK can be used to request retransmission of missing packets,
   thus improving play out quality considerably.  If the generic NACK
   packets are transmitted as non-compound packets, the bandwidth
   requirement for RTCP will be minimal, enabling more frequent feedback.
   Like in the Codec control case it is important that these packets can be
   transmitted with as little delay as possible.  The RTCP bandwidth
   reduction and transmission speed are equally useful when retransmission is
   not used for loss recovery.

>   Another interesting use for non-compound RTCP is in cases when
>   regular feedback is need, like in the profile under development for
                        ^^^^^^^^^^
                        needed, such as
>   TCP friendly rate control (TFRC) for RTP [I-D.ietf-avt-tfrc-profile].
>   The size of compound RTCP can result in very high bandwidth
>   requirements for the feedback in case the round trip time is short.
                                  ^^^^^^^
                                  when
>   For this particular application non-compound RTCP may give a very
>   substantial improvement.

>5.4.  Status reports
>
>   One idea that is discussed is to transmit small measurement or status
>   reports in non-compound RTCP or to be able to split the parts of e.g
>   a minimum compound RTCP into its parts and transmit them separately.
>   The status reports can be used either by the endpoints of by other
>   network monitoring boxes in the network.
>
>   The benefit is that with some radio access technologies small packets
>   are more robust to poor radio conditions than large packets.
>   Additionally, with small (report) packets there is a smaller risk
>   that the report packets affects the channel that it reports upon.

   One idea proposed is to transmit small measurement or status reports in
   non-compound RTCP, and to be able to split the sub-packets of a minimum
   compound RTCP and transmit them separately.  The status reports can be
   used either by the endpoints or by other network monitoring boxes in the
   network.

   The benefit is that with some radio access technologies small packets
   are more robust to poor radio conditions than large packets.
   Additionally, with small (report) packets there is a smaller risk
   that the report packets will affect the channel that they report upon.

>
>   In principle it is perfectly OK to convey all sorts of information as
>   non-compound RTCP by means of e.g. a new RTCP packet type with a new
>   payload type.  It is for instance possible to specify a number of
>   measurement metrics in separate small non-compound RTCP.  However a
>   few issues needs to be considered.

Ummmm...  Huh?  

That's all I have time to review today.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)