Subject: [arch-d] 1. the architecture

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Jan 2007 18:04:16 +0100

[It seems the discussions directly related to the IAB workshop have  
moved elsewhere, can someone give me a pointer?]

If we're going to talk architecture, we should discuss the  
architecture of what the network will do for its users, and the  
generalities of how it will accomplish those things. Naming issues  
are largely irrelevant to such a discussion.

At the highest level, the network is about allowing people, and the  
devices working on their behalf, to communicate. In that sense, it's  
perfectly reasonable to hold up something with a corporate logo up  
before a built-in camera and ask the computer or communication device  
to set up a connection towards the corporation the logo belongs to.  
Since putting images in the IP destination field doesn't produce the  
intended result, this obviously involves a number of disambiguation  
and capabilitity discovery/negotation steps that fortunately, we  
don't have to worry about in our little architectural corner.

But at some point these activities should result in something that  
looks like a URL. Today's URLs are pretty bad. The FQDN part is the  
best part, this even works so well that we haven't even bothered to  
improve our DNS technology significantly the past two decades. So any  
problems here are due to operational issues rather than fundamental  
ones, in my opinion. But the bad part is that we put the application  
part before the FQDN part in the URL, and a low-level detail in the  
form of the port number is implicitly or explicitly part of the URL.

A better architecture would be to specify a destination and one or  
more applications or communication methods that we are prepared to  
use, and then let lower layers take care of the rest. Each lower  
layer has to live with certain restrictions and brings certain  
additional information to the table. The same may be true for  
intermediate hops. So what should happen, is that the each layer or  
hop adds its own information, either in the forward direction toward  
the next layer or hop, or back to the previous one. At some point,  
the setup process reaches the destination, and if there is a  
sufficient set of common capabilities, the actual communication can  
start. Should at any point the communication stall (which we can  
detect using something similar to the REAP protocol that's part of  
the shim6 effort) we simply restart the negotiation process and  
uncork the communication after any required changes in the  
communication parameters.

More concrete: when I want to talk to www.google.com, my system  
consults a distributed database to find initial points of contact for  
this destination. In this particular case, that won't be an actual  
WWW server, but rather a list of dispatch/load balancing devices.  
When (for instance) I end up talking to such a device in Chicago,  
that one may notice that I'm better served by talking to an actual  
server in Amsterdam, so it gives me the address for the least busy  
server there. I may have to talk to another intermediate device in  
Amsterdam, or maybe I'm immediately connected to a WWW server. Since  
this is a WWW server, it tells my system to invoke the default WWW  
brower, or maybe, the Google WWW browser if available. If I only have  
a generic browser, my system says so so the Google server knows to  
omit any Google-specific extensions.

However, should I have be more paranoid, my initial packets to the  
Google point of contact could be intercepted by a local firewall  
which checks whether I am allowed to talk to the outside world and  
monitors the progress of the negotiation. When it notices that I want  
to use Intranet Exploder 1.0 as a WWW browser, the firewall consults  
its permission list and notices that there is a vulnerability for  
this version of that browser so it removes Intranet Exploder 1.0 from  
the list of applications (and sends an error message back to me for  
good measure). So either another application is selected for this  
session, or the session setup doesn't complete because there are no  
shared capabilities.

Notice that this isn't 1.609 million kilometers removed from today's  
practice, except that today, most information is lost between layers  
and hops so a lot of guessing goes on, often successful but also  
often annoyingly unsuccessful, and leaving us preciously little room  
to improve the current internet.

If designed properly, a network like this could handle all kinds of  
stuff that are very difficult today with great ease. For instance,  
the use of NAT becomes a non-issue as all the address rewriting now  
happens explicitly at known points. Interoperation between different  
network layer protocols is trivial for the same reason.

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: John Leslie <[email-masked]>
Date: Fri, 12 Jan 2007 15:52:31 -0500

