One document matched: draft-rosenberg-rai-modest-proposal-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth='5'?>
<?rfc compact='yes'?>
<?rfc subcompact='no'?>
<?rfc symrefs="yes"?>
<rfc category="info" ipr="full3978">

  <front>
    <title abbrev="Modest Proposal">A Modest Proposal for Session Initiation Protocol (SIP) Work in the IETF</title>

    <author fullname="Jonathan Rosenberg" initials="J.R." surname="Rosenberg">
      <organization>Cisco</organization>

      <address>
        <postal>
          <city>Iselin</city>

          <region>NJ</region>

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

        <email>jdrosen@cisco.com</email>

        <uri>http://www.jdrosen.net</uri>
      </address>
    </author>


    <date year="2008" />

    <area>RAI</area>

    <workgroup>SIP</workgroup>

    <keyword>process</keyword>

    <abstract>
      <t>The Session Initiation Protocol (SIP) has become widely
      deployed on the Internet, covering a wide range of usages from
      toll bypass to instant messaging, from service provider to
      enterprise. However, its realization in actual deployments
      differs in important ways from the specifications. This has
      created a gulf between existing and ongoing standards work, and
      real live deployments. This document argues that the RAI area
      should focus on solving real world interoperability issues and
      address real world functional gaps. </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">

<t>The Session Initiation Protocol (SIP) <xref target="RFC3261"/>, is
  a wildly successful protocol by any metric. It has seen widespread
  deployment on the Internet. It is used primarily in Voice over IP
  deployments, and carries billions and billions of minutes of traffic
  each year. It is used by enterprises big and small, by services
  providers far and wide, for a wide range of communications
  applications. 
</t>

<t>
However, like any large piece of work, some of the SIP
specifications have seen widespread usage, and others have
not. Indeed, in the past few years, there has been an increase in the
gap between implementations and standards, with an increasing number
of specifications being produced with limited use in the industry. At
the same time, the industry is facing a whole host of interoperability
and SIP problems, which are not being addressed by IETF. 
</t>

<t>
This document proposes that the SIP working group (and the RAI area at
large), recognize this gap, and begin work on addressing the real
needs of real SIP deployments.
</t>

</section>

<section title="The SIP Implementation Gap">

<t>
The SIP implementation gap is the increasing difference between SIP as
defined by the IETF, across its many specifications, and SIP in use
within the industry. This gap manifests itself in several key ways -
specifications that are not implemented or used by most vendors or
networks, non-standard solutions to problems, and networks whose
architectures differ from the models conceived by the IETF
specifications. The latter gap appears to be one of the primary
contributors to the implementation gap. This architecture gap consists
of three primary areas:
</t>

<t><list style="hanging">
<t hangText="Proxies vs. B2BUA:"> The SIP specifications would lead a
  reader to believe that SIP networks are full of these things called
  proxies, and that these proxies are principally concerned about call
  routing and are totally ignorant of call state. In reality, many if
  not most of the intermediaries in vendor products and networks are
  B2BUAs. These include SBCs, IP PBXs, softswitches, and so on, all of
  which are B2BUA.</t>

<t hangText="Endpoint vs. Network Features:"> The SIP architecture
  envisions a model where the majority of features live in the
  endpoints, and a smaller number live in the network. Network
  features are primarily limited to routing features -
  such as call forwarding and follow-me - which live in
  proxies. Though this is true for some networks (it is a foundational
  principle in P2P networks), most operational SIP deployments do not
  work this way. In reality, many products implement a much larger set
  of features in the network. Indeed, there appears to be a wide
  variation in this area, from one extreme (for P2P, all features in
  the endpoints) to another (using SIP as an MGCP alternative, passing
  digits and stimulus over INFO or DTMF to a call agent which
  implements all features). Unsurprisingly, this variation is a
  consequence of the software architecture of many products that
  existed prior to adding SIP, and in a desire not to re-architect
  products, features remain where they were and SIP gets added on. 
</t>

