Re: PROs/CONs of SIP/PIP/TUBA

Steve Deering <deering@parc.xerox.com> Mon, 17 May 1993 15:14 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa28090; 17 May 93 11:14 EDT
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa28086; 17 May 93 11:14 EDT
Received: from thumper.bellcore.com by CNRI.Reston.VA.US id aa05020; 17 May 93 11:14 EDT
Received: by thumper.bellcore.com (4.1/4.7) id <AA16336> for ietf-archive@nri.reston.va.us; Mon, 17 May 93 11:13:23 EDT
Received: from alpha.xerox.com by thumper.bellcore.com (4.1/4.7) id <AA16330> for /usr/lib/sendmail -oi -fowner-pip X-pip; Mon, 17 May 93 11:13:22 EDT
Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11616>; Mon, 17 May 1993 08:12:53 PDT
Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Mon, 17 May 1993 08:12:44 -0700
To: John Day <Day@bbn.com>
Cc: pip@thumper.bellcore.com, sip@caldera.usc.edu, tuba@lanl.gov
Subject: Re: PROs/CONs of SIP/PIP/TUBA
In-Reply-To: Your message of "Sun, 16 May 93 18:55:04 PDT." <9305171304.AA12758@p.lanl.gov>
Date: Mon, 17 May 1993 08:12:32 PDT
X-Orig-Sender: Steve Deering <deering@parc.xerox.com>
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Steve Deering <deering@parc.xerox.com>
Message-Id: <93May17.081244pdt.12171@skylark.parc.xerox.com>

John Day wrote:

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

That is not a property of IPAE.  If it is possible for someone to come to
so false a conclusion after reading the IPAE specification, we clearly need
to work more on that specification.

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

Yes, in the sense that it is possible to conceive of an addressing scenario
that uses an unbounded number of bits.  Once we have infinitely fast routers
with infinite memory, joined by links of infinite bandwidth, we could consider
implementing an internet protocol with unbounded address length.  Until then,
we'll have to make an engineering choice of maximum address length.  SIP's
64-bit address space is 10^7 times larger than the international telephone
numbering space, and if managed sensibly (i.e., not just allowing everyone
to cobble up their own favorite octet string and expect the world to be able
to route on it) it will scale to handle many thousands of computers in every
room and vehicle in this solar system.

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

That would work fine for connection-oriented priority, where the mappings
from address to priority can be pre-established in the routers along a path.
If your protocol supports connectionless priority (e.g., "loss preference"
for layered video encodings) you don't want to have each of your routers
doing some sort of directory lookup on each packet's destination address in
order to determine the priority of the packet -- you want well-known priority
values as a separate field (or in a fixed, known location within the address,
which is effectively the same as a separate field).

Steve