Re: NATs *ARE* evil!
> thank you, I think you've advertised this draft quite adequately for the > time being. I'm quite willing to look at it, but there are numerous Thanks! now I will relax and go home :) > every possible alternative architecture to conclude that (a) most or all > of these identifiers are necessary, and (b) reserving space for each > one separately, and maintaining all of the mappings between them, > would be onerous. But before I go: Condition (b) presumes on possible alternative architectures. My favourite example is the parallel line axiom - in retrospect, it was *because* it was an axiom that we ended up having two sets of alternative geometries, elliptic and hyperbolic, one of which (Riemannian = elliptic) became the basis of general relativity. Currently, it looks like (b) is axiomatic, but I already break it, and I'm sure the younger, smarter generations will think of new ways we can't begin to imagine. happy holidays, -p.
kernelizing the network resolver
Hi everyone, Please check out http://infs.sourceforge.net for a novel INternet FileSystem (INFS) package which appears to be ideally suited to cell phones and other small devices or appliances. By pushing the DNS resolution to the kernel, INFS means to achieve the following: - eliminates sockaddr_t handling in the user space, allowing application code to become free of IPv4/IPv6 (or for that matter raw Ethernet or ATM) dependencies; - reduces the number of context switches going from application to resolver and back; - provides robust kernel multitasking for the resolution process, avoiding buggy or unsafe multithreading in application-based resolvers (like in netscape); - reduces the overall code footprint - the filesystem name tree cache is reused, sockaddr_t handling code in applications gone. This is still a pre-alpha version, sufficient only to illustrate the concept. A few system calls need to be added to completely eliminate any need for handling sockaddr_t in user space. Also, the dns response parsing can be improved - it currently gets confused with CNAME records (e.g. from www.microsoft.com), tho' it does tolerate multiple A records (e.g. from www.ibm.com). To the anonymous referees of my sigcomm submission earlier this year on the Namespace Addressing Principle: you might recognize that I was proposing INFS - but it was untried till May. the full thesis is not yet final (but the global Internet self-management algorithms hinted at are now described in the draft Annals paper at http://www.columbia.edu/~vg96/papers). I look forward to comments, education*, help... Sincerely, -prasad. -- * finally a true student: no longer at ibm or anywhere!
Re: kernelizing the network resolver
Dear John,
On Fri 2002.11.01, John Stracke wrote:
> V Guruprasad wrote:
>
> >- eliminates sockaddr_t handling in the user space, allowing
> > application code to become free of IPv4/IPv6 (or for that matter
> > raw Ethernet or ATM) dependencies;
> >
> Doesn't using a shared library for the resolver give you the same
> benefit? It's in user space, but it's not in the app.
Yes, sockaddr_t can be eliminated using a shared library, but in order
to do that, we must replace the following steps:
server side:
1 hostent_t haddr = gethostbyname (char* namepath);
2 sockaddr_t sockaddr := { haddr, int port };
3 fd_t sock = socket (domain, type, protocol);
4 listen (sock);/* optional */
5 bind (sock, sockaddr, sizeof (sockaddr));
client side:
[1,2,3] and
7 int addrlen = sizeof (sockaddr);
8 fd_t sock = connect (sock, sockaddr, &addrlen);
with one function call
9 fd_t sock = sockaddressless_socket_open (
char* namepath,
int type,
int protocol,
int port
);
This is only one step removed from the INFS version
10 fd_t sock = open (char* namepath, int flags, [int omode]);
if the port, type and protocol parameters are included in the namepath as
e.g. /com/ibm/research/www/rtsptoolkit/tcp:80.
The real motivation for going this extra step was the thesis that
emerged in the incomplete sigcomm02 submission, for which we (my
immediate ex-colleagues and I) had two important ingredients begging
for a top-down architectural story:
A) an alternative namespace-based "addressless networking" algorithm
presented at ECUMN'00, together with a prototype implementation
(as MS project) demo'd at INET'01; and
B) an address/route auto-aggregation algorithm comprising a Huffman-like
recursive address assignment scheme applied to Dijkstra routing trees.
(A) says that a distributed network namespace is sufficient as a
primary addressing mechanism (the proof involves a basic property of
an unshared distributed tree as a self-defining network address space),
i.e. not depending on a manually managed/coordinated numeric address
space like IP. Thus, (A) facilitates (B) and (B) motivates (A).
However, this also means that the end-to-end-ness or long term stationarity
of the numeric (IP) addresses should no longer be taken for granted, and
that names should be used instead as the primary reference. This makes
it imperative to consider an alternative networking API that uses names
as addresses. Since the ordinary notion of what constitutes "system"
and what "application/user" concerns the operating system boundary, a
system calls interface of this form merited consideration. The fact that
the open(2) already has almost the desired form, and caters to a hierarchical
(filesystem) namespaces as well, made the INFS approach all the more
interesting to try out.
Yes, a shared library is still the way to go on many platforms, especially
on Windows where the socket implementation itself comes from dll's. The
filesystem interface is more restrictive, however, and provides a stronger
test of the sufficiency of the filesystem/file operations paradigm.
> >- reduces the number of context switches going from application
> > to resolver and back;
> >
> Do you have data showing these context switches are a problem? To me, it
> seems like you're optimizing something that doesn't take up that much
> time anyway--what apps spend that much CPU time on DNS lookups?
The context switching reduction was intended only to point out
that performance is likely to improve rather than worsen. However,
yes, it is one of the things on the to-do list, but I don't know
how soon I can get around to it given my current resources (being
out of job!).
> >- reduces the overall code footprint - the filesystem name tree
> > cache is reused, sockaddr_t handling code in applications gone.
> >
> Again, shared libs also reduce duplicate code (though not data; for that
> you do need the kernel, or a daemon).
The code reduction is *slightly* more than with just shared library:
with an slib, duplications between apps is avoided, but there is at
least one slib implementation of parsing and name caching code. With
the infs approach, even this much of the slib would be eliminated
as the vfs already contains similar code and would be reused.
I wholeheartedly agree that this much of code reduction is not all
that big a diff today, as memory and cpu cycles are quite cheap and
becoming even cheaper by the minute, but if a reduction is possible,
it's always educational to try it out. However, the sockaddr_t and
VFS integration were the main motivations.
thanks,
-prasad.
Re: kernelizing the network resolver
On Fri 2002.11.01, Keith Moore wrote: > > Please check out http://infs.sourceforge.net for a novel INternet > > FileSystem (INFS) package which appears to be ideally suited to > > cell phones and other small devices or appliances. By pushing the > > DNS resolution to the kernel, INFS means to achieve the following: > > > > - eliminates sockaddr_t handling in the user space, allowing > > application code to become free of IPv4/IPv6 (or for that matter > > raw Ethernet or ATM) dependencies; > > so when the address changes out from under the app, or there are > multiple hosts bound to a single domain name, the app loses. I don't see why name-address caching within the kernel cannot be as good or as bad as caching in the user space. I believe this would be an important area that the current Linux implementation of INFS allows. > and the app is also forced to live with delays and lower reliability > of DNS whether or not it is appropriate for that app. Programs which more directly concern the IP infrastructure, e.g. like traceroute or tcpdump, should naturally continue using IP addresses as arguments. It is only for "true apps", for which use of DNS names as command arguments is as such recommended, that INFS use is envisaged. I like to think that while this distinction isn't black and white, it is not altogether grey either. Again, this is precisely the kind of issue a working implementation is needed to answer, hence INFS. > sockaddr support. why are you trying to wean apps off of using > IP space when for many purposes DNS is even worse? DNS is slower > and less reliable than IP, no more consistent than IP, and DNS names > are as overloaded as IP addresses. The previous paragraph answers this to the extent INFS supplements the current status quo and the limitations of the DNS. There is a sounder philosophical/physics argument, given in my thesis (section 1.3/1.4), for the idea of weaning apps off IP or similar numeric address spaces. Very briefly, the two main reasons are (a) that any fixed-length numeric address space automatically sets a hard limit and resists expansion, as we are finding from the IPv6 migration, and (b) not depending on fixed-length numeric addresses as primary (user & application level) addresses would enable the network to auto-aggregate its addresses and routes. A more consistent and less overloaded namespace is naturally required, and is at least partly addressed by the alternative namespace (ANS) described in the thesis. (The driver for ANS would be simply another INFS kernel module like the dns driver in INFS.) Please note that the thesis is not yet final, in that I need to rework it a bit and add some results, but it is sufficient to the extent of motivating and relating to INFS. Thanks for your thoughtful comments. I should add that our previous discussions re: addressless networking i-d last year substantially educated me and influenced the arguments in the sigcomm'02 submission and the thesis. sincerely, -prasad.
Re: kernelizing the network resolver
Thanks for your thoughtful comments and look forward to more. Since I wrote INFS back in May-Jun, I already have had discussion on some of these issues, as given below. -p. On Tue 2002.11.05, John Stracke wrote: > The problem is that only the app knows what kind of caching behavior it > needs. For a simple protocol like SMTP or HTTP, pure DNS-based caching > is fine; for a more sophisticated protocol (e.g., any sort of > videoconferencing app), it may be necessary to ensure that each > connection associated with a given session go to the same address. I see both as largely system calls API issues, permitting simple and elegant solutions, and as not fundamental networking constraints that would legitimately rule against the INFS approach. As Vahalia (Unix internals book) describes, different network filesystems involve very different caching behaviours, meaning that the VFS name tree cache already caters to a wide variety of desired behaviours. The Linux VFS, for example, provides for per-node ttl, and can be manipulated on a per- process basis by setting mode parameters specifying the cache control before "opening" the nodes. For the second requirement, a simple known approach is to pass the already open (socket) file descriptor as argument when opening the secondary connections, so that the fd serves as an abstract handle for the previously obtained address. This is one of the things I am hoping people will play with in the INFS and lead to a mature networking API. > The fixed-length numeric addresses still need to exist, and their nature > still needs to be coded into all hosts and routers. Hiding them from > the apps will not make it easier to upgrade the installed base. No, but it would avoid inertia from the apps, whose hardcoding for IPv4 sockaddr's does pose some problems for v6 migration and dual support in wireless devices and appliances. I don't have data first hand on the magnitude of the problems involved, but have been told that it is enough to make INFS attractive. One analogy that comes to mind is that having app code doesn't eliminate disk sector addresses and formatting. One cannot upgrade to a larger disk by simply dd'ing from the old disk. However, mercifully, we store files and directories today by name and not disk sectors, and copying name-by-name, i.e. at the filesystem level, simplifies the upgrade. To compare, it was not too long ago that this wasn't the case! > You're talking about permitting automatic renumbering. How does that > happen without disrupting established TCP connections? What I am talking about is not *just* automatic renumbering, but renumbering with aggregation, and on large scales eventually including the entire Internet. Internet-defrag, so to speak. The sub-problem of preserving TCP connections has been variously addressed in other scenarios, e.g. in Snoeren and Balakrishnan's Mobicom'00 paper. There are TCP protocol extension proposals to allow renumbering of end points within the connection. Given the relative infrequency of re-aggregation, say weekly, and the increasingly shorter lifespan of TCP connections on the external Internet, it might even be worthwhile in subnets to simply carry the old address till the existing TCP sessions terminate. It would have been neat if TCP already had the provisions to allow transparent renumbering, but the difficulties of developing and deploying this feature appear to be increasingly less significant, compared to the savings that would result from automatic renumbering and aggregation.
Re: kernelizing the network resolver
On Tue 2002.11.05, Keith Moore wrote: > No it doesn't, because your overloading of DNS names for this purpose > interferes with their utility for other purposes. > > Keith Imho, use of A records is not an overload.
Re: kernelizing the network resolver
On Tue 2002.11.05, Keith Moore wrote: > purposes, or for all apps. My concern is that an API that "encouraged" > apps to use DNS (by making it difficult or infeasible to use IP addresses) > would cripple that's platform ability to support some kinds of apps. INFS is simply a VFS wrapper around the existing socket implementation. Check it out - the kernel patch is not for disabling the socket() call, but rather, to add two new hooks, sock_morph() and sock_demorph() to the existing sock_create() and sock_destroy() entry points. In short, you continue to have the full socket API with no impediment to its use. INFS is meant to be a high level addendum to the socket API. This is in keeping with the spirit of Unix that there be high as well as low level APIs, like /dev/hd0 and /proc, etc. > > The previous paragraph answers this to the extent INFS supplements > > the current status quo and the limitations of the DNS. > > I don't see how INFS supplements the limitations of DNS at all. The INFS is a general VFS wrapper. My thesis talks about an alternative namespace that goes beyond DNS in many respects. As I'm still working on filling in some details, it's probably better to hold off discussion on that for a couple of months. > Personally, I would prefer a variable length address space, and I think > the technical performance issues with this could have been addressed. This was discussed in the Nimrod proposal in the early 90s. However, it would still be low level and impose manual end to end coordination effort like IP. The advantage with going to a name-based primary addressing scheme is that the address space in many senses defines itself. > Even assuming that a variable-length IP address were better, that would > not argue for trying to overload DNS names to do that job. Not at all, and the DNS is indeed not what I had in mind. On the other hand, both Nimrod and the more recent Francis and Gummadi's IPNL schemes, as well as Cheriton's Triad at one time, depend on the DNS for linking routes between route map regions (in Nimrod) or realms (Triad, IPNL). > So you'd prefer that the network advertise routes to DNS suffixes > to having it advertise routes to IP prefixes, and forcing DNS > to reflect network topology? Not really. I'd prefer (a) a different kind of namespace that's designed for this purpose and (b) a two level approach in which this other namespace reflects topology only between realms, leaving the intra-realm routing to IP and DNS. This is somewhat like IPNL, but avoids protocol shims and the 48-bit limit, among other differences. > Forgive me if I don't read your whole thesis right now. If you have > a 10 or 20 page summary I'd be willing to look at that. The first 17 pages pretty much cover the philosophy and the principles of architecture and operation, with tons of figures. The remaining sections are mostly algorithms that can be skipped. I'm working on condensing it somewhat for the Annals special issue, but it would probably mean throwing out many figures. Sigh. If you recall, we had a good bit of discussion on this mailing list last year, following a very premature I-D I'd put out in Nov'00. I learnt many things from that discussion, such as the notion and the importance of orthogonality between the DNS and IP-level routing. [ Speaking of orthogonality, I made the observation, in my INET'01 poster, that DNS and IP are not really orthogonal because of the overlap of identification role - the right word should be independent. To have orthogonality, one must have only identification and other, only location. Since you can't strip the id role from names, it must be stripped from IP, and that's what my thesis is about. ] sincerely, -prasad.
Re: kernelizing the network resolver
On Tue 2002.11.05, John Stracke wrote: > >I see both as largely system calls API issues, permitting simple and > >elegant solutions, and as not fundamental networking constraints that > >would legitimately rule against the INFS approach. > > > I disagree. The answers you give seem to say that you assume there are > only a few possible variations on an application's needs, which is not > the case. Au contraire, I am simply being more open to the idea that the OS interface can be as simple and general as applications need it to be. But, that's admittedly a matter of faith - in some cases, for example, with SysV's streams modules, the generalization can become complex enough to limit it from general adoption. > (a) This requires that the kernel be able to support the cache logic > that the app needs. The only way to support apps with novel > requirements is a minimalist API on which the app can build its own > logic. That's the lesson of Unix--and, for that matter, of IP. True, so aren't you assuming that use of INFS somehow prevents use of the traditional socket system call for the special needs? The lesson of Unix is also that while we provide a high level i/f that suffices for most apps, we also provide a low level i/f - viz the /dev/hd0, /dev/hda etc. interface available for special needs. It's in Windows that I don't see a convenient low level access for the disk, the usb, etc. Unix is a minimalist, not a restrictionist, philosophy, and this is in fact reflected in my implementation - the kernel patch merely adds sock_morph() and sock_demorph() to support INFS, it doesn't subtract anything. All I'm saying here's another way, try this too, maybe in some cases, like small wireless devices, you'll find it advantageous. It doesn't have to be equally advantageous for large, wired servers. > (b) Per-process is not sufficient, because a given process may need > several different styles of caching. For example, consider a > conferencing program with an embedded LDAP client. I meant that as example. The source code is there so that people can try more imaginative things out if they want to. (so please don't give me *all* the ideas or the others will feel left out ;-) > >For the second requirement, a simple known approach is to pass the already > >open (socket) file descriptor as argument when opening the secondary > >connections, so that the fd serves as an abstract handle for the previously > >obtained address. > > > That works only if the first connection is still open. True, but that's not the only trick up the kernel programmer's sleeve. > In addition, not all applications use connected sockets. If you're > using a UDP-based protocol, it may be more efficient to have a single > unconnected socket, and specify the recipient address on each packet you > send. This is especially true for servers; if you've got lots of > requests coming in, and they don't require a lot of user-space CPU, then > the cost of creating a new socket for each request could add > significantly to the cost of serving the requests. Of course. The neat trick of INFS is that it reuses the open(2) system call for connected sockets, since the filename argument can be used for the DNS pathname. However, it's a trivial matter to arrange the code to return an unconnected socket for a null filename argument, which is what you'd generally want for server-side sockets. With unconnected sockets, it is known that you can't use read()/write() calls in any case, and must use the send()/recv() calls that take a destination parameter. For the INFS version of send/recv, we'd allow a DNS name as the destination argument, but note, as already mentioned above, that the low level socket API remains intact - the old send/recv calls will work. > And you think you won't encounter inertia trying to get people not to > use sockaddrs at all? No more than Linus' world conquest, which gives me hope, imho! > Securely? And what about all the non-TCP-based protocols? Perhaps - why not check out the Snoeren-Balakrishnan paper? I'll assume that, for the purposes of my thesis, those problems are or will be solved by people specialized in those areas. Also, I'm tempted to add: And what about all the non IP-based protocols, for good measure? Are we absolutely sure that there is no good feature in any of them that we have not already compromised by going to IP? [I do allow for non IP protocols also in my thesis, since with names as primary addresses, I can have that luxury. It is IP, IMHO, that appears to be more biased and restrictive.] -p.
Re: kernelizing the network resolver
On Wed 2002.11.06, John Stracke wrote: > V Guruprasad wrote: > > >In short, > >you continue to have the full socket API with no impediment to its use. > > > This is misleading. You say that your main motivation here is to move > the identification role out of IP up to DNS, and moving the resolver > into the kernel is a necessary first step for that. But it's not a > sufficient first step; to eliminate IP addresses as identifiers, you > have to remove the socket API. No more than you need to disable the socket API for MAC layer or ATM AAL5 access. > >Since you can't strip the id role from names, it must be stripped from > >IP, and that's what my thesis is about. ] > > > > > You can't strip the ID role from IP, either, unless you provide a new > form of ID for transport protocols to use. Read my thesis.
Re: kernelizing the network resolver
On Thu 2002.11.07, Keith Moore wrote: > And those shortcomings are more-or-less inherent in DNS - you really > can't fix it and still have a namespace with the characteristics we > want in DNS - e.g. federated assignment, federated lookup, and ability > to assign names to groups of hosts or services. > > (some people think DNS should have only been used for host names, but > we're long since past the time when that was a reasonable assumption) That's why we need a different namespace approach, which looks close enough to the dns at the user/application level, so that the same API(s) will work, but is architected differently. Carpenter had remarked back in '01 that maybe what I had could be better described as a more successful namespace. However, getting that published as a networking paper seems as hard as the classical derivation of Planck's law and the missing thermodynamic details they don't want to learn. It's so frustrating to work alone and become unable to communicate, even if it lightens the inertia to make great leaps quietly :( -p
Re: kernelizing the network resolver
Dear Keith, Sorry I couldn't respond earlier (if, that is, a response was expected). On Thu 2002.11.07, Keith Moore wrote: > problem is, if you keep the same API, then apps that depend on that API > will expect that the name space has the same characteristics as DNS, > (benefits and shortcomings and everything else). so for instance they > will still try to bypass DNS when DNS would have been a poor choice for > them. > > even if the resulting architecture makes more sense than the old one, > you can't expect to be compatible with existing apps if you significantly > change how the services that were accessed by those APIs work. The essence of my thesis is as follows: - A namespace suffices as the end to end primary/effective address space in itself - no lower level or manually set up destination labels are necessary to define names. A distributed name tree is itself an effective addressing mechanism, and provides default end to end routes by up-and-down treewalk. (Of course it wouldn't be optimal, hold your horses. Let's start with a Pascal-like simplification at the high level for once, and treat the practical/optimal/efficient/whatever routing as a separate implementational/compiler/route-translation problem.) - Fixed length numeric addresses (FLNA) for routing, as in IP, can be automatically assigned and reassigned to the names for non-triangular/efficient/etc. routing, so long as * an end to end primary EA space remains available for datagrams and new connections; * ongoing connected sessions are switched over transparently, but this, as in Snoeren/Balakrishnan's paper for TCP, should be treated as an individual protocol level issue rather than an address space and management issue. Note: I prefer the terms 'allocation' and 'assignment' for FLNA because these terms are already used broadly in automated software like OS's and device drivers for things like real memory/IO/bus addresses and interrupts. 'Renumbering' appears to be special to IP and connotes two things: (a) that a human agent must be involved in deciding and effecting it, and (b) that the connected universe constitutes a single numeric label space. This is undue baggage that would limit reconsideration of the assumptions currently made for IP, as will be clear from the next bullet. (In fact, (b) is not even physically sound on the unlimited scale that I allow for.) - Notice that: * Routing with FLNA can and would be done using automatic route discovery, within each FLNA space, which ensures *independence* of the FLNA-based actual routes from the namespace structure. * Since every FLNA space involves management and FLNA are reflected in routing tables, each FLNA represents *networking state*. * We do not need, and in fact do not use a single FLNA today. VPNs are FLNAs stacked vertically because of the end to end paradigm we have been following philosophically. NAT gateways illustrate horizontal tiling of FLNA spaces, although in conventional NAT, the FLNA spaces overlap (over 192.168 etc. private network ranges) and are not disjoint. Using virtual path style state representation in the gateways can yield the same level of connectivity for the same state volume, with the essential difference that the address will now be faked both ways making the client space disjoint. Secondary issues like how the traffic will distribute across gateways concerns distribution of the state across gateways. This has been in effect shown for IP-like FLNAs in IPNL, and primary difference in going to 2-way NAT or virtual paths is the signalling/initialization mechanism for the state set up, not its resulting volume. In other words, virtual path/circuit state represents horizontal tiling form of network state - there's no getting away from state altogether, only how much we keep horizontal and how much vertical. To compare, IPNL describes a limited form of tiling. * Given the state equivalence and the availability of an end to end EA in the form of names, which applications already have to consult every so often (from what I seem to recall reading, netscape caps the ttl to 15 mins regardless of what the dns said), there is no reason to continue mandating end-to-endness of an FLNA, which means vertical stacking only as in VPNs. - Within an FLNA space, the route translation problem fromnamespace to non-triangular/efficient/optimal/ best-effort-but-better-than-Prasad's-namespace/ whatever-you-want-to-do routes reduces to the name->FLNA problem which is the
The original NSAP variable length addresses
On 25 Apr 2000, you'd written: > One interesting example: OSI NSAP addresses are variable length, with a > theoretical limit of 255 bytes I believe (perhaps there's an escape > mechanism to grow them longer?). There was an "implementors' > agreement" to limit the maximum length in actual use to 20 bytes "for now", > to make implementations practical. Two things happened: > > (1) Almost all of the addressing plans designed for NSAPAs > produced addresses that were *exactly* 20 bytes long, in > some cases inserting padding in the middle of the address > to fill it out to 20 bytes! I suspect that was done to > make the address allocation job easier, e.g., making > sure delegation boundaries fell on byte boundaries. > > (2) Many of the implementations ended up with the 20-byte limit > wired into them, such that the use of addresses longer than > 20 bytes would have required updating most of the installed > base (the changes being of a similar nature to those required > to modify an IPv4 application or protocol to support IPv6). I'd like to cite this in my thesis, and am looking for a published reference that states the reduction. My search to date has turned up documents, like the ATM UNI, that spec only the 20 byte max length. Maybe I'm not looking in the right places... Could you or anyone else possibly give me a pointer?? I'd be greatly obliged. thanks, -prasad. --- V. Guruprasad, Inspired Research LLC. http://www.columbia.edu/~vg96/papers.
Nimrod is still ugly - was: NATs *ARE* evil!
> Were we to i) incrementally deploy and start using new globally unique > namespace(s) [either a single one functioning much as IPv4 addresses > functioned originaly, or, as many of us think would be wise, two separate > ones, one to identify entities for end-end communication and another to give > topologically related names to communication devices], and then ii) > reinterpret the 32-bit fields as "local forwarding tags", then NAT boxes > would cease to be an architectural ugliness, and become merely engineering > ugliness. > > "I trust I make myself obscure." (And a tip of the hatly hat to anyone who > recognizes the source of that quotation... :-) > > Noel Now that we've figured out the first step and admit to the remaining ugliness, maybe we can take the next... Here goes: One basic reason Nimrod is still ugly is that it leaves us to deal with real addresses. The art of doling out virtual addresses and doing virtual-to-real translation behind the scenes, and quite efficiently at that, has been known in the OS arena for over three decades. Even PC OS's have it today :) Isn't it time to graduate to the network analogue? Yes, it takes a mental leap - even binary search isn't as simple as linear, let alone Unix to the DOS-groomed. But if you want performance, scalability and elegance, it's possible, it's already shown, and it's waiting for the brave new world. Far more importantly, which point is sorely missed in the Triad and Nimrod proposals and where the real mental leaps comes, it doesn't require throwing the v4 (or v6) baby out with the scummy bathwater. ["and still the earth moves"] -p.
Re: Nimrod is still ugly - was: NATs *ARE* evil!
> If you find a way to select paths in real networks using only virtual data, > we'd all be interested to hear it. Try draft-guruprasad-addressless-internet-00.txt, and the ECUMN'2000 paper on which it was based, at http://affine.watson.ibm.com/tmp/vinet.pdf The draft doesn't yet mention the log(N) bounds on the routing complexity, but I did try to explain that real addresses are obviated at all levels. A detailed comparison of addressing and addressless principles is yet to be made, hopefully soon in the next revision and/or paper. -p.
Re: NATs *ARE* evil!
Hi Keith! On Tue, 19 Dec 2000, Keith Moore wrote: > mumble. as far as I can tell, both DNS names and IP addresses > are hopelessly overloaded and are likely to stay that way until > we figure out how to make a major architectural change. Could you please take a look at draft-guruprasad-addressless-internet-00.txt ? It's been done, and at least one conference PC rated it a best paper (online at http://affine.watson.ibm.com/tmp/vinet.pdf), so it couldn't be so bad as to be left in total oblivion while everyone continues in endless inane discussions :-( More to the point, everyone I did manage to present it to in the hallways at the 49th IETF did like the idea. I'd hate to list the nodders, but the list includes at least one IAB member, one W3C person, and an important contributor to IS-IS and OSPF, as I recall. "only an asteroid can clear the dinosaurs..." -p.
Re: NATs *ARE* evil!
On Tue, 19 Dec 2000, Jon Knight wrote: > are on and what the address of their gateway router is. Not exactly what > I'd call omniscience. All right, I confess, I'm not perfect in summarising the existing art and relating to it (yet). I promise to gratefully acknowledge comments such as these that will doubtless help make the next revision more readable :) > Surely DNS addresses are more equivalent to the virtual memory No, in the sense I was arguing about, the DNS hostname points to a physical host (or interface, etc.), and is therefore a physical address. > of virtual memory is that it makes it easier for the user (well, > programmer) by hiding the nasty details of which physical address your IMHO, hiding is not the primary function of virtual memory addressing, although it does spin off as a powerful means of security (Section 2.1.3 - security by invisibility). > code and data live at. The whole point of the DNS is that it makes it > easier for the user by hiding the nasty details of what IP address you > need to talk to. And that's without getting into the situations where a That's high level programming language, not virtual addressing... This point is particularly brought out in my proposal, as the routing is literally accomplished as a (distributed) compilation (see attribute grammar examples in Section 2.4.4, page 28). > mention URNs at all and yet alot of what it seems to do appears similar to > the ideas behind the URN efforts of the IETF in the past. Similar sounding ideas, but no semantics match, really, since the underlying premises are fundamentally different. -p.
Re: NATs *ARE* evil!
On Tue, 19 Dec 2000, Mike Fisk wrote: > explosion. So over time there becomes an established club of roots and > everybody else has to be a child. That creates a monopolistic situation > where you have to pay a root node for transit. It could work, but it > sounds worse than the existing DNS root mess. > > How do you preserve the decentralized resilience of the Internet with such > a hierarchy? We do have such a thing in the Internet today. It used to be DARPA, and now it's IANA, and is still very much US-centric; we have regional bodies spec'd out for IPv6 that will control not only names but also addresses. In the proposed framework, you would only ask your immediate provider for connectivity - (s)he doesn't have to coordinate nationally and internationally to give you an address, and it's enough if your chosen name doesn't clash with something already registered at the provider's name server. So I'd think it's less of a mess than the DNS and IP are today in that regard. > maintain a reasonable number (< 100k?) of peers. For efficient table > lookup, there would be a push to standardize on a length limitation. So > You've just created a situation where the root club will enforce > sufficient hierarchy so as to limit the size of route tables. Like //com/ibm/watson/affine/tmp/vinet.pdf? Seems to be working ok for now. What I'm wondering is why/whether the residual defects, which are common to the DNS, should detract from the improvements/alternatives/differences that you haven't commented on. thanks, -p.
Re: NATs *ARE* evil!
On Tue, 19 Dec 2000, Mike Fisk wrote: > It's one thing to hand out addresses or names. It's another thing to run > a top-level routing server that all of your children customers have to > route through to get to other top-level providers. Your mapping between > the two would imply that, for instance, all traffic between europe and > japan would have to transit across a RIPE top server and a JPNIC top > server? Only in principle. No more than typing http://www.nokia.com from Finland would route the lookup to the .com root server in Washington D.C. Also, you're misreading it as "all traffic" - it should be "all connection request traffic". > Again, the hierarchical addressing is nothing new, but the fact that > you're tying routing to the same hierarchy will have new side-effects on > routing that need to be understood. Spanning tree, faster but suboptimal logical path. You wouldn't want your data to go that way. > Right now, routing is orthogonal to addressing and DNS naming. You're The orthogonality comes from the translation. The translation goes sideways from the name service spanning tree. Secondly, it does not need to know the global network topology or addresses. You still need IGP (or equivalent) to supply the translation rulebase, but no BGP, so to speak. > removing addressing and tying routing to naming. Now your name servers > have to route packets and be aware of peering relationships. That has No. Their job is only to compile connection requests, distributed fashion, into the data paths. Peering relations would be presumably compiled by IGPs for them, but that's as much as they need to have to get the connections going. Btw, I'm still working on some aspects of translation optimisation and failure recovery, which will be critical if and when we try to apply it on the Internet scale, and which I expect will reach a conclusive level within the next few months. On the other hand, these aspects are not critical for deploying over the existing Internet, or even for "addressless" cellular Internet connectivity, for example, since the latter will be routed through transcoding gateways for the foreseeable future in any case. thanks, -p.
Re: NATs *ARE* evil!
On Wed, 20 Dec 2000, John Stracke wrote: > > Why don't you read the I-D > > I did. Then you'd see that the invisibility refers to that of the server host, as follows: The client sees only the service name binding in the form of the URL, but what it gets as the data path is a virtual path (or LSP) handle. Since the label changes at each hop, the path index visible to the client host relates only to its own handle or file descriptor for the path, and is not enough to identify the server host. (The server host gets revealed only if there's only one hop.) Obscurity would mean that a unique server host address exists but is not advertised. Invisibility means that a unique server host address does not exist at all. This is a harder condition. If my approach is implemented *in addition to* end-to-end IP, you do get compromised because the IP layer supplies the host address. But the defect would be due to the IP layer, NOT my framework, which is happy as long as it can do MPLS end-to-end for transport. In particular, one does not need IP per se under my framework, and in that aspect, one can continue to use the higher IP protocols, like TCP, UDP, SCTP, etc. e2e because they'd run on top of the virtual path endings. One question that was unclear till the IETF meeting was whether these higher protocols could indeed be fooled to work independently of IP: the proof of principle exists - in Cheritan's Triad project at Stanford, the 32 b IP address is faked in similar fashion. Incidentally, Triad was substantially what I had initially proposed within IBM in 1995-1996, and we didn't see it as being of more than academic interest at that time. best regards, -p.
Re: Addressless Internet [stalker alert..]
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 t
Re: NATs *ARE* evil!
On Wed, 20 Dec 2000, John Stracke wrote: > I say it's a weak form because I believe you are wrong in stating that "a > unique server host address does not exist". The URL (ick) is an address > for the server; it's just a higher-level address than an IP address. The "URLs" in my approach do not identify the server host, and it's NOT a higher-level version of the IP address. See Section 2.1, which states the extent of weakness, and 2.3.9 which charts the conditions under which the information can be leaked to the client. The fact that my "URLs" are not high-level host addresses was specifically brought out at the ECUMN'2000 workshop-like conference, where the impact of this development was so strongly felt that attention was drawn to this right from the introductory plenary session. The purpose of the architecture is not to provide security, however. [ btw, what's (ick)? ] thanks, -p.
Re: Bottom feeders
On Wed, 20 Dec 2000, Keith Moore wrote: > > maybe the registration form should have a short quiz on material from > these documents, which must be filled out before the form is considered > complete. and if not completed successfully the prospective > registrant is warned that he may be wasting his money. Including the overcrowding statistics, and warnings that the venue is not the yankees stadium, that he might not make it into the door, and that making it in is no guarantee of audibility, might help emphasize the potential waste! -p
Re: Bottom feeders
On Thu, 21 Dec 2000, Ken Hornstein wrote: > That hasn't been my experience; I've seen what can only be described as > an "old-boy" network in operation. I'm not saying that such a thing is > necessarily bad, just that sometimes it takes significant effort to > overcome it if you're a newbie. Both the "old-boy" network and the undue skepticism are natural and occur in every field. My intuition is, if you try to suppress them, they'll show up in other ways! On the other hand, I was a first-timer at the 49th IETF (although I was already known to some in mmedia wg before), and had a rather atrocious proposal to lobby for (see my I-D - you *can't* possibly believe it at first reading :-). I've seen no less openness and no more skepticism at the IETF than within my own organisation. I think the people are wonderful, including many "old timers" - I quite enjoyed the many first-hand stories in the many hallway discussions. just my 2c. -p.
Re: IETF logistics
On Wed, 20 Dec 2000, Michael Richardson wrote: > The wireless access is likely key to actually giving everyone a chance to > get online, but I recall a lot of useful work that occured in the terminal > room. I also recall deciding to go to the terminal room rather than find a > session that I can "cross-fertilize" --- now if I pick wrong, then I just > don't pay attention, but I still take up room. (I become aware of my own Here's an outlandish solution: these problems might go away (as new ones will doubtless emerge) if and when we get live feeds out and inject keystroke feedback, in reverse direction, into the live meetings. [visions of hum-counting web pages, holy matrix] That would take care of non-participation (a) from terminal rooms residence, (b) because of overcrowding in the meeting rooms, and (c) budgetary constraints preventing travel to the IETF meetings... In limit t->infinity, enthusiastic newbies like myself would go there merely to watch the work being done remotely. -p.
Re: NATs *ARE* evil!
On Thu, 21 Dec 2000, Mike Fisk wrote: > Yes, I was being slightly more general to include other gateways that > don't necessarily operate at the application layer: > TCP-splicing/spoofing, NAT, SOCKS, etc. > > The problem is that the protocol mechanisms to discover and use these > gateways are piecemeal and inadequate. That leads many of them to be > implemented "transparently" which breaks protocols that don't know there's > a gateway. One way to let higher protocols transparently cross such gateways is described both in Cheritan's Triad project and my I-D on addressless networking. The cut is made just above the IP layer - Triad shows that higher protocols like TCP can be made happy with pretending there's an IP address below. I more specifically propose a 32b switch path termination - as long as the 32b number serves to identify an e2e path, whether or not it is an e2e destination address and/or transits gateways would be irrelevant to the e2e operability of the TCP layer. In the limit of fine-granularity, NAT'ing becomes no different from label switching, so what I'm suggesting is that we take the bull by the horns once and for all and run MPLS over IP instead of under it... That way, you'd obsolete NATs and SOCKS in the longish run, but that's another story. -p.
Re: NATs *ARE* evil!
{I had written:}
> | from label switching, so what I'm suggesting is that we take the bull by
> | the horns once and for all and run MPLS over IP instead of under it...
>
> an mplsd-like tag fits neatly in the first half of an ipvsux destination
> address, although there are other places in the vsux header you can put
> tag bits if you're inclined to do so for stacking reasons or whatnot.
> ...
> this has all the same problems of NAT where there is no end-to-end
> namespace that is not TOPOLOGICAL in nature separate from but convertible
> between a namespace populated with globally unique IDENTITY names.
> (where that namespace can mean single hosts or service locations or whatever,
> but not two or more of these things simultaneously! overloading bad.)
>
> Sean.
The NATty problems also go away when the theme is completed with the
globally unique etc. namespace, with a different topology (but yet
a spanning tree by definition), and the conversion is formally handled
by automatic translation using a context-free attribute grammar distributed
en route, so that the label switched path is synthesised e2e without
having to return addresses to the client application. I.e. no "overloading".
The final architecture one then gets would be that described in
draft-guruprasad-addressless-internet-00.txt
-p.
Re: NATs *ARE* evil!
> IMHO what we need to change is the *implicit* association between > "host" related identifiers and "network topology" related identifiers - > so that coders treat them as separate entities, and provide a way > for the two to be different at the IP layer - while still allowing > the optimization to take place where it makes sense. then you > only need to maintain the mapping for the case where the identifiers > are different. > > I'm still waiting for folks to see this "overloading" as a design compromise A fundamentally different approach that does achieve this separation is described in draft-guruprasad-addressless-internet-00.txt. > rather than a pure evil. not overloading at all would be even more evil. You don't have adequate grounds for the second statement unless you can formally establish that you have considered all *possible* alternative architectures. In other words, experiences with Nimrod or early-day relative addressing, or with UUCP, ATM, SNA, etc, cannot be adequate foundation. That also excludes potential knocking down of my I-D, but you evidently haven't read it anyway. > as it happens, I'm in the NSRG. but I also think it's useful to have these Especially where we need to be more careful in positing opinions, lest we prematurely block out good solutions because of such prejudices and shun away "newbies" proposing them (to borrow from another thread!). One might recall that astronomers had a similar complexity problem with the celestial routing of planets at one time, and the solution, taken for granted today (but not taught in all schools!), contradicted most educated and carefully conservative opinions. I submit a more open attitude might be healthier for the Internet and my I-D :-) -p.
Re: [midcom] WG scope/deliverables
On Thu, 2001.02.01, Hilarie Orman wrote: > Dave Cheriton's TRIAD is an example of such a proposal. > > Hilarie > > >>> Dave Crocker <[EMAIL PROTECTED]> 02/01/01 11:05AM >>> > At 03:05 PM 1/31/2001 -0800, Ed Gerck wrote: > >You miss at least one other possibility. If it is possible to develop > >an addressing scheme that works in a heterogeneous network, then > >we can have point-to-point functionality across system borders and > >do not require a homogeneous address space to do so. Nimrod, not Triad - fails heterogeneity. -p.
Re: [midcom] WG scope/deliverables
Eliot, On Wed, 2001.02.14, Eliot Lear wrote: > With all the discussion of Napster and so-called "peer to peer" networking, > I think NATs are going to become far more visible to users as these > applications grow in popularity. Today, you can use something like Gnutella > if at least one party is not behind a NAT. With the addressless overlay architecture, you don't need any party to be outside the firewalls. So the premise is incorrect. I'm keeping relatively quiet because I'm busy implementing a prototype system myself, and hope to demo it within this semester (honto ni) :-) (Please read my soon-to-be-published revised paper, which Carpenter says is much clearer than my I-D, temporarily housed at http://affine.watson.ibm.com/tmp/ - see Annals - unlike the Triad, this one's been peer-reviewed and published twice, plus almost all IP protocols would work, not just TCP.) regards, prasad.
Re: [midcom] WG scope/deliverables
On Thu, 2001.02.15, Lloyd Wood wrote: > that webpage is still black on black. The style file on http://affine.watson.ibm.com/tmp/ has been commented out, since some versions of Mozilla (4.05 on SunOS 5.6??) appear to be broken. -p.
Re: [midcom] WG scope/deliverables
> You give a name to your house (say, "The Tulip") and > the post office knows where The Tulip is. If you move, > you can do the same at your new location, provided > there is no conflict. This seems to be more similar to the I suspect it only works in rural areas - I recall walking past 27A Wimpole Street and humming the rain in spain. Back where I grew up, the village postmen not only deliver without numbers, but read the letters too for those who can't :) > notion of using an IP number as a name -- but isn't this > why we need DNS? ;-) Beg to differ - the reason we need the DNS is because its hierarchy mirrors instead of routing. If it (the hierarchy) did routing, it (the DNS) wouldn't be mirroring and that might change the loading/scalability issues with the DNS. -prasad
Re: Writing Internet Drafts on a Macintosh
Hi, On Wed 2001.02.21, Bora Akyol wrote: > I am trying (trying is the key word) to write Internet drafts on a > powerbook using MS Word with the template from the IETF web-site, > then using a PC to convert Word to text per the instructions. > > Is there a better way to write IDs on a Mac? I personally prefer LaTeX because it vastly simplifies cross-references within the text. LaTeX should be platform-neutral, but the dvitty driver given is ancient. I had to tweak the dvitty code a bit to get the import of ascii artwork almost right. The only other things that needed slight touchup were the equations. Perhaps I should post the dvitty patch somewhere... > Also, why isn't HTML an accepted format for Internet Drafts, pretty > much everyone on the planet should be able to read an HTML file (even > using Lynx on a terminal)? and that goes for pdf too, given that the irs uses it too :) -prasad.
Re: alternate guide to london
On Wed 2001.03.21, Jon Crowcroft wrote: > this is a solicitation to peopel that know london > (the venue for the next ietf) Any idea when this is likely to be? [ Sorry I couldn't make it to "mpls" to enjoy the winter, this prototype for my I-D has me so tied, but I'd sure like to plan for the next one. > http://www-mice.cs.ucl.ac.uk/ietf/ and thanks for putting the month in the middle, where it properly belongs. ] -p.
