Re: PROs/CONs of SIP/PIP/TUBA

[John Day <[e-mail]>]

>Received: from p.lanl.gov by BBN.COM id aa22582; 14 May 93 16:59 EDT
>Received: from noc-gw.lanl.gov by p.lanl.gov (5.65/1.14)
>	id AA26009; Fri, 14 May 93 14:53:37 -0600
>Received: by noc-gw.lanl.gov (4.1/SMI-4.1)
>	id AA05087; Fri, 14 May 93 14:51:28 MDT
>Return-Path: <[e-mail]>
>Received: from p.lanl.gov by noc-gw.lanl.gov (4.1/SMI-4.1)
>	id AA05070; Fri, 14 May 93 14:50:39 MDT
>Received: from atc.boeing.com by p.lanl.gov (5.65/1.14)
>	id AA25744; Fri, 14 May 93 14:48:53 -0600
>Received: by atc.boeing.com (5.57) 
>	id AA14355; Fri, 14 May 93 13:52:03 -0700
>Date: Fri, 14 May 93 13:52:03 -0700
>From: Eric Fleischman <[e-mail]>
>Message-Id: <[e-mail]>
>To: [e-mail], [e-mail], [e-mail]
>Subject: PROs/CONs of SIP/PIP/TUBA
>Cc: [e-mail]
>
>                            Request for Assistance
>
>I am frequently asked by other Boeing employees to explain to them the PROs 
>(advantages) and CONs (disadvantages, unknowns, vulnerabilities) of the 
>major IPng approaches.  I have constructed the following list of the unique 
>elements which form the PROs and CONs of SIP, PIP, and TUBA in order to 
>partially satisfy these requests.  However, I have noticed that my own 
>understanding of these approaches is imperfect.  This implies that I may have 
>inadvertently misrepresented some of the proposals in various ways.  
>Unfortunately, I am not usually aware of when I have been inaccurate.  For 
>this reason I am sending this note out to the SIP, PIP, and TUBA working 
>groups in order to elicit their assistance to more accurately characterize 
>these approaches.  I offer my apologies to those people who, like me, belong 
>to multiple lists since this will mean that we will be bothered by multiple 
>copies of this note.
>
>I would like to request that interested parties read the following lists of 
>PROs and CONs in order to enhance the list.  I recognize the possibility 
>that differing people may label the same feature differently since there are 
>a variety of legitimate and differing perspectives by which the IPng issues 
>may be viewed.  For this reason, I would appreciate it if the responders 
>would explicitly note the viewpoint of their comments (e.g., network 
>providers, university, router vendor, end system vendor, government, 
>non-computer-related industry, etc.) together with their sage advice 
>as to how this list may be improved/enhanced.  An enhanced version of 
>this list may be requested in a week or two once the anticipated 
>suggestions have been assimilated.
>
>One more thing:  I have no desire to spark another "whose protocol is best" 
>flaming fest by this request (hence I am not sending it to the
>big-internet list).  Thus, I suggest that any respondent seriously 
>consider not copying the entire list unless the response is deemed to be of 
>value to the community as a whole (i.e., accomplishes more than just 
>instructing a certain naive yours truly).
>
>In any case, thank you for your attention to this matter.
>
>Sincerely yours,
>
>--Eric Fleischman
>
>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>                                   SIP Pro
>
>1)  As much like the current TCP/IP network layer protocols as possible 
>(except for SIP System Discovery which enhances upon the current protocols).  
>This leverages off of our current IPv4 knowledge-base for IPng deployments 
>(e.g., reduce training costs, etc.).  It also greatly reduces the "risk 
>factor" of introducing new technologies.
>
>2)  SIP has fewer options than IPv4 which means that it is even simpler 
>than IPv4 to process (e.g., to route).
>
>3)  Theoretically positioned to better support "flows" and other future 
>technologies than is the case for IPv4.

Actually as long as the addresses are assigned to each "flow" all of the
current protocols, IP, CLNP, SIP, PIP are equally well positioned to
support flows. The problem is that we tend to treat everything going to
the same place as the same address, which they only sort of are.
Different addresses at the same place are really means for
distinguishing different types of flows. If you take this view you won't
believe the options you can get rid of. For example, priority is simply
a flow with different traffic characteristics and should be on a
separate address.
>
>4)  Has IPAE and other well-thought-out migration approaches.  [Question 
>to the reader:  I suspect that a slightly modified IPAE would also work 
>for TUBA and EIPIP has been proposed for PIP.  Thus, is this really an 
>advantage of SIP?  Isn't it rather merely a function of the expertise of 
>the original SIP designers rather than an inherent advantage of the SIP 
>approach?]
>
I would list this as a CON. The IPAE properties that create the kind of
chaos found in some European phone systems where the number you are
calling depends on where you are calling from (and I don't mean just
more numbers added on the front; different numbers added on the front
depending on where you are calling from) is not something we want to
foist on the world. Even the PTTs that did it don't seem to consider it
a good idea. They are getting rid of it.