<t hangText="Email vs. Number Identifiers:"> The SIP specifications
 support both email-style and phone number identifiers. However,
 the focus - in examples, in specifications, and in use cases - is for
 email-style addressing. However, many deployments still
  utilize traditional phone numbers, and represent them using a SIP
  URI whose domain part is ignored, irrelevant, or used merely for
  determining the next hop target for the request.
</t>

<t hangText="Open Federation:">The SIP specifications assume an
email-style open-Internet interconnection - a user in example.com can
send an INVITE to a user in a completely different domain -
example.edu, and using basic DNS lookups, the call can be completed
between domains without prior arrangement. While this remains a
laudable goal, in practice it has not happened. SIP is deployed widely
within individual domains, but interconnections between domains, when
they do exist, are through managed federations.</t>

</list></t>


</section>

<section title="Implications of the Gap">

<t>
There are several consequences of this gap that are important for
IETF. 
</t>

<section title="Low Adoption Rate of Specifications">

<t>
Because of the implementation gap, IETF has produced many
specifications which target problems in networks or deployments which
represent only a small minority of real systems. As a consequence,
these specifications have seen poor adoption and support. The cost to
IETF is one of opportunity; time we could have spent on problems
important to a large number of deployments, are spent on problems
important to only a few.
</t>

<t>
Interestingly, many of these relate to B2BUAs. The following
specifications, all of which have seen relatively limited
adoption, are all important only in networks with proxies and not
B2BUAs:
</t>

<list style="hanging">

<t hangText="GRUU:"> In networks with proxies, the proxy cannot modify
  the Contact header field in dialog forming requests and
  responses. This necessitates the mechanism in GRUU
  <xref target="I-D.ietf-sip-gruu"/> whereby a UA can
  obtain and utilize URIs for use in the Contact header
  field. However, since a B2BUA does maintain call state, it can
  merely rewrite the Contact header field to one that has the GRUU
  property. That can be done without specification, and is indeed a
  common practice in B2BUA. Results from SIPIt 23 indicate that GRUU
  was supported by only 9% of implementations present, despite thet
  fact that it has been done for many years.
</t>

<t hangText="Session Policies:"> In networks with proxies, the proxy
  cannot modify the SDP to enforce network policies on things like
  codecs or media intermediaries. This necessitates a mechanism, via
  the session policy framework
  <xref target="I-D.ietf-sip-session-policy-framework"/> and related
  specifications
  <xref target="I-D.ietf-sipping-media-policy-dataset"/>,
  <xref target="I-D.ietf-sipping-policy-package"/>, that allow a proxy
  and UA to communicate policies to each other. However, in a network
  with B2BUA, the B2BUAs can just modify the SDP and other parts of
  the signaling to enforce policy. This requires no specification and
  is commonly done. There were no implementations of session policy at
  SIPit 23.
</t>

<t hangText="SIP Identity:"> SIP identity <xref target="RFC4474"/> assumes an
interconnection of proxies which do not rewrite key fields in the SIP
message (which are covered by signatures) and which make user of
email-style identifiers. Consequently, although the problem space it
  addresses is highly relevant to deployments with B2BUA and proxies
  alike, the mechanism itself is not compatible with B2BUAs or phone
  numbers, both of which are common. Only two implementations at SIPit
  23 (out of 50 present) had RFC 4474 support.
</t>
</list>

</section>

<section title="Unaddressed Problems">

<t>
SIP has seen widespread deployment, and as a consequence, many
interoperability issues have arisen in actual networks. Many of these
are areas where additional standards work could help improve the
situation. In addition, there remain areas where there are no
standards, and useful work could be done, but is not being done
because the problems don't make sense in the original SIP
architecture.
</t>

