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

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!ENTITY BUNDLE SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mmusic-sdp-bundle-negotiation-00.xml">
<!ENTITY SHIM SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-westerlund-avtcore-transport-multiplexing-02.xml">
<!ENTITY muxarchitecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-westerlund-avtcore-multiplex-architecture-01.xml">
<!ENTITY maxssrc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-westerlund-avtcore-max-ssrc-01.xml">
<!ENTITY rtpmux SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-rosenberg-rtcweb-rtpmux-00.xml">
<!ENTITY rtpusage SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-rtcweb-rtp-usage-02.xml">
<!ENTITY ssrcdemux SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.peterson-rosenberg-avt-rtp-ssrc-demux.xml">
<!ENTITY msid SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.alvestrand-mmusic-msid.xml">
<!ENTITY OneRTP SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.alvestrand-one-rtp.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY RFC6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC5761 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5761.xml">
<!ENTITY RFC4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ejzak-mmusic-bundle-alternatives-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
        or pre5378Trust200902
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="BUNDLE alternatives">Alternatives to BUNDLE</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Richard Ejzak" initials="R." 
            surname="Ejzak">
      <organization>Alcatel-Lucent</organization>

      <address>
        <postal>
          <street>1960 Lucent Lane</street>

          <!-- Reorder these if your country does things differently -->

          <city>Naperville</city>

          <region>Illinois</region>

          <code>60563-1594</code>

          <country>US</country>
        </postal>

        <email>richard.ejzak@alcatel-lucent.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date year="2013" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>RAI</area>

    <workgroup>MMUSIC</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

   

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>BUNDLE <xref target="I-D.ietf-mmusic-sdp-bundle-negotiation"></xref> provides for the multiplexing of the media associated with multiple SDP <xref target="RFC4566"></xref> m lines into a single 5-tuple and RTP <xref target="RFC3550"></xref> session, thus providing many potential advantages in reducing the messages needed for ICE <xref target="RFC5245"></xref> candidate gathering (particularly for server reflexive candidates) and reducing the messaging for DTLS <xref target="RFC6347"></xref> 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.</t>
      
    <t>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.</t>
    
      <t>The One-RTP proposal <xref target="I-D.alvestrand-one-rtp"></xref>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.</t>
      
    </section>

    <section title="Potential solutions">
      <t>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.</t>
      
      <t>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.</t>
      
      <t>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, directionality, or other attributes are not considered since they are all needed to signal characteristics of the media associated with the m line.</t>
      
      <t>This paper does not discuss the syntax of the unspecified address for IPv6 as this has been covered elsewhere.</t>
      
      <section title="The same port number for all m lines in SDP answer">
        <t>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?</t>
        
        <t>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.</t>
        
        <t>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.</t>
        
        <t>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.</t>
        
      </section>
 
      <section title="Unspecified address for subsequent m lines in SDP offer">
        <t>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.</t>
        
        <t>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.</t>
        
        <t>It is possible that the middle box will not accept the SDP offer with an unspecified address, although RFC 3264 mandates support for this.</t>
        
        <t>Another problem with this approach is that if the SDP answerer chooses to not bundle media, then the SDP offerer will either need to perform Trickle ICE, if supported, or to send another SDP offer with valid connection, candidate and port information for each m line.</t>

      </section>
            
      <section title="Unspecified address for subsequent m lines in SDP answer">
        <t>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.</t>

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

        <t>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.</t>
      
      </section>
      

      <section title="Immediately send an altered SDP offer">
        <t>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.</t>
        
        <t>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.</t>
        
        <t>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.</t>
      </section>
            
    </section>
    
    <section title="Discussion">
      <t>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. </t>
      
      <t>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.</t>
      
      <t>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.</t>
      
     </section>
    
     <section anchor="IANA" title="IANA Considerations">
      <t>To be completed.</t>

      </section>

    <section anchor="Security" title="Security Considerations">
      <t>To be completed.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      &BUNDLE;
      
      &OneRTP;
      
      &RFC3550;
      
      &RFC5245;
      
      &RFC6347;
      
       &RFC4566;

    </references>    
 
  </back>
</rfc>