Subject: Addressless Internet [stalker alert..]

From: [email-masked]
Date: Mon, 11 Dec 2000 18:12:01 +0000

Folks,

Just thought I'd alert you all to the danger of running
into me in the hallways and getting buttonholed on this
wonderful, new kind of sliced bread - after all, what's a 
more dangerous marketing type than the nutty inventor!)

The approach has been judged one of the best papers at
the IEEE 1st ECUMN conference and a fuller paper is to be 
published in the Annals of Telecommunications. The conf. 
paper and presentation (pdf,ps) are temporarily hosted at
 http://affine.watson.ibm.com/tmp/
That said, I should admit I'm no expert and need lots of 
comments and advice!

Yes, really, I came here with the express purpose and
mandate to lobby for a rearchitecture of the Internet.
Some have already pointed to me a certain similarity to
the TRIAD project of David Cheritan - the TRIAD is very
similar to what I had initially proposed (within IBM)
in '96-'97, and I would like to clarify that the present
proposal is a lot more drastic! I hope to convince 
enough people to get a bof or a wg going, could you 
please help?

thanks,
-p.
---
V. Guruprasad
[email-masked] (while at IETF meeting)
[email-masked]

---

From: V Guruprasad <[email-masked]>
Date: Wed, 20 Dec 2000 16:11:39 -0500

I've taken the liberty of posting it to the mailing list as IMHO the issues
Joel raises are very pertinent and I believe worthy of general consumption.

[Also, I use colourful syntax highlighting in Vim under Mutt, which makes
it easy for me to view the inline quotation. I realise it will look plain
b&w and long on the web page (and Lotus Notes ;), so my apologies in advance.]

sincerely,
-p.

-------------------

On Mon, 18 Dec 2000, Joel M. Halpern wrote:

> It appears that the path the communication takes is related to the path 
> among ACS used to resolve the virtual name down to its next level of 
> realization.
> If so, given that the ACS hops are picked without any destination 
> knowledge, it seems that the path chosen may very well be distinctly longer 
> and more resource consuming than one would like.  If this were just a 
> discovery path, that would not be a problem.  But it becomes locked in as 
> the virtual communication path between the entities.
> 
> Is this correct?

[This issue is stated in Section 2.3.7, 2nd bullet.]

No, because the translation process is orthogonal to the ACS path (Section 1.5)
so that the data path can be quite far from the ACS path depending on
the coverage of the translation rulebase at each of the ACS nodes. 

Consider two extreme cases:
* bad case:
	Each ACS node is sitting next to a switch and knows
	only about this and the switches of the adjacent ACS nodes.
	This describes what you said, but the only place one would
	use this is where there are no other switches (or routers)
	anyway. E.g. for intranet within a very small company.

* good case:
	Consider an ACS node in LA, Chicago, NYC and Miami, with
	switches in LA, Chicago, Austin (TX) and Ft Lauderdale. Student in
	Dade county dials up with her "home ACS" configured as Miami,
	looks up coursework posted at http://chicago/ucla/e6998,
	i.e. in the Chicago ACS node, by UCLA server presumably in LA.
	The ACS path is home-Miami-Chicago-LA-UCLA. If we did a poor
	job of translation, we'd get the longer path
		home-Ft Lauderdale-Chicago-LA-UCLA
	instead of
		home-Ft Lauderdale-Austin-LA-UCLA
	Now all that's needed to pick the latter path is to have
	translation rules at the Chicago ACS node identifying Austin
	as a usable switch with a shorter distance metric 
	(see attribute grammar description, section 2.4.5 of the I-D)

> When Noel Chiappa laid out the Nimrod work, similar results were evident 
> for default flows.  There were several ways to cope with this:
> 1) The paths were tied to administrative boundaries, not tied to servers, 
> so it was less of an issue.

That's kind of like the "bad case" above.

> 2) One could easily create and make use of shortcuts between domains.

Shortcuts are transparently supported even in the ACS plane - Sections
2.3.9, 2.3.10. Section 2.4.5 shows how transport plane shortcuts would
be encoded in the translation rulebase.