> moved elsewhere, can someone give me a pointer?]

   (There's more discussion on <[email-masked]> right now...)

> are largely irrelevant to such a discussion.

   There are strong opinions about naming: I wouldn't call naming
"irrelevant"; but it certainly can be "distracting".

> to set up a connection towards the corporation the logo belongs to.  

   Agreed, but it's not our job to make that work...

> don't have to worry about in our little architectural corner.

   (If that isn't true, I'd argue we've chosen the wrong corner.)

> form of the port number is implicitly or explicitly part of the URL.

   This feels like the wrong corner to me...

><snip>
> this destination.

   ... which is exactly what happens today. What looks like a single
to the user can involve dozens of different TCP connections...

><snip>
> monitors the progress of the negotiation.

   Now we're getting near "architecture". Employers _do_ want to
control that sort of thing, and our current architecture doesn't help
them...

><snip>

   OTOH, most of what they want can be approximated by running all
employee traffic through proxy servers. The fact that folks look to
buy "firewalls" to do this is _not_ (IMHO) an architectural problem.

--
John Leslie <[email-masked]>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Jan 2007 23:52:49 +0100

> "irrelevant"; but it certainly can be "distracting".

My strong opinion is that it is largely irrelevant. There are two  
aspects to a name: its relationship to the object that it names, and  
its structure. It's tempting to attach meaning to names, but that's  
an exercise in futility, because whenever the circumstances change,  
so must the names. Successful names are ones that have no inherent  
meaning and can be used for many purposes. As such they're as  
interesting as a blank sheet of paper: lots of potential, but nothing  
else. The corollary is that for any long-lived naming system, that  
type of name will be used for all purposes it can possibly be used for.

The hierarchical structure of names may seem important at first  
glance, but once the names have been assigned, looking them up can be  
done with only slight differences in effort in several scalable ways.  
IP prefixes are assigned pretty much randomly, but we have very fast  
FIB lookup algorithms nonetheless. DNS names make for a nice  
hierarchy but finding arbitrary hash values in a distributed system  
also works with dynamic hash tables. Replication and other database  
techniques can make (distributed) lookups fast on pretty much  
anything. (The trouble is with distributed updates.)

Ok, maybe I'm being a bit too harsh here. You can encode one value  
into a name or address "for free". With CIDR that's a pointer to the  
ISP, but other choices are also possible. But CIDR isn't relevant to  
PI addressing, hence our troubles.

> to the user can involve dozens of different TCP connections...

The difference is that today, one end knows what's really going on,  
but it tricks the other end into thinking that we're dealing with  
1980s pre-CIDR, pre-DNS IP (which wasn't a bad architecture, just a  
limited one).

> control that sort of thing, and our current architecture doesn't help

What I'd like to see is all of this being explicit at the (meta-) 
session setup, rather than have firewall meddling show up as  
seemingly random breakage. Doing a recursive setup also allows both  
the transparent end-to-end model (talk directly to the destination  
and be done) as the degenerative case where we need to negotiate  
with / be NATed by each hop along the way, and, more importantly,  
survive any bad side effects from the latter. When we know that the  
school firewall doesn't allow us to talk to myspace.com we then have  
the option to engage the 3G radio and see if the cell provider is  
more liberal, if we care enough.

> buy "firewalls" to do this is _not_ (IMHO) an architectural problem.

Proxies is exactly what I had in mind. Because HTTP proxies see the  
real identifier and not just the one implied by the destination  
address, they can do much more than a NAT box. But I only want this  
at setup. Once that's done, packets should flow with minimal  
processing by intermediate devices.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 23 Jan 2007 15:10:54 +0100

On Fri, Jan 12, 2007 at 11:52:49PM +0100,
 Iljitsch van Beijnum <[email-masked]> wrote 

> processing by intermediate devices.

Isn't it the architecture of OPES? (RFC 3835). Once the complicated
things are done in the "callout server", the data flow only goes
through the OPES processor.

It seems OPES addresses most of your needs.