One document matched: draft-ejzak-mmusic-bundle-alternatives-00.txt

MMUSIC                                                          R. Ejzak
Internet-Draft                                            Alcatel-Lucent
Intended status: Informational                         February 18, 2013
Expires: August 22, 2013


                         Alternatives to BUNDLE
               draft-ejzak-mmusic-bundle-alternatives-00

Abstract

   This paper discusses some potential modifications to the BUNDLE
   proposal for multiplexing of multiple media types within a single
   5-tuple to address limitations of the current proposal and
   alternatives already considered by MMUSIC.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 22, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Ejzak                    Expires August 22, 2013                [Page 1]

Internet-Draft             BUNDLE alternatives             February 2013


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Potential solutions . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  The same port number for all m lines in SDP answer  . . . . 4
     2.2.  Unspecified address for subsequent m lines in SDP offer . . 4
     2.3.  Unspecified address for subsequent m lines in SDP
           answer  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     2.4.  Immediately send an altered SDP offer . . . . . . . . . . . 5
   3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Informative References  . . . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7





































Ejzak                    Expires August 22, 2013                [Page 2]

Internet-Draft             BUNDLE alternatives             February 2013


1.  Introduction

   BUNDLE [I-D.ietf-mmusic-sdp-bundle-negotiation] provides for the
   multiplexing of the media associated with multiple SDP [RFC4566] m
   lines into a single 5-tuple and RTP [RFC3550] session, thus providing
   many potential advantages in reducing the messages needed for ICE
   [RFC5245] candidate gathering (particularly for server reflexive
   candidates) and reducing the messaging for DTLS [RFC6347] key
   exchange.  BUNDLE is signaled in an SDP offer by using the grouping
   framework to identify those m lines that are to share a single
   5-tuple.  In addition, the grouped m lines are all signaled with the
   same port number.  In the event that BUNDLE negotiation fails, it is
   still possible to construct separate 5-tuples for each m line by
   signaling separate port numbers for these m lines in the SDP answer.

   Unfortunately, there are some legacy middle boxes that identify an
   SDP offer with the same port number on multiple m lines as an error,
   thus failing the call attempt.  While it is possible to identify this
   situation and retry the call without BUNDLE, this is wasteful of
   system resources and induces undesirable delay in the call setup.

   The One-RTP proposal [I-D.alvestrand-one-rtp]is very similar to
   BUNDLE except that each m line in the SDP offer is signaled with a
   different port number.  It is understood that the endpoints are to
   use only the port number from the first m line for the multiplexed
   group.  This approach solves the previous legacy case, but causes a
   problem with other middle boxes that reserve resources based on the
   multiple port numbers and may later time out due to inactivity,
   causing the call to drop.


2.  Potential solutions

   This paper proposes several alternatives to these proposals for
   consideration.  All of these proposals assume the signaling of
   different port numbers for each m line in the SDP offer to avoid call
   failure and retry.

   Note that in this case if the SDP answerer chooses to not bundle the
   media then there is no problem.  The remainder of the paper will
   focus primarily on the case where the terminating side selects to
   bundle media but a middle box might allocate unneeded resources and
   potentially fail the call due to their inactivity.

   Note also that the paper only considers manipulation of the
   connection and port information in the subsequent m lines of the SDP
   offer and/or answer.  Zero port is not considered due to its very
   specific meaning on an SDP m line.  Changes to bandwidth,



Ejzak                    Expires August 22, 2013                [Page 3]

Internet-Draft             BUNDLE alternatives             February 2013


   directionality, or other attributes are not considered since they are
   all needed to signal characteristics of the media associated with the
   m line.

   This paper does not discuss the syntax of the unspecified address for
   IPv6 as this has been covered elsewhere.

2.1.  The same port number for all m lines in SDP answer

   Assuming that the middle box allocates resources for each m line in
   the SDP offer, it will still need to modify those resources upon
   receipt of the SDP answer.  If the SDP answerer signals the same port
   number for all the bundled m lines, then is there any possibility
   that the problem can be avoided?

   The legacy middle box will have signaled separate port numbers in the
   forwarded SDP offer so there is still a separate 5-tuple for each m
   line regardless of the port numbers signaled in the SDP answer.  So
   the middle box will have no choice but to retain the reserved
   resources after receiving the SDP answer.

   In addition, it is possible that the middle box will recognize the
   use of the same port for the bundle m lines in the SDP answer as an
   error condition and use the next opportunity to fail the call.

   This approach appears to have no value.  It seems to always be
   preferable to include valid but different port numbers in all the
   subsequent m lines in the SDP answer, even when choosing to bundle.

