Subject: [AVT] PROTO writeup for draft-ietf-avt-rtp-and-rtcp-mux-05.txt

From: Tom Taylor <[email-masked]>
Date: Fri, 29 Jun 2007 13:52:11 -0400

Attached.  A request for publication is being forwarded to the IESG.

Tom Taylor
PROTO Writeup for draft-ietf-avt-rtp-and-rtcp-mux-05.txt

Document history: see end of this writeup.

   (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

       Tom Taylor. I believe this version is ready.

   (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

       The document was announced informally to the BEHAVE and MMUSIC Working
       Groups. Prior to that announcement, an MMUSIC Chair commented on the draft,
       ICE from version 14 onwards has mentioned it, and the Chair of the BEHAVE
       Working Group has been aware of it. Because RTP/RTCP multiplexing could
       affect current QoS procedures developed by other SDOs, it is recommended
       that these SDOs (ETSI TISPAN, ITU-T Q. 5/11, PacketCable) be formally
       advised of the work.

   (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

       No.

   (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

       No specific concerns. The issues raised during WG discussion (as
       enumerated below under "Document History") have all been dealt with.
       No related IPR disclosure.

   (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

       The list and meeting discussions involved a satisfactory number of people,
       and did their job in raising and resolving issues. The document brought
       about a discussion of architectural principles in San Diego, since it
       represents a change to the RTP/RTCP architecture. The discussion concluded
       that the potential benefits were worth the change. The document drew no
       comments in AVT Working Group Last Call, but the issues raised in earlier
       discussion had already been dealt with at that point. 

   (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

       No.

   (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

       Nits noted on the tools /avt page for this draft:

         ** Obsolete normative reference: RFC 2032 (ref. '3') (Obsoleted by RFC 4587)
            The reference to RFC 2032 is intentional.
            
            A later version of draft-ietf-mmusic-ice exists.

   (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

       References are split as required. There is a normative dependency on
       draft-ietf-avt-rtcpssm, which is supposed to be ready but needs further
       editorial work. The Chairs will work to bring this into WGLC ASAP.

   (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

       One new SDP attribute registered, properly referred to RFC 4566 for
       the registry and procedurtes. 

   (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

       N/A. 

   (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
             This memo discusses issues that arise when multiplexing RTP data
             packets and RTP control protocol (RTCP) packets on a single UDP port.
             It updates RFC 3550 to describe when such multiplexing is, and is
             not, appropriate, and explains how the Session Description Protocol
             (SDP) can be used to signal multiplexed sessions.

          Working Group Summary
             This document represents a solid consensus of the AVT Working Group,
             with informal concurrence of the MMUSIC and BEHAVE Working Groups.
             Following the initial proposal, the major issue subsequently considered
             and resolved was how to negotiate the multiplexing capability and
             achieve fail-safe behaviour.  The decision was to provide a new SDP
             attribute to signal the multiplexing capability explicitly. There was
             also some discussion of how to signal bandwidth requirements.  The
             outcome was a decision to include allowance for RTCP traffic in the
             b=AS: value. 

          Document Quality
             The document has attracted considerable interest because it makes NAT
             traversal easier.  Jonathan Rosenberg, author of the ICE document,
             reviewed the proposal in terms of its interaction with ICE and provided
             related text.  Randell Jesup deserves special mention for his careful
             reviews of successive versions of the document and persistence in
             analysis of the associated signalling issues.

          Personnel
             Document Shepherd was Tom Taylor.
             Responsible Area Director was Cullen Jennings.

---------------------------
Document history:

       draft-perkins-dccp-rtp-00.txt, published 17-10-2005, mentions possibility
       of multiplexing RTP and RTCP onto the same port, but notes that care
       would be required to do it right.

       draft-perkins-avt-rtp-and-rtcp-mux-00.txt published 8-9-2006.

         Hadriel Kaplan <[email-masked]> had specific comments (thread
         "Comments on draft-perkins-avt-rtp-and-rtcp-mux-00.txt" beginning 
         11-9-2006) on the following points:
          -- why caution needed on PT values;
          -- effect on bandwidth values coded in b=AS line.
         Randell Jesup <[email-masked]> agreed with the relevance of these
         points and had a general suggestion on the bandwidth issue. Harikishan
         Desineni<[email-masked]> made a more specific suggestion. Colin
         Perkins agreed to clarify his concern over potential payload type 
         clashes and proposed to accept the essence of Harikishan's proposal for 
         calculation of the b=AS value.

         Discussion between Randell Jesup and Hadriel Kaplan (main thread 
         "Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt" beginning 
         with Colin's announcement 8-9-2006) on issues with the overloading of 
         the a=rtcp: attribute in SDP signalling when middleboxes fail to 
         understand the signalling. Randell urged a more explicit signalling of
         the proposed use of multiplexing.

         A comment by Gunnar Hellstrom (main thread) on the additional need to 
         multiplex different media streams over the same port to further 
         simplify NAT traversal generated a side discussion not related to the 
         specific topic of the draft. Gunnar asked that the draft make clear
         that it did not cover this point.

         New thread ("Comments on draft-perkins-avt-rtp-and-rtcp-mux-00.txt"
         beginning 21-9-2006) initiated by Roni Even. Points made:
          -- advantage of multiplexing is that RTCP messages serve as NAT 
             keep-alive;
          -- need to address case of one-way RTP flows;
          -- may be an use case for multiplexing at one end only;
          -- will it be possible to move in and out of the multiplexing state 
             through appropriate exchange of signalling?
          -- prefers that b=AS and b=TIAS just specify RTP, not RTCP bandwidth;
          -- separation of RTP and RTCP on different ports facilitates network
             giving of priority treatment to RTP over RTCP.
         Randell Jesup responded, suggesting that one-way RTP flows did not need 
         special treatment, discussing the single-ended case and whether it 
         could happen, and agreeing that it should be possible to renegotiate 
         the use or non-use of multiplexing in mid-session. Colin agreed with 
         Randell that one-way RTP flows did not need special treatment. He was 
         of the opinion that symmetric use of multiplexing should be forced, 
         bearing in mind the problems already posed by asymmetric RTP.

         In an unrelated point on the same thread, Stephan Wenger 
         <[email-masked]> wondered whether RTCP multiplexing would have a 
         negative impact on compression (RoHC). Colin responded that he would 
         add something on this topic in the next version of the draft.

       draft-perkins-avt-rtp-and-rtcp-mux-01.txt published 25-9-2006.

         Gunnar Hellstrom pronounced himself content with the clarification of 
         scope provided in the new version.

         Randell Jesup again questioned why it was worth restricting payload 
         type numbers. He also noted that when a=rtcp: is returned but shows a 
         different port number than the RTP stream, "rejecting" the session as 
         required by the draft involves killing the session or doing an 
         UPDATE/re-INVITE. Finally, he made alternative suggestions for setting 
         the b=AS: value, pointing out that mid-stream devices unaware of RTCP 
         multiplexing would reserve too little bandwidth with the procedure 
         Desineni asked for clarification of Randell's comments on the QOS 
         issue, and Randell gave an example involving DOCSIS-controlled cable
         bandwidth.
         
         Colin responded to Randell, agreeing that the payload type restrictions
         did not buy much, but suggesting areas where implementations based on
         misinterpretion of the specifications might send non-compound packets.
         He agreed there was a signalling problem when the far end failed to act
         correctly, and this was an open issue. He was concerned that including
         RTCP bandwidth in the b=AS: value as Randell suggested would break
         compatibility.

         Behind the scenes: agreed as a charter item (Cullen Jennings,
         20-9-2006).

       draft-ietf-avt-rtp-and-rtcp-mux-00.txt published 2-10-2006.

         Randell Jessup (2-10-2006) continued his analysis of the proper 
         procedure when the far end fails to assign the same port to RTP and 
         RTCP. He also continued to argue for inclusion of RTCP bandwidth in the 
         b=AS: value. [In fact, the new -00 version and subsequent versions do
         so.]
 
       draft-ietf-avt-rtp-and-rtcp-mux-01.txt published 26-10-2006. 

         Colin Perkins noted (27-10-2006) that it covered:
           -- implications when the device receiving the offer understands
              the a=rtcp: attribute, but does not understand RTCP multiplexing;
           -- expanded discussion of interactions with ICE;
           -- expanded discussion of SIP forking;
           -- clarified failure behaviour during offer/answer negotiation;
           -- added "Interactions with Header Compression" section.

         Discussion in San Diego (7-11-2006) resulted in a resolution of the 
         signalling issue. A new attribute would be sent in the offer to 
         indicate use of multiplexing (as originally proposed by Randell Jesup). 
         If this attribute is understood, the receiver would ignore the a=rtcp: 
         attribute. The latter would be restricted to a fallback role. 
         Discussion also examined the broader question of whether RTCP 
         multiplexing offered real value. It was agreed that its main value 
         would be in port savings on the TURN server.

       draft-ietf-avt-rtp-and-rtcp-mux-02.txt published 20-11-2006.

         Signalling section updated as agreed in San Diego. ICE discussion
         considerably expanded. Improvements in other sections.

       draft-ietf-avt-rtp-and-rtcp-mux-03.txt published 12-5-2006.
         
         Editorial changes only.

       draft-ietf-avt-rtp-and-rtcp-mux-04.txt published 8-3-2007.

         Added requirement that multiplexing be done for unicast sessions only 
         when previously signalled. Changed SHOULD NOT to MUST NOT multiplex if 
         answer does not indicate acceptance of multiplexing.

       Working Group Last Call announced 18-3-2007, to conclude 7-4-2007. No 
       comments received. Notice extended to the BEHAVE and MMUSIC Working 
       Groups prior to completion of this writeup. No comments received in the
       ensuing week. 

       draft-ietf-avt-rtp-and-rtcp-mux-05.txt published 21-5-2007.

         Fixed some nits.

                                        -30-
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt