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.