2.2.  Unspecified address for subsequent m lines in SDP offer

   This approach borrows a mechanism from Trickle ICE to avoid the
   signaling of any candidates for the subsequent m lines in the SDP
   offer.  The middle box will not allocate resources for these m lines
   when forwarding the SDP offer, and the SDP answerer will usually
   respond with the unspecified address for these m lines.  Even if the
   SDP answer includes valid connection information for these m lines,
   the middle box will still not allocate any resources.

   The primary advantage of this approach is that it is unnecessary to
   allocate either any ICE candidates for the subsequent m lines or any
   middle box resources for these m lines.

   It is possible that the middle box will not accept the SDP offer with
   an unspecified address, although RFC 3264 mandates support for this.

   Another problem with this approach is that if the SDP answerer
   chooses to not bundle media, then the SDP offerer will either need to



Ejzak                    Expires August 22, 2013                [Page 4]

Internet-Draft             BUNDLE alternatives             February 2013


   perform Trickle ICE, if supported, or to send another SDP offer with
   valid connection, candidate and port information for each m line.

2.3.  Unspecified address for subsequent m lines in SDP answer

   To further reduce the potential for unsupported signaling at middle
   boxes and to avoid problems with the unbundled case, the solution
   might still signal valid connection and port information in the SDP
   offer, thus potentially causing the middle box to unnecessarily
   allocate resources.  But if the SDP answerer decides to bundle media,
   then it can signal the unspecified address for the subsequent m lines
   in the bundle.

   With this approach, the middle box recognizing the unspecified
   address in subsequent m lines will release extraneous resources and
   avoid failure due to inactivity.

   There is some small risk that the middle box will not recognize the
   unspecified address (even though its support is mandated), but this
   risk is limited to the bundled case since the SDP for the unbundled
   case is not impacted.

2.4.  Immediately send an altered SDP offer

   Upon receiving the SDP answer (with separate ports for the subsequent
   m lines) and recognizing that bundling is selected there is the
   opportunity to send another SDP offer that might cause the middle box
   to release extraneous resources.

   Signaling the same port for all bundled m lines in the second SDP
   offer has the same problem as the original BUNDLE proposal if the
   middle box recognizes this as an error.

   Of the alternatives under consideration, the only one that makes
   sense in the second SDP offer is to modify the connection information
   for subsequent m lines to indicate the unspecified address.  This
   approach should be effective as long as the middle box supports the
   unspecified address in SDP, but as long as this is the case it seems
   preferable to just use the unspecified address for subsequent m lines
   in the first SDP answer.


3.  Discussion

   Of the approaches presented above, the author is of the opinion that
   the "unspecified address for subsequent m lines in the SDP answer" is
   the best choice and the "unspecified address for subsequent m lines
   in the SDP offer" is a reasonable second choice.



Ejzak                    Expires August 22, 2013                [Page 5]

Internet-Draft             BUNDLE alternatives             February 2013


   As long as middle boxes support the unspecified address (as RFC 3264
   requires them to do), the author's preferred choice successfully
   completes negotiation of either the bundled or unbundled media case
   in a single SDP offer/answer transaction.  Unfortunately, ICE
   candidates and middle box resources need to be allocated at least
   until receipt of the SDP answer.

   The second choice avoids any unnecessary ICE candidate or middle box
   resource allocation and successfully completes negotiation of the
   preferred bundled media case in a single SDP offer/answer
   transaction.  Unfortunately, the unbundled case (of lower priority)
   requires Trickle ICE or a second SDP transaction for successful
   completion.


4.  IANA Considerations

   To be completed.


5.  Security Considerations

   To be completed.


6.  Informative References

   [I-D.alvestrand-one-rtp]
              Alvestrand, H., "SDP Grouping for Single RTP Sessions",
              draft-alvestrand-one-rtp-02 (work in progress),
              September 2011.

   [I-D.ietf-mmusic-sdp-bundle-negotiation]
              Holmberg, C. and H. Alvestrand, "Multiplexing Negotiation
              Using Session Description Protocol (SDP) Port Numbers",
              draft-ietf-mmusic-sdp-bundle-negotiation-00 (work in
              progress), February 2012.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,



Ejzak                    Expires August 22, 2013                [Page 6]

Internet-Draft             BUNDLE alternatives             February 2013


              April 2010.

   [RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security Version 1.2", RFC 6347, January 2012.


Author's Address

   Richard Ejzak
   Alcatel-Lucent
   1960 Lucent Lane
   Naperville, Illinois  60563-1594
   US

   Email: richard.ejzak@alcatel-lucent.com




































Ejzak                    Expires August 22, 2013                [Page 7]