<t>
Several meetings ago, the SIP forum hosted an interoperability session
during a lunch break. The session included presentations from many
vendors and network operators listing real issues that they were
having. These included problems with DTMF interoperability, phone
number representation, SDP incompatibilities, and so on. Yet, IETF has
not responded with work to address these issues. In some cases, the
problem is that the IETF standards-based solutions for these problems
have not been adopted by the industry. Sometimes, its jut a matter of
time. In other cases, the proposed solutions, while architecturally
pure and elegant, have simply been too complicated for the use cases
for which they were targeted. For example, despite the IETF's
production of a standard for signaling-based carriage of DTMF (KPML,
RFC 4730 <xref target="RFC4730"/>), it has seen relatively little
adoption. Rather, most deployments use an INFO-based solution that is
not standards based, but has been found to be much simpler for actual
implementors. Only at the most recent IETF was there agreement to
adopt a framework for INFO.
</t>

</section>

<section title="Declining Participation">

<t>
Some RAI gourps have seen a decline in participation from folks with real
implementations who have real problems to solve. More and more, folks
seem to be busy with day jobs with little time for IETF. This has
resulted in increasing timelines to complete drafts as editors
struggle to get a revision done per meeting. While there is certainly
no consensus that this is the only or even primary part of the
problem, I do believe lack of participation and slow editors is a part
of it.
</t>

<t>
Why is that? Why are folks more busy with day jobs with less time for
IETF? Perhaps its due to the fact that the IETF simply isn't producing
documents that are actually relevant to their day jobs - said day jobs
presumably being tied to real products with real implementations and
real deployments. If, however, IETF work were tied to the actual
implementation issues those product teams were facing, we might see an
increase in participation from implementors.
</t>

</section>

</section>

<section title="A Modest Proposal">

<t>
Unsurprisingly, my modest proposal is the following is to do three
primary things:
</t>

<list style="numbers">

<t>Recognize the realities of SIP operational networks and take them
  into account. </t>

<t>Weigh our efforts proportionally with the number of affected
  networks. </t>

<t>Less is More.</t>
</list>

<section title="Recognize the Realities">

<t>The RAI area needs to formally recognize that B2BUAs, phone
numbers, and intra-domain focused implementations are common, and are
part of SIP's architecture. As an example, DHCP is an intra-domain
  only protocol, yet it was specified by IETF and is absolutely a
  standards track.
</t>

<t>Consequently, we should formally design
our specifications to work in those environments when appropriate, and
perhaps even be optimized for them based on engineering analysis. If a
particular feature needs to work one way in a proxy environment, and a
different but much simpler way in a B2BUA environment, the IETF should
consider that perhaps the much simpler solution, which is likely to be
broadly applicable, is superior. Session policies is a great example
of that; with an SBC, the solution of modifying SDP is much simpler
  than defining a protocol framework for negotiation between UA and
  servers in the network. IETF is, after all, the Internet
  *Engineering* Task Force, and engineering involves minimizing
  resources for maximal match of requirements. 
</t>

<t>Of course, nothing is absolute and
all things are subject to engineering analysis; but we should stop
ruling out solutions that require B2BUA, and consider them fully in
our efforts. Furthemore, SIP is nothing if not diverse. Some features
are targeted at networks, like P2PSIP, which lack central servers by
design. As part of our engineering analysis, we need to factor in
whether a feature is relevant in such networks, and whether their
properties impact the engineering choice on the mechanism. 
</t>

<t>
To support
this end, I propose the following specific steps:
</t>

<list style="numbers">

<t> The RAI area produce an informative document
which shows pictures of several exemplary real operational SIP
networks, covering service providers, enterprises, consumer and
residential services, presence/IM networks, and so on. Such pictures
would omit vendor names but be clear about what kinds of components
are in the network (B2BUA, gateways, proxies, UAs of various sorts),
what the scale is, and what types of protocols are in use. That will
provide a clear framework to measure how easily our specifications
'fit' into the real networks that are out there today. We can update
that document regularly as real networks change. We should invite architects
of such networks or vendors of key components in those networks to
help draft the document.
</t>

<t> The RAI area update the guidelines for authors of SIP extensions
  <xref target="RFC4485"/> to reference the above informative
  document, and based on it, present additional guidelines - e.g.,
  take into account SBCs, and so on.
</t>

<t> The RAI area revise RFC 3427 <xref target="RFC3427"/> (the SIP
  change process). Work was begun on this
  <xref target="I-D.peterson-rai-rfc3427bis"/>, but the draft is now
  expired. That revision should remove the "P-header" punishment for
  specifications which do not work on the public Internet. IETF should
  recognize that intra-domain and multi-domain but closed federations
  are real, and valid deployments of SIP. Standards defined to address
  problems in those deployments are no less 'real' than ones meant for
  SIP on the Internet.
</t>

</list>

</section>

<section title="Effort Proportional to Deployments">

<t>
SIP, like all other technologies, has gone through an adoption
lifecycle. This lifecycle, called the technology adoption life cycle,
looks at the rate of adoption of new technologies over time. Within
the VoIP market, SIP is currently in the late majority phase; most
vendors have it, it is widely deployed and operational.
</t>

<figure title="Technology Lifecycle" anchor="fig-curve"><artwork>
<![CDATA[
                                                                          
                                                                          
                                                                          
     |                                                                    
     |                                                                    
     |                                                                    
     |                                                                    
     |                                  SIP                               
  A  |                                                                    
  d  |                                   |                                
  o  |                                   |                                
  p  |                                   |                                
  t  |                                   V                                
  i  |                        **********                                  
  o  |                      **   |     **                                 
  n  |                    **     |      **                                
     |                   **      |       **                               
     |                  *        |        **                              
     |                 **        |         *                              
     |                 *         |         **                             
     |                **         |          *                             
     |               **          |          **                            
     |             **            |           **                           
     |           *** |           |          | ***                         
     |         ***   |           |          |    ***                      
     |       ***     | Early     |  Late    |      **********             
     | ******* Early | Majority  |  Majority|                ***          
     |      |Adopter |           |          |  Laggards                   
     |                                                                    
  ---+---------------------------------------------------------           
     |                                                                    
     |                    time                                            

]]></artwork></figure>


<t>
It is well understood in product marketing that your strategies for
building and selling products vary tremendously as a technology
crosses through these phases. During the innovation and early adopter
phases, the technology can be rough, hard to manage and use. But, the
focus is on new capabilities and benefits to the user. As technologies
mature, the importance of 'new' diminishes, and instead, ease of use,
ease of purchase, and reduction in operational cost, become more and
more important.
</t>

<t>
I would assert that, the same applies to standardization processes. In
the beginning, when a technology is new, the right thing is to focus
on cool new capabilities, innovations, and wild new capabilities. As a
technology matures, the standards activities need to shift focus as
well, moving more towards real problems in real
networks. The golden rule is:
</t>

<list style="empty">
<t>The work IETF spends on a topic should be proportional to the
  number of operational networks in which that topic is important.
</t>
</list>

<t>The SIP working group and RAI area at large invest their energies
in problems proportionally to the scope of the networks and
deployments with those problems. A problem, like SDP interoperability,
which affects a large number of real operational networks, should be
given priority over one with a limited audience. It is important to
note that audience refers NOT to implementations, and NOT to other
SDOs, but to current or planned networks. Oftentimes, folks have an
implementation but it is a prototype or research activity. Those
implementations should count less in our prioritization than ones in
actual large-scale operational networks. Similarly, oftentimes a
specification is needed by another SDO, for their own standards. While
the SDO and its specifications are important, we should weight such
work by looking at the current or planned real implementations of our
specification that come about through that SDO.
</t>

<t>
How do we make this determination of what is important? One suggestion
is that the SIP and/or SIPPING groups review the contributions to the
SIP forum session a few IETFs back, and begin working the top issues
identified there. The inclination is often to say, "oh, thats just an
implementation problem", or, "well they were just being
lazy". However, for problems that are systemic - where several vendors
would appear to be lazy or getting it wrong, this points to an issue -
either the specifications are overly complex and the industry has
decided not to use them, or they are unclear and hard to get
correct. Both of these are problems that can be addressed by
additional standards work. So the suggestion is to lean towards, "its
the IETF's fault" when doing this analysis.
</t>

