MMUSIC A. Begen
Internet-Draft Cisco Systems
Intended status: Informational February 14, 2008
Expires: August 17, 2008
FEC Grouping Issues in Session Description Protocol
draft-begen-mmusic-fec-grouping-issues-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 17, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The Session Description Protocol (SDP) currently supports grouping
media lines. SDP also has semantics defined for grouping the
associated source and Forward Error Correction (FEC)-based repair
flows. However, the existing specifications have strict requirements
that severely limit the use of the new features that are currently
under development in the FECFRAME WG. These new features will allow
applications to use FEC in a more flexible way but they require
changes in the current specifications. This document provides a list
Begen Expires August 17, 2008 [Page 1]
Internet-Draft FEC Grouping Issues in SDP February 2008
of the required changes and discusses potential approaches to make
these changes.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
3. FEC Framework Requirements and Issues with the Existing
Specifications . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Source and Repair Flow Association . . . . . . . . . . . . 5
3.2. Support for Additivity . . . . . . . . . . . . . . . . . . 6
3.3. Support for Prioritization . . . . . . . . . . . . . . . . 6
4. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 7
4.1. New Grouping Attribute . . . . . . . . . . . . . . . . . . 7
4.2. New Grouping Semantics . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Begen Expires August 17, 2008 [Page 2]
Internet-Draft FEC Grouping Issues in SDP February 2008
1. Introduction
The FEC Framework [I-D.ietf-fecframe-framework] outlines a general
framework for using Forward Error Correction (FEC) codes in
multimedia applications that stream audio, video or other types of
multimedia content.
Any application that needs a reliable transmission over an unreliable
packet network has to cope with the packet losses. FEC is an
effective approach that provides reliable transmission particularly
in multicast and broadcast applications where the feedback from the
receiver(s) is potentially limited.
In a nutshell, FEC groups source packets into blocks and applies
protection to generate a desired number of repair packets. These
repair packets may be sent on demand or independently of any receiver
feedback. The choice depends on the FEC scheme or the Content
Delivery Protocol used by the application, the error characteristics
of the underlying network, the transport scheme (e.g., unicast,
multicast, and broadcast), and the application. At the receiver
side, lost packets can be recovered by erasure decoding provided that
a sufficient number of source and repair packets are received.
For example, one of the most basic FEC schemes is the parity codes,
where an XOR operation is applied to a group of packets (i.e., source
block) to generate a single repair packet. At the receiver side,
this scheme achieves a full recovery if only one packet is lost
within the source block and the repair packet is received. There are
various other ways of generating repair packets, possibly with
different error-recovery capabilities.
The FEC Framework specification states that source and repair packets
MUST be carried in different streams, which are referred to as the
source and repair flows, respectively. At the receiver side, the
receivers should know which flows are the source flows and which
flows are the repair flows. The receivers should also know the exact
association of the source and repair flows so that they can use the
correct data to repair the original content in case there is a packet
loss. Currently, [RFC3388] and [RFC4756] are used for this purpose.
In order to provide applications more flexibility, the FEC Framework
[I-D.ietf-fecframe-framework] allows a source flow to be protected by
multiple FEC schemes, each of which requires an instance of the FEC
Framework. Thus, multiple instances of the FEC Framework MAY exist
at the sender and the receiver(s). Furthermore, within a single FEC
Framework instance, multiple source flows MAY be grouped and
protected by one or more repair flows.
Begen Expires August 17, 2008 [Page 3]
Internet-Draft FEC Grouping Issues in SDP February 2008
A basic example scenario is shown in Figure 1. Here, source flow S1
is protected by repair flow R1. Also, source flows S1 and S2 are
grouped and protected together by repair flow R2.
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
| S1: Source Flow |--------| R1: Repair Flow
+---|
| | S2: Source Flow
|
+______________________________| FEC FRAMEWORK INSTANCE #2
| R2: Repair Flow
Figure 1: Example scenario with two FEC Framework instances where R1
protects S1, and R2 protects the group of S1 and S2
Grouping source flows before applying FEC protection enables us to
achieve a better coding performance. As a typical scenario, suppose
that source flow S1 and S2 in Figure 1 correspond to the base and
enhancement layers in a layered video content, respectively. Repair
flow R2 protects the combination of the base and enhancement layer
for the receivers who receive both layers, and repair flow R1
protects the base layer only, for the receivers who want the base
layer only, or who receive both layers but prefer FEC protection for
the base layer only due to a bandwidth and/or processing-power
limitation.
Using multiple FEC Framework instances for a single source flow
provides flexibility to the receivers. An example scenario is
sketched in Figure 2. Different instances may offer repair flows
that are generated by different FEC schemes and receivers choose
receiving the appropriate repair flow(s) that they can support and
decode. Alternatively, different instances (whether they use the
same FEC scheme or not) may use larger and smaller source block
sizes, which accommodate the receivers that have looser and tighter
latency requirements, respectively. In addition, different instances
may also provide FEC protection at different redundancy levels. This
is particularly useful in multicast scenarios where different
receivers might experience different packet loss rates and each
receiver can choose the repair flow that is tailored to its needs.
Begen Expires August 17, 2008 [Page 4]
Internet-Draft FEC Grouping Issues in SDP February 2008
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
S3: Source Flow |---------| R3: Repair Flow
|
|---------| FEC FRAMEWORK INSTANCE #2
| R4: Repair Flow
Figure 2: Example scenario with two FEC Framework instances, each
with a single repair flow protecting the same source flow S3
To summarize, the FEC Framework supports the following:
1. A source flow MAY be protected by multiple different FEC schemes.
2. An FEC scheme MAY generate multiple repair flows.
3. Source flows MAY be grouped prior to FEC protection. That is,
one or more repair flows MAY protect a group of source flows.
Unfortunately, the existing specifications ([RFC3388] and [RFC4756])
have strict requirements that severely limit the use of the
flexibility that the FEC Framework provides. In Section 3, we
describe what is needed by the FEC Framework and the issues with the
existing specifications. In Section 4, we propose two solution
approaches. The goal of this document is to start discussions around
this topic and motivate the MMUSIC WG to come up with a solution that
will address the issues raised here.
2. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
3. FEC Framework Requirements and Issues with the Existing
Specifications
3.1. Source and Repair Flow Association
Currently, the 'group' attribute and the FEC grouping semantics
defined in [RFC3388] and [RFC4756], respectively, are used to
associate source and repair flows together.
The 'group' attribute is used to group multiple repair flows with one
or more source flows. However, [RFC3388] prohibits an "m" line
identified by its 'mid' attribute from appearing in more than one
"a=group" line using the same semantics. This limitation prevents us
Begen Expires August 17, 2008 [Page 5]
Internet-Draft FEC Grouping Issues in SDP February 2008
from indicating specific associations between the source and repair
flows by using an "a=group:FEC" line per FEC Framework instance. For
example, for the scenario sketched in Figure 1, [RFC3388] mandates us
to write
a=group:FEC S1 S2 R1 R2
Clearly, this "a=group:FEC" line does not say anything specific about
which repair flows are protecting which source flows. Note that
source and repair flows are identified by their payload formats
and/or other descriptors [I-D.ietf-fecframe-sdp-elements].
3.2. Support for Additivity
The FEC Framework also supports additive repair flows. Additivity
among the repair flows means that multiple repair flows may be
decoded jointly to improve the recovery chances of the missing
packets in a single or the same set of source flows. Additive repair
flows can be generated by the same FEC scheme or different FEC
schemes.
For example, in Figure 4, repair flows R5 and R6 may be additive
within the FEC Framework instance #1. Alternatively, all three
repair flows R5, R6 and R7 could be additive, too.
SOURCE FLOWS | FEC FRAMEWORK INSTANCE #1
S4: Source Flow |---------| R5: Repair Flow
| | R6: Repair Flow
|
|---------| FEC FRAMEWORK INSTANCE #2
| R7: Repair Flow
Figure 4: Example scenario with two FEC Framework instances, where
two repair flows in the first instance and a single repair flow in
the second instance protect the same source flow S4
Currently, there is no SDP semantics for indicating additivity among
the repair flows.
3.3. Support for Prioritization
When there are multiple repair flows protecting a single or the same
set of source flows, the sender MAY assign different levels of
priority to each repair flow. The sender uses prioritization to let
the receivers know in which order the receivers MUST receive and
decode the repair flows [I-D.ietf-fecframe-sdp-elements]. Note that
the repair flows that are assigned a priority level may be additive
or non-additive.
Begen Expires August 17, 2008 [Page 6]
Internet-Draft FEC Grouping Issues in SDP February 2008
A possible scenario where prioritization can be used is that the
sender generates two repair flows and sends them in two separate
multicast groups. It might be highly desirable to keep all the
receivers in the same multicast group to save from the network
traffic. The sender can achieve this by assigning a higher priority
to one of the repair flows. Another scenario is where one of the
repair flows is more expensive in terms of complexity, cost, etc. and
the sender wants every receiver to use the less expensive repair flow
first. This is again possible by using prioritization. For example,
in Figure 4, the sender MAY assign a higher priority to repair flow
R5 and a lower priority to repair flow R6.
Currently, there is no SDP semantics for indicating the priority
levels of the individual flows that are grouped in an "a=group" line.
Instead, within the FEC Framework, the priority of a repair flow is
described with the optional parameter 'flow-priority' in the "a=fec-
repair-flow" line [I-D.ietf-fecframe-sdp-elements], which is used to
describe the individual repair flows. However, there might be other
benefits of defining more general semantics for flow prioritization
in SDP that can be used by other applications and frameworks besides
FEC Framework.
4. Solution Approaches
There are two main solution approaches.
4.1. New Grouping Attribute
We can define a new grouping attribute that does not have the
limitations that [RFC3388] has. Since we do not obsolete [RFC3388],
applications using the existing grouping attribute ("a=group") will
not be affected and the existing grouping semantics can be used
without any complications. Furthermore, any application that does
not understand the new grouping attribute MUST ignore it [RFC4566].
This will avoid any backward compatibility issue.
Let the new grouping attribute be "gengroup". For the scenario
sketched in Figure 1, we can write
Begen Expires August 17, 2008 [Page 7]
Internet-Draft FEC Grouping Issues in SDP February 2008
v=0
o=ali 1122334455 1122334466 IN IP4 fec.rocks.com
s=FEC Grouping Examples - New Grouping Attribute
t=0 0
a=gengroup:FEC S1 R1
a=gengroup:FEC S1 S2 R2
m=video 30000 RTP/AVP 100
c=IN IP4 224.1.1.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=video 30000 RTP/AVP 101
c=IN IP4 224.1.1.2/127
a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1
a=mid:S2
m=video 30000 RTP/AVP 110
c=IN IP4 224.1.2.1/127
a=rtpmap:110 parityfec/90000
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X
a=repair-window: 200 ms
a=mid:R1
m=video 30000 RTP/AVP 111
c=IN IP4 224.1.2.2/127
a=rtpmap:111 parityfec/90000
a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; rs-fssi=456WSX
a=repair-window: 400 ms
a=mid:R2
which provides the complete association information. For the
definitions of the SDP descriptors specific to the FEC Framework,
refer to [I-D.ietf-fecframe-sdp-elements].
For the additivity and prioritization issues, let us consider the
scenario sketched in Figure 4. Suppose that repair flows R5 and R6
are additive but repair flow R7 is not additive with any of the other
repair flows. In this case, we can write
a=gengroup:FEC S4 R5 R6
a=gengroup:FEC S4 R7
If none of the repair flows were additive, we could have written
a=gengroup:FEC S4 R5
a=gengroup:FEC S4 R6
a=gengroup:FEC S4 R7
If the sender wants to assign priority levels to the repair flows,
Begen Expires August 17, 2008 [Page 8]
Internet-Draft FEC Grouping Issues in SDP February 2008
the priority order may be indicated with the order of the 'mid'
values of the repair flows. However, this approach is potentially
prone to errors and SHOULD be evaluated carefully whether it covers
the corner cases or not.
4.2. New Grouping Semantics
We can define a new grouping semantics for FEC that does not inherit
some of the requirements imposed by [RFC3388]. In particular, the
new grouping semantics should ignore the requirement of having the
same 'mid' value at most one "a=group" line using the same semantics.
Let the new grouping semantics be "genFEC". For the scenario
sketched in Figure 1, we can write
v=0
o=ali 1122334455 1122334466 IN IP4 fec.rocks.com
s=FEC Grouping Examples - New Grouping Semantics
t=0 0
a=group:genFEC S1 R1
a=group:genFEC S1 S2 R2
m=video 30000 RTP/AVP 100
c=IN IP4 224.1.1.1/127
a=rtpmap:100 MP2T/90000
a=fec-source-flow: id=0
a=mid:S1
m=video 30000 RTP/AVP 101
c=IN IP4 224.1.1.2/127
a=rtpmap:101 MP2T/90000
a=fec-source-flow: id=1
a=mid:S2
m=video 30000 RTP/AVP 110
c=IN IP4 224.1.2.1/127
a=rtpmap:110 parityfec/90000
a=fec-repair-flow: encoding-id=0; ss-fssi=1Q2A3Z; rs-fssi=4W5S6X
a=repair-window: 200 ms
a=mid:R1
m=video 30000 RTP/AVP 111
c=IN IP4 224.1.2.2/127
a=rtpmap:111 parityfec/90000
a=fec-repair-flow: encoding-id=0; ss-fssi=123QAZ; rs-fssi=456WSX
a=repair-window: 400 ms
a=mid:R2
Similar to the SDP examples given in Section 4.1, the additive repair
flows may be listed in the same "a=group:genFEC" line and non-
additive repair flows may be listed in separate "a=group:genFEC"
lines. The priorities of the repair flows may be signaled by the
Begen Expires August 17, 2008 [Page 9]
Internet-Draft FEC Grouping Issues in SDP February 2008
same approach that was described in Section 4.1. However, a similar
careful consideration SHOULD be given to check the corner cases, one
example being the case when priorities are assigned to a mix of
cross-instance additive and non-additive repair flows.
5. Security Considerations
There are no security considerations.
6. IANA Considerations
There are no IANA considerations.
7. Acknowledgments
The author would like to thank the FEC Framework Design Team, Dan
Wing and Flemming Andreasen for their inputs, suggestions and
contributions.
8. References
8.1. Normative References
[I-D.ietf-fecframe-framework]
Watson, M., "Forward Error Correction (FEC) Framework",
draft-ietf-fecframe-framework-01 (work in progress),
November 2007.
[I-D.ietf-fecframe-sdp-elements]
Begen, A., "SDP Elements for FEC Framework",
draft-ietf-fecframe-sdp-elements-00 (work in progress),
February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H.
Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002.
Begen Expires August 17, 2008 [Page 10]
Internet-Draft FEC Grouping Issues in SDP February 2008
8.2. Informative References
[RFC4756] Li, A., "Forward Error Correction Grouping Semantics in
Session Description Protocol", RFC 4756, November 2006.
Author's Address
Ali Begen
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: abegen@cisco.com
Begen Expires August 17, 2008 [Page 11]
Internet-Draft FEC Grouping Issues in SDP February 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Begen Expires August 17, 2008 [Page 12]