> 3) there were ways to set up explicit paths for common cases.

The rulebases are readily handcrafted for special or common cases.

> Do you have some similar capabilities in mind for what you are looking at?

Above.

> As a separate matter, every communication requires traversal of server 
> resources and connection setup resources in addition to the actual 
> communication.  One of the points made by Ross Callon in discussing ATM 
> usage is that it is very useful if there is an easy way to send short 
> datagrams, in addition to a harder way to set up paths when they are 
> useful.    In your context ACS queries and path setups are much more 
> expensive than DNS queries, so they do add significant overhead to the 

No way! The 2-way stitching algorithm (Section 2.4.1) combines path
signalling with the ACS "lookup", but that's only to explain the
basic principle of addressless connectivity. It's not intended to be
the "production approach".

The correct approach is the delayed/avoided signalling (Section 2.4.2),
where the path signalling is not done at all in the "lookup" or "forward
passage" phase, and the "lookup" itself can carry a short message payload
(SMS - short message service, in ATM/GSM-MAP/SS7 terminology).

The performance is exactly the number of hops taken by the ACS transit.
In combination with the ACS shortcuts (Sections 2.3.9 and 2.3.10),
you'd have the page carried to the destination in roughly the same time
as an IP datagram, but recall that for the latter, we very often need
to do a separate DNS lookup first.

> communication establishment phase.  Could your mechanism be linked to some 
> lighter weight datagram mode for short communication?  Or would that 

Section 2.4.2.

> require the very addresses that you are trying to abolish?  You claim that 
> your mechanism can do this by handling messages in the ACS.  But the ACS is 
> a request handler, not a message forwarder.  And the information for 

The way it handles requests *is* by forwarding messages...
[ "but they're *in* the well" - Alice, in Wonderland, of course]

> forwarding requests in the ACS is complex strings.  There is no way that 
> will be performance competitive with datagram routing.  In fact, if there 
> were any significant rate of "paging" messages, ACS would just be routers, 

Yes, if the traffic were largely paging messages, the ACS would be essentially
routing. But in that case, they would not be doing signalling either, so
their implementations would be best optimised differently.

Btw, there is nothing in the architecture to require the ACS tree to be
unique - your request gets interpreted by the ACS tree to which your
configured "home ACS node" belongs. On basis of your remarks, I'd recommend
a differently optimised ACS tree for paging service providers...

[point for next revision, thanks]

Also, it's not clear to me that the fact of using strings would make it less
efficient - I'm thinking of path name strings equal to DNS path names, you'd
have to do that much of string parsing and lookup in either case. Or that
the length of the strings makes it slower to transmit - e.g. if I were to use
AAL5 links to configure my ACS tree, there would be no issue of packet size. 

I think the real difference lies in the possibility of directly using
IP addresses for the paging datagrams, and not doing DNS lookups at all.
This is not applicable to clients (unless we're looking at android customers),
but it would be to a paging-style "push server", but this appears to be
a somewhat special area, which is currently commercially addressed by pre-IP
technologies so to speak. I suspect there will be ways to get around
this problem.

Another point, particularly with respect to ATM now that you mention it, is
that the need for SMS becomes acute with ATM (and is not satisfied AFAIK),
primarily because of the complexity of the ATM signalling protocols. Both the
PNNI and UNI Signalling 4.0 specs mention "broad-side on signalling", but
they don't specify it!

> and your virtual addresses would have become real addresses, since they 
> would be the fields on which the packets were forwarded.

I do point this out in Section 2.1 that the best that can be had is indirection;
this you still have even with paging, as the service "URLs" do not identify
the server hosts.

The only way the indirection can disappear is if the final ACS path is
percolated all the way back to the client for caching, which I would not
recommend at the client end because the security loss could offset the
performance gain (Section 2.3.9). Maybe ok for push servers - at this point,
I don't know.

Notwithstanding such issues, I still feel that this is a fundamental
alternative that goes way beyond Triad (I did, back in '95-96) and Nimrod,
and would beg you all to consider further.

thanks,
-p.