<t>
Another suggestion is that the SIP and/or SIPPING working groups
approach vendors with SIP 
implementations and deployments and solicit requests for areas of
standards work that they would like to see addressed. Those folks
should also be invited to participate in the IETF with welcome
arms. We can set up mentoring programs were existing long-time
participants help new folks learn the ropes and show them how to
participate on the lists and bring ideas forward. Collection of input
on standards work could happen via a web survey, for example, much
like was done for the BLISS working group.
</t>

<t>
Indeed, since IETF is ultimately a volunteer organization, any
proposal that requires a change in focus, requires bringing in
participants who are interested in that focus. We should therefore try
and identify steps which lead to increased participation from
implementors and deployers.
</t>

</section>

<section title="Less is More">

<t>
IETF overall, and RAI in particular, has a tendency to produce
specifications which are fairly large and complex (indeed I personally
have contributed much to this). The focus has been to have broad
solutions that provide general purpose, framework-type
capabilities. As SIP has matured and become deployed, it is now part
of many products and networks for which big large changes are
hard. Consequently, it is becoming increasingly important to aim low,
and produce specifications that provide incremental features for only
a small increment of work. This is not always possible of course, but
our focus should be, "less is more", especially when weighing the
features of the specification relative to the current reality of
networks.
</t>

<t>
One such example of this is the configuration framework
<xref target="I-D.ietf-sipping-config-framework"/>. It is a very rich
and complex specification, supporting composition of configuration
policies, roaming and home networks, change notifications and
enrollment. In reality, many consumer products just periodically poll
a config file from a defined URL, and thats it. A much simpler
configuration mechanism, that is easy to add ontop of what is out
there today, would probably be more welcome in the marketplace. Note
that, at SIPit 23, there were no implementations of the configuration
framework.
</t>

<t>
Another example of this is the relatively new SDP capability
negotiation framework
<xref target="I-D.ietf-mmusic-sdp-capability-negotiation"/>. This work
was driven primarily to solve one key industry problem - negotiating
SRTP vs. RTP. So, the decision factor is, should we define a general
purpose framework or an incremental solution just for RTP/SRTP? The
IETF chose a general purpose framework, and that brings with it a
certain level of complexity. Will implementors use this just to solve
that one problem? I am concerned the cost/benefit ratio is too high.
</t>

</section>

</section>

<section title="Conclusion">

<t>
In conclusion, IETF needs to adapt to the realities of SIP.  The IETF
should focus on reall engineering problems that enable building
interoperability systems that will see significant deployment. The RAI
area needs to admit the things like SBCs and phone numbers and private
federations are real, and design solutions for them. Those networks
are our customers.
</t>

<t>
<list style="hanging">
<t hangText="Insanity:">doing the same thing over and over again and
  expecting different results.
</t>
</list>
</t>
<list style="empty">
<t>--Albert Einstein</t>
</list>

</section>


<section title="Security Considerations">

<t>
This document does not have any security implications for the
Internet. 
</t>

</section>

<section title="Acknowledgements">

<t>
The author would like to thank Paul Kyzivat, Dan Wing, Cullen
Jennings, James Polk and Mary Barnes for their comments on this
document. 
</t>

</section>

</middle>

<back>

  <references title="Informational References">

      <?rfc include='reference.RFC.3261'?>

      <?rfc include='reference.I-D.ietf-sip-gruu'?>

      <?rfc include='reference.RFC.4474'?>

      <?rfc include='reference.I-D.ietf-sip-session-policy-framework'?>

      <?rfc include='reference.I-D.ietf-sipping-media-policy-dataset'?>

      <?rfc include='reference.I-D.ietf-sipping-policy-package'?>

      <?rfc include='reference.I-D.ietf-sipping-config-framework'?>

      <?rfc include='reference.RFC.4730'?>

      <?rfc include='reference.RFC.4485'?>

      <?rfc include='reference.RFC.3427'?>

      <?rfc include='reference.I-D.peterson-rai-rfc3427bis'?>

      <?rfc include='reference.I-D.ietf-mmusic-sdp-capability-negotiation'?>

  </references>

</back>

</rfc>