Re: [AVT] I-D ACTION:draft-ietf-avt-rtcp-non-compound-01.txt
Randell Jesup <rjesup@wgate.com> Tue, 04 December 2007 22:33 UTC
Return-path: <avt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgKY-00062d-E8; Tue, 04 Dec 2007 17:33:30 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzgKX-00062C-1K; Tue, 04 Dec 2007 17:33:29 -0500
Received: from pr-66-150-46-254.wgate.com ([66.150.46.254] helo=exchange1.wgate.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzgKV-0005Nt-Kv; Tue, 04 Dec 2007 17:33:28 -0500
Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Dec 2007 17:33:27 -0500
To: Internet-Drafts@ietf.org
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-rtcp-non-compound-01.txt
References: <E1IzdET-0007eJ-Fu@stiedprstage1.ietf.org>
From: Randell Jesup <rjesup@wgate.com>
Date: Tue, 04 Dec 2007 17:33:26 -0500
In-Reply-To: <E1IzdET-0007eJ-Fu@stiedprstage1.ietf.org> (Internet-Drafts@ietf.org's message of "Tue, 04 Dec 2007 14:15:01 -0500")
Message-ID: <ybumysqay4p.fsf@jesup.eng.wgate.com>
User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-OriginalArrivalTime: 04 Dec 2007 22:33:27.0628 (UTC) FILETIME=[B06A68C0:01C836C5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b360bd6cb019c35178e5cf9eeb747a5c
Cc: avt@ietf.org, i-d-announce@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Randell Jesup <rjesup@wgate.com>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Errors-To: avt-bounces@ietf.org
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
rjesup@wgate.com
"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)
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt
- [AVT] I-D ACTION:draft-ietf-avt-rtcp-non-compound… Internet-Drafts
- Re: [AVT] I-D ACTION:draft-ietf-avt-rtcp-non-comp… Randell Jesup