>                                 SIP Con
>
>1)  Since hierarchical addresses tend to be deployed in a "sparse" manner, 
>it unclear whether a 64 bit address space will adequately scale to meet 
>every conceivable future addressing scenario. 

It is pretty clear that any fixed length will never be enough.
>
>2)  No SIP protocol is totally unchanged from its "IPv4" equivalent.  This 
>introduces a certain degree of risk in its deployment (i.e., the unknown).
>
>3)  No network provider currently supports SIP.
>
>4)  RFC 1454 stated:  "although there are a few 'reserved' bits in the 
>header, the extension of SIP to support new features is not obvious".  
>[Question to the reader:  Is this really the case?  Isn't it rather the 
>case that new features will be supported by optional header data field 
>additions whose existence is signaled by the payload type field?  But then, 
>how would this be generally extensible for complex permutations of payload 
>types?  If so, then probably the original claim of RFC 1454 has merit.  
>Does it?]
>
>--------------------------------------------------------------------------
>
>                              PIP Pro
>
>1.  General routing and addressing without performance hit (i.e., in most 
>cases PIP routes faster than IPv4.  Exception is IP cache hit...)   Tangible 
>near-term benefit of this generality is provider selection and policy routing 
>in general together with potentially simplified address administration.  
>Longer term benefit of this generality is ability to evolve to new routing 
>and addressing paradigms.

Addressing is independent of all of these protocols to the extent that
an address from an addressing plan can be made to fit in the header. To
the same extent, all of these protocols are independent of the routing.
In fact this is a major advantage of all of these protocols. As long as
the PDU that carries the user-data is independent of the addressing and
routing (especially the latter), it will be possible to evolve routing
techniques without disturbing the end-systems. Since we still have a lot
to learn about routing this sounds like a big win, especially since it
is so difficult to predict how new routing algorithms will work in the
large. If PIP is really tied to a particular addressing and routing
strategy then this is not a PRO.
>
>2.  PIP has more features.  These include provider selection, auto host
>configuration (address, ID, domain name, and DNS server address, plus 
>auto-config of DNS), PDN address discovery, and domain-wide address prefix 
>autoconfiguration.

Again, I hope these are properties of the protocols supporting PIP and
not PIP itself. Otherwise, choosing PIP and then finding that one or
more of its features are less desirable than first appears, then
changing it is going to be very painful.
>
>3.  Evolvability.  PIP is architected to be well positioned to support 
>"flows" and other future network-layer technologies (e.g., separation of 
>routing/identification/handling), plus has explicit evolution mechanisms 
>(contents numbers, host version number, fast options handling).  This will 
>hopefully enhance the possibility of support for real-time services.
>
>                              PIP Con
>
>1. Complexity. 

Might expand on this a bit.
>
>2.  PIP is not directly based on existing protocols.  Thus, it represents new 
>technologies and it has a new addressing paradigm.  This "newness" implies 
>an unknown deployment "risk" factor (i.e., the "unknown").  
>
>3.  Since the PIP approach is novel, it represents a significant "learning 
>curve" for deployments with attendant expenses.
>
>4.  No network provider currently supports PIP.
>
>--------------------------------------------------------------------------
>
>                             TUBA Pro
>
>1.  Every TUBA protocol already exists and has experienced some degree of 
>actual deployment experience.  TUBA adopts these OSI network layer protocols 
>in an unchanged fashion.
>
>2.  Internet currently becoming "bilingual" with IPv4 and CLNP.  Thus, no 
>change for many network providers to support TUBA.
>
>3.  Will partially join the TCP/IP and OSI/CCITT communities -- hopefully 
>for greater synergy between these communities for those end users which 
>currently support both protocol families.  This may translate into reduced 
>end user network complexity.  
>
>4.  Has proven auto-configuration (auto-addressing) capabilities.
>
>5.  Is based upon International Standards and government-supported protocols 
>which are currently mandated in certain environments.
>
>6.  Integrated IS-IS already exists for mixed IPv4/TUBA deployments.  
>Integrated-OSPF (for IPv4/IPng) is yet to be defined.
>
>7.  The 160 bit TUBA address space is well positioned to meet any future 
>address scaling requirement.
>
>                                 TUBA Con
>
>1.  Unless a company is already familiar with OSI's connectionless network 
>layer protocols, TUBA represents a significant "learning curve" for 
>deployments with attendant expenses.
>
>2.  TUBA is no more positioned to support "flows" and other possible future 
>technologies than is IPv4.
>
>3.  TUBA supports a 160 bit network address which represents a potentially 
>significant overhead penalty for some environments.
>
>4.  TUBA protocols are not "tuned" for maximum routing efficiency (e.g. 
>checksum, attention to 32-bit CPU alignment issues).
>