One document matched: draft-wu-avt-retransmission-supression-rtp-06.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl'
href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-wu-avt-retransmission-supression-rtp-06"
ipr="pre5378Trust200902">
<front>
<title abbrev="Feedback Suppression">RTCP Report Extension for Feedback
Suppression</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Frank Xia" initials="F." surname="Xia">
<organization>Huawei</organization>
<address>
<postal>
<street>1700 Alma Dr. Suite 500</street>
<city>Plano</city>
<region>TX 75075</region>
<country>USA</country>
</postal>
<phone>+1 972-509-5599</phone>
<email>xiayangsong@huawei.com</email>
</address>
</author>
<author fullname="Roni Even" initials="R." surname="Even">
<organization>Huawei</organization>
<address>
<postal>
<street>14 David Hamelech</street>
<region>Tel Aviv 64953</region>
<country>Israel</country>
</postal>
<email>even.roni@huawei.com</email>
</address>
</author>
<date month="October" year="2010" />
<workgroup>Network Working Group</workgroup>
<abstract>
<t>In a large RTP session using the RTCP feedback mechanism defined in
RFC 4585, a media source or middlebox may experience transient overload
if some event causes a large number of receivers to send feedback at
once. This feedback implosion can be mitigated if the device suffering
from overload can send a feedback suppression message to the receivers
to inhibit further feedback. This memo defines RTCP extensions for
feedback suppression, to suppress NACK and FIR feedback requests. It
also defines associated SDP signalling."</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>RTCP feedback messages <xref target="RFC4585"></xref> allow the
receivers in an RTP session to report events and ask for action from the
media source (or a delegated feedback target). There are cases where
multiple receivers may initiate the same, or an equivalent message
towards the same media source. When the receiver count is large, this
behavior may cause transient overload of the media source,the network or
both. This is known as a "feedback storm" or a "NACK storm". One common
cause of such a feedback storm is receivers utilizing RTP retransmission
<xref target="RFC4588"></xref> as a packet loss recovery technique
based, sending feedback using RTCP NACK messages <xref
target="RFC4585"></xref> without proper dithering of the retransmission
requests.</t>
<t>Another use case involves video Fast Update requests. A storm of
these feedback messages can occur in conversational multimedia scenarios
like Topo-Video-switch-MCU <xref target="RFC5117"></xref>. In this
scenario, packet loss may happen on an upstream link of an intermediate
network element such as a Multipoint Control Unit(MCU). Poorly designed
receivers that blindly issue fast update requests (i.e., Full Intra
Request (FIR) described in <xref target="RFC5104"></xref>), can cause an
implosion of FIR requests from receivers to the same media source.</t>
<t>RTCP feedback storms may cause short term overload and, and in
extreme cases to pose a possible risk of increasing network congestion
on the control channel (e.g. RTCP feedback), the data channel, or both.
It is therefore desirable to provide a way of suppressing unneeded
feedback.</t>
<t>One approach to this, suggested in <xref target="DVB-IPTV"></xref>,
involves sending a NACK message from server to the client (or receiver).
However NACK is defined as a receiver report sent from a client to the
server and therefore exhibits a semantic mismatch when used as a
suppression indication from the server (or intermediary) to the client.
This document instead specifies a newly message for this function. It
further is more precise in the intended uses and less likely to be
confusing to receivers. It tells receivers explicitly that feedback for
a particular packet or frame loss is not needed and can provide an early
indication before the receiver reacts to the loss and invokes its packet
loss repair machinery.</t>
</section>
<section title="Terminology">
<t>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
<section title="Protocol Overview">
<t>This document extends the RTCP feedback messages defined in the
Audio-Visual Profile with Feedback (AVPF) and define the Feedback
Suppression message. The Feedback Suppression message asks a receiver to
not send feedback messages for particular packets (indicated by their
RTP sequence numbers) independent of whether the receiver detected the
packet loss or detected a need for a decoder refresh point).</t>
<t>In order to detect packet loss before the receivers perceive it, one
or more intermediate nodes may be placed between the media source and
receiver. These intermediates are variously referred to as Distribution
servers, MCUs, RTP translator, or RTP mixers, depending on the precise
use case. These intermediaries monitor for packet loss upstream of
themselves by checking RTP sequence numbers, just as receivers do. Upon
detecting (or suspecting) an upstream loss, the intermediary may send
Feedback Suppression message towards the receivers as defined in this
specification.</t>
<t>These intermediate nodes need to take into account such factors as
the tolerable application delay, the network dynamics, and the media
type. When the packet loss is detected upstream of the intermediary and
additional latency is tolerable, the intermediate node may itself send a
feedback message asking for the suspected lost packet or ask for the
correct decoder refresh point. Because it has already provided the
necessary feedback toward the source, the intermediate node can be
reasonably certain that it will help the situation by sending a Feedback
Suppression message to all the relevant receivers, thereby indicating
that the receivers should not themselves transmit feedback messages.</t>
<t>Alternatively, the media source may directly monitor the amount of
feedback requests it receives, and send feedback suppression messages to
the receivers.</t>
<t>When a receiver gets such a feedback suppression message, it should
refrain from sending a feedback request (e.g., NACK or FIR) for the
missing packets reported in the message. A receiver may still have sent
a Feedback message before receiving a feedback suppression message, but
further feedback messages for those sequence numbers will be suppressed
by this technique. Nodes that do not understand the feedback suppression
message will ignore it, and might therefore still send feedback. The
media source or intermediate nodes cannot assume that the use of a
feedback suppression request actually reduces the amount of feedback it
receives.</t>
<t>RTCP Feedback Suppression follows the same semantic model as RTCP
NACK - it conveys the packet receipt/loss events at the sequence number
level and considers missing packets as unrepaired. But unlike RTCP NACK,
the Feedback Suppression messages can be generated at RTP middleboxs and
sent to the corresponding receivers. Intermediaries downstream of an
intermediary detecting loss obviously SHOULD NOT initiate their own
additional feedback suppression messages for the same packet sequence
numbers. They may either simply forward the Feedback Suppression message
received from upstream, or augment (or replace) it with a feedback
suppression message that reflects the loss pattern they have themselves
seen.</t>
<t>Since feedback suppression interacts strongly with repair timing, it
has to work together with feedback to not adversely impact the repair of
lost source packets. In some cases where the loss was detected and
repair initiated much closer to the source, the delay for the receiver
to recover from packet loss can be reduced through the combination of
intermediary feedback to the source and feedback suppression downstream.
In all (properly operating) cases, the risk of increasing network
congestion is decreased.</t>
</section>
<section title="RTCP Feedback Report Extension">
<t>This document registers two new RTCP Feedback messages for Feedback
Suppression. Applications that are employing one or more loss-repair
methods MAY use Feedback Suppression together with their existing
loss-repair methods either for every packet they expect to receive, or
for an application-specific subset of the RTP packets in a session. In
other words, receivers MAY ignore Feedback Suppression messages, but
SHOULD react to them unless they have good reason to still send feedback
messages despite having been requested to suppress them.</t>
<section title="Transport Layer Feedback: NACK Suppression Report">
<t>The NACK implosion Suppression message is an extension to the RTCP
feedback report and identified by RTCP packet type value PT=RTPFB and
FMT=TBD.</t>
<t>The FCI field MUST contain one or more NACK Suppression Early
Indication (NSEI) entries. Each entry applies to a different media
source, identified by its SSRC.</t>
<t>The Feedback Control Information (FCI) for NSEI uses the similar
format of message Types defined in the section 4.3.1.1 of <xref
target="RFC5104"></xref>. The format is shown in <xref
target="fig2"></xref>.</t>
<figure align="center" anchor="fig2"
title="Message Format for the NSEI report">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PID | BLP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="SSRC (32 bits):"><vspace blankLines="1" />The SSRC
value of the media source that is requested to send the lost
packet.<vspace blankLines="1" /></t>
<t hangText="Packet ID (PID): 16 bits"><vspace blankLines="1" />
The PID field is used to specify a lost packet. The PID field
refers to the RTP sequence number of the lost packet.<vspace
blankLines="1" /></t>
<t
hangText="bitmask of proceeding lost packets (BLP): 16 bits"><vspace
blankLines="1" /> The BLP allows for reporting losses of any of
the 16 RTP packets immediately following the RTP packet indicated
by the PID. The BLP's definition is identical to that given in
<xref target="RFC4585"></xref>.<vspace blankLines="1" /></t>
</list></t>
</section>
<section title="Payload Specific Feedback: FIR suppression report">
<t>The FIR implosion Suppression message is an extension to the RTCP
receiver feedback report and identified by RTCP packet type value
PT=PSFB and FMT=TBD.</t>
<t>The FCI field MUST contain one or more FIR suppression Early
Indication (FSEI) entries. Each entry applies to a different media
source, identified by its SSRC.</t>
<t>The Feedback Control Information (FCI) for FSEI uses the similar
format of message Types defined in the section 4.3.1.1 of <xref
target="RFC5104"></xref>. The format is shown in <xref
target="fig3"></xref>.</t>
<figure align="center" anchor="fig3"
title="Message Format for the FSEI report">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seq nr. | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t><list style="hanging">
<t hangText="SSRC (32 bits): "><vspace blankLines="1" />The SSRC
value of the media source that is requested to send a decoder
refresh point.<vspace blankLines="1" /></t>
<t hangText="Seq nr:8bits">Command sequence number. The sequence
number space is unique for each pairing of the SSRC of command
source and the SSRC of the command target. The sequence number
SHALL be increased by 1 modulo 256 for each new request.<vspace
blankLines="1" /></t>
<t hangText="Reserved: 24 bits"><vspace blankLines="1" />All bits
SHALL be set to 0 by the media source and SHALL be ignored on
reception.<vspace blankLines="1" /></t>
</list></t>
</section>
</section>
<section title="SDP Signaling">
<t>A new feedback value “fss” needs to be defined for the Feedback Storm
Suppression message to be used with Session Description Protocol
(SDP)<xref target="RFC4566"></xref> using the Augmented Backus-Naur Form
(ABNF)<xref target="RFC4585"></xref>.</t>
<t>The "fss" feedback value SHOULD be used with parameters that indicate
the feedback suppression supported. In this document, we define two such
parameters, namely:<vspace blankLines="1" /><list style="symbols">
<t>"fsei" denotes support of fir suppression early indication
(fsei).<vspace blankLines="1" /></t>
<t>“nsei” denotes support of NACK suppression early indication.</t>
</list><vspace blankLines="1" />In the ABNF for rtcp-fb-val defined in
<xref target="RFC4585"></xref>, there is a placeholder called rtcp-fb-id
to define new feedback types. "fss" is defined as a new feedback type in
this document, and the ABNF for the parameters for fss is defined here
(please refer to section 4.2 of <xref target="RFC4585"></xref> for
complete ABNF syntax).</t>
<figure align="center">
<artwork>
rtcp-fb-val =/ "fss" rtcp-fb-fss-param
rtcp-fb-fss-param = SP "nsei";nack suppression early indication
/ SP “fsei”;fir suppression early indication
/ SP token [SP byte-string]
; for future commands/indications
byte-string = <as defined in section 4.2 of [RFC4585] >
</artwork>
</figure>
<t>Refer to Section 4.2 of <xref target="RFC4585"></xref> for a detailed
description and the full syntax of the "rtcp-fb" attribute.</t>
</section>
<section title="Example Use Cases">
<t>The operation of feedback suppression is similar for all types of RTP
sessions and topologies <xref target="RFC5117"></xref>, however the
exact messages used and the scenarios in which suppression is employed
differ for various use cases. The following sections outline the
intended use cases for feedback suppression and give an overview of the
particular mechanisms.</t>
<section title="Source Specific Multicast (SSM) use case">
<t>In SSM RTP sessions as described in <xref target="RFC5760"></xref>,
one or more Media Sources send RTP packets to a Distribution Source.
The Distribution Source relays the RTP packets to the receivers using
a source-specific multicast group.</t>
<t>In order to avoid the forms of NACK implosion described in section
1,the distribution source should choose to include the support for
loss detection. How the packet loss detection works is beyond of scope
of this document. When upstream link or downstream aggregate link
packet loss occurs, the distribution source creates a Feedback
Suppression report and sent it to all the RTP receivers, over the
multicast channel. Another possibility is when there may have multiple
distribution source placed between the media source and the receivers,
the upstream distribution source may inform downstream distribution
source of the detected packet loss using Feedback Suppression
messages. In response, the distribution source forwards packet loss
suppression report received from upstream to all the RTP receivers,
over the multicast channel. This loss suppression report tells the
receivers that the lost packet will either be forthcoming from
distribution source, or it irretrievably lost such that there is
nothing to be gained by the receiver sending a NACK to the media
source. The distribution source then can (optionally) ask for the lost
packets from the media source on behalf of all the RTP receivers.</t>
<t>When there is only one distribution source with loss detection
support between the media source and the receivers, redistribution of
the feedback suppression report to all the receivers is trivial. When
there are multiple distribution sources between the media source and
the receiver, , each distribution source with loss detection support
may create a Feedback Suppression Report using the similar format as
conventional RTCP NACK packets at the RTP layer and send it to its
downstream distribution source or forward one Feedback Suppression
Report from upstream to its downstream distribution source or the
receivers. Also each distribution source at the downstream of the
other distribution source may also create additional Feedback
Suppression Report and send it to the receivers.</t>
<t>The distribution source must be able to communicate with all group
members in order for either mechanism to be effective at suppressing
feedback.</t>
<t>As outlined in the <xref target="RFC5760"></xref>, there are two
Unicast Feedback models that may be used for reporting, - the Simple
Feedback model and the Distribution Source Feedback Summary Model. The
RTCP Feedback Suppression report extension specified in the section 4
of this document will work in both Feedback models. Details of
operation in each are specified below.</t>
<section title="Simple Feedback Model">
<t>In the simple Feedback Model, there may have one distribution
source with loss detection support. The distribution source must
listen on the corresponding RTP session for data. When the
distribution source observes that a sequence of RTP packets from
upstream contains gaps (by checking the sequence number of packets),
the distribution source must use the same packet types as
traditional RTCP feedback described in <xref
target="RFC3550"></xref> and create one new RTCP Feedback Report
with information on the RTP sequence number of the lost packets and
suppression early indication event. When the distribution source is
eligible to transmit, it must send this Report packet to the the
group on the multicast RTCP session.</t>
<t>Alternatively the distribution source should pass through any
feedback suppression requests it receives from the upstream
direction. Such a distribution source can also choose to not send
feedback suppression messages if it's already seen similar messages
with identical packet loss from upstream.</t>
<t>This RTCP Feedback Report lets the receivers know that feedback
for this packet loss is not needed and should not be sent to the
media source(s). If the media source(s) are part of the SSM group
for RTCP packet reflection, the Distribution Source must filter this
packet out. If the media source(s) are not part of the SSM group for
RTCP packets, the Distribution Source must not forward this RTCP
packets received from the receivers to the media source(s).</t>
</section>
<section title="Distribution Source Feedback Summary Model">
<t>In the distribution source feedback summary model, there may have
multiple distribution sources and the Loss Detection instances are
distributed into different distribution sources. In some cases,
these Loss Detection instances for the same session can exist at the
same time, e.g., one Loss Detection instance is implemented in the
upstream distribution source A, another two Loss Detection instances
for the same session is part of feedback target A and feedback
target B respectively within the distribution source B. In this
section, we focus on this generic case to discuss the distribution
Source Feedback Summary Model.</t>
<t>The distribution source A must listen on the RTP channel for
data. When the distribution source A observes RTP packets from a
media source are not consecutive by checking the sequence number of
packets, the distribution source A generates the new RTCP Feedback
Suppression Report packet described in the section 6, and then send
it to the distribution source B.</t>
<t>Two loss detection instances within the Distribution Source B
must listen for RTCP data sent to the RTCP port. Upon receiving the
RTCP Feedback Report packet from the Distribution Source A, the
distribution source B needs to summarize the information received
from all the RTCP Feedback Reports generated by the upstream
distribution source together with the information generated by two
loss detection instances witin the Distribution Source B and then
create the summary report to include all these information. In order
to reduce the processing load at the distribution source, each loss
detection instance may provide preliminary summarization report.</t>
<t>During the summary report creating, the Distribution Source B
must use its own SSRC value for transmitting summarization
information and MUST perform proper SSRC collision detection and
resolution.</t>
<t>In some case, the distribution source B may receive RTCP NACK
messages from the receivers behind the Distribution Source before
the distribution source detects the packet loss which may cause
potential Feedback implosion. In such case, the distribution source
B may filter them out if it already sent a packet loss request for
the missing packet to the media source. When the distribution source
B confirms packet loss reported by the receiver, the distribution
source B generates the summary report to include the packet loss
information from the corresponding receiver or upstream distribution
source.</t>
<t>The distribution source B may send this new RTCP summary report
described in the section 6 to the group on the multicast RTCP
channel and in the meanwhile sending a packet loss request to the
media source.</t>
<t>If there are a couple of distribution sources with loss detection
support looking at the same RTP stream, then the loss may be
identified by all and they will all send requests for the same
packet loss. In this case, the distribution source must filter out
the duplicated information from various distribution source and only
append one copy of such information to the summary report.</t>
<t>When the host receives the RTCP Feedback Suppression message, if
the host understands this message it will not send packet loss
request (e.g., NACK) for the missing packets reported in the
message. If it did not understand this new message, the host MAY
send packet loss request(e.g., NACK messages) to the specified media
source. When the distribution source receives the packet loss
request from the hosts after it has already detected packet loss,
the distribution source MUST filter it out until proactive recovery
is complete.</t>
</section>
</section>
<section title="Unicast based Rapid Acquisition of Multicast Stream (RAMS) use case">
<t>In the typical RAMS architecture, there may have one distribution
source placed between media source and BRS for relaying SSM stream
from media source. The BRS will receive the SSM stream from the DS.
Suppose there are several BRSes behind the distribution source or
media source, there may be just one BRS that detects packet loss on
its upstream link between the distribution source and BRS, but the
others will perhaps not, as the packet loss took place on SSM tree
branch that does not impact the other BRSes. In such case, the
distribution source with loss detection functionality support can not
detect packet loss at the downstream of itself, therefore the
distribution source SHOULD NOT create new Feedback Suppression message
and send it to all the BRS. If BRS impacted by packet loss has loss
detection support, the BRS MAY choose to create new Feedback
Suppression message and send it to the receivers behind this BRS.</t>
</section>
<section title="RTP transport translator use case">
<t>A Transport Translator (Topo-Trn-Translator), as defined in <xref
target="RFC5117"></xref> is typically forwarding the RTP and RTCP
traffic between RTP clients, for example converting between multicast
and unicast for domains that do not support multicast. The translator
can identify packet loss from the upstream and send the Feedback
Suppression message to the unicast receivers. The translator can also
serve as a loss reporter on the multicast side as described in the SSM
case.</t>
</section>
<section title="Multipoint Control Unit (MCU) use case">
<t>In point to multipoint topologies using video switching MCU
(Topo-Video-switch-MCU) <xref target="RFC5117"></xref>, the MCU
typically forwards a single media stream to each participant, selected
from the available input streams. The selection of the input stream is
often based on voice activity in the audio-visual conference, but
other conference management mechanisms (like presentation mode or
explicit floor control) exist as well.</t>
<t>In this case the MCU may detect packet loss from the sender or may
decide to switch to a new source. In both cases the receiver may lose
synchronization with the video stream and may send a FIR request. If
the MCU itself can detect the mis-synchronization of the video, the
MCU can send the FIR suppression message to the receivers and send a
FIR request to the video source.</t>
</section>
</section>
<section title="Security Considerations">
<t>The defined messages have certain properties that have security
implications. These must be addressed and taken into account by users of
this protocol.</t>
<t>Spoofed or maliciously created feedback messages of the type defined
in this specification can have the following implications:</t>
<t>Sending NACK Suppression Report with wrong sequence number of lost
packet that makes missing RTP packets can not be compensated.</t>
<t>Sending FIR Suppression Report with wrong sequence number of lost
packet that makes missing RTP packets can not be compensated by update
request mechanism.</t>
<t>To prevent these attacks, there is a need to apply authentication and
integrity protection of the feedback messages. This can be accomplished
against threats external to the current RTP session using the RTP
profile that combines Secure RTP <xref target="RFC3711"></xref> and AVPF
into SAVPF <xref target="RFC5124"></xref>.</t>
<t>Note that middleboxes that are not visible at the RTP layer that wish
to send NACK/FIR suppression reports on behalf of the media source can
only do so if they spoof the SSRC of the media source. This is difficult
in case SRTP is in use. If the middlebox is visible at the RTP layer,
this is not an issue, provided the middlebox is part of the security
context for the session.</t>
<t>Also note that endpoints that receive a NACK/FIR suppression request
would be well-advised to ignore it, unless it is authenticated via SRTCP
or similar. Accepting un-authenticated NACK/ FIR suppression requests
can lead to a denial of service attack, where the endpoint accepts poor
quality media that could be repaired.</t>
</section>
<section title="IANA Consideration">
<t>New feedback type and New parameters for RTCP FSS receiver feedback
report are subject to IANA registration. For general guidelines on IANA
considerations for RTCP feedback, refer to <xref
target="RFC4585"></xref>.</t>
<t>This document assigns one new feedback type value x in the RTCP
feedback report registry to “Feedback Storm Suppression” with the
following registrations format:</t>
<figure align="center">
<artwork>
Name: FSS
Long Name: Feedback Storm Suppression
Value: TBD
Reference: This document.
</artwork>
</figure>
<t>This document also assigns the parameter value y in the RTCP FSS
feedback report Registry to "NACK Suppression Early Indication ", with
the following registrations format:</t>
<figure>
<artwork align="center">
Name: NSEI
Long name: NACK Suppression Early Indication
Value: TBD
Reference: this document.
</artwork>
</figure>
<t>This document also assigns the parameter value z in the RTCP FSS
feedback report Registry to "FIR Suppression Early Indication ", with
the following registrations format:</t>
<figure align="center">
<artwork>
Name: FSEI
Long name: FIR Suppression Early Indication
Value: TBD
Reference: this document.
</artwork>
</figure>
<t>The contact information for the registrations is: <figure>
<artwork>
Qin Wu
sunseawq@huawei.com
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012, China
</artwork>
</figure></t>
</section>
<section title="Acknowledgement">
<t>The authors would like to thank David R Oran, Ali C. Begen, Colin
Perkins,Tom VAN CAENEGEM, Ingemar Johansson S, Bill Ver Steeg, WeeSan
Lee for their valuable comments and suggestions on this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.5760"?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.4585"?>
<?rfc include="reference.RFC.3550"?>
<?rfc include="reference.RFC.5117"?>
<?rfc include="reference.RFC.4588"?>
<?rfc include="reference.RFC.4566"?>
<?rfc include="reference.RFC.5234"?>
<?rfc include="reference.RFC.5104"?>
<?rfc include="reference.RFC.3711"?>
<?rfc include="reference.RFC.5124"?>
</references>
<references title="Informative References">
<reference anchor="RFC5740">
<front>
<title>NACK-Oriented Reliable Multicast (NORM) Transport
Protocol</title>
<author fullname="Brian Adamson" initials="B." surname="Adamson">
<organization>Naval Research Laboratory</organization>
</author>
<author fullname="Carsten Bormann" initials="C." surname="Bormann">
<organization>Universitaet Bremen TZI</organization>
</author>
<author fullname="Mark Handley " initials="M." surname="Handley">
<organization>University College London</organization>
</author>
<author fullname="Joe Macker" initials="J." surname="Macker">
<organization>Naval Research Laboratory</organization>
</author>
<date month="November" year="2009" />
</front>
</reference>
<reference anchor="DVB-IPTV">
<front>
<title>Digital Video Broadcasting(DVB); Transport of MPEG-2 TS Based
DVB Services over IP Based Networks</title>
<author>
<organization>ETSI Standard</organization>
</author>
<date month="August" year="2009" />
</front>
<seriesInfo name="ETSI TS 102 034, V1.4.1" value="" />
</reference>
<reference anchor="I-D.hunt-avt-monarch-01">
<front>
<title>Monitoring Architectures for RTP</title>
<author fullname="Geoff Hunt" initials="G." surname="Hunt">
<organization>BT</organization>
</author>
<author fullname="Philip Arden" initials="P." surname="Arden">
<organization>BT</organization>
</author>
<date month="August" year="2008" />
</front>
</reference>
<reference anchor="I-D.ietf-pmol-metrics-framework-02">
<front>
<title>Framework for Performance Metric Development</title>
<author fullname="Alan Clark " initials="A." surname="Clark">
<organization>Telchemy Incorporated</organization>
</author>
<date />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:17:31 |