Subject: Re: [arch-d] Re: An example of how the requirements and right questions interrelate

From: [email-masked] (Noel Chiappa)
Date: Fri, 10 Nov 2006 11:49:32 -0500 (EST)

> From: Fred Baker <[email-masked]>

    > The big issue is that there are a variety of configuration elements
    > .. where it is just a whole lot simpler to configure the address, and
    > as a result the address is what is configured. Fixing this is a
    > non-trivial problem ...
    > And saying "well, if we just had <pick your protocol> defined and
    > implemented that would be solved" is naive - the big problem there is
    > that never mind what might or might not exist, the engineer designing
    > <whatever> chose to not use it. If the tool isn't used, it really
    > doesn't matter how wonderful it is. ...
    > one has to somehow touch every computer in an organization including
    > its network infrastructure and management and mission-critical servers,
    > and in touching them do exactly the right thing.

Fred, illuminating. I've heard this stuff before, but your examples are
interesting, and I like your description of the problem. The bottom line is
that being able to switch ISP's seamlessly is really a priority-one
requirement.

How many of these problems go away if one uses a NAT box to insulate the local
addressing domain from the global one? Yes, everything that's visible from the
rest of the Internet still has to be updated, but everything involved in
internal communication should be insulated, no?

Interestingly, NAT boxes don't solve the problem of *other* people changing
addresses - e.g. if company A has some other company B they cooperate with,
and B is allowed (to make up an example for illustrative purposes only, I
don't know if anyone actually does this) incoming FTP access through A's
firewall, then if B switches ISP's, A has to update their configuration.

As far as I can tell, the only thing that fixes that class of problem is to
use a different namespace for configuration, and, as you point out, that's
not trivial, to get people to change their habits. So jacking up the existing
internetwork layer, and changing internetwork addresses into true
identifiers, starts to look more and more appealing...

    > I will generally argue that one wants to name applications, not the
    > computers they run on .. The translations of these names into
    > addresses may result in single or multiple addresses, and in the latter
    > case they may be multiple interfaces on the same machine or they may be
    > different machines. In general, I think that is a very sensible model.
    > ...
    > There are many ways to cut this cookie: the addresses a system uses
    > can, when treated as an equivalence class, be called a locator or
    > endpoint identifier .. functionally, we have to have some solution to
    > the problem that the EID, however we understand it, solves.

This is kind of what I was alluding to yesterday, when I questioned whether
endpoints were really the thing we needed to add a namespace for, or whether
it should be some sort of higher-level entity (e.g. a "service", which is
actually implemented as a bunch of actual machines in a farm, which are
separate fate-sharing entities) - and then went on to muse that perhaps we
needed both.

We clearly need names for interfaces, because those are the places that the
system of routers delivers packets to. We clearly need names for services,
because that's what people (and applications working on their behalf) really
care about.

The thing is, do we need another namespace in the middle, to name one end of
a reliable transport connection?

Perhaps not, if one had a blank sheet, but at the same time, for the reasons
mentioned above, maybe it's pragmatic to add one, simply because of all this
installed grup where people are using addresses as identifiers.

    > the big problem that we have tripped over in this area is that we have
    > not kept names at the application layer and network layer addresses at
    > the network layer. They are in fact in the right places, but we manage
    > to distribute addressing information to a part of the system it is
    > irrelevant to, and in so doing shoot ourselves in the foot.

'Exactement'. And by now the problem is so widespread we may never fix it.
So, once again, jack-up looks good.

	Noel

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

---

From: Fred Baker <[email-masked]>
Date: Fri, 10 Nov 2006 14:30:53 -0800

> How many of these problems go away if one uses a NAT box to  
> insulate the local addressing domain from the global one?

or an address rewrite algorithm like GSE proposes, or a single  
address at the site which is independent of the ISP as is proposed in  
PI or Metro?

Some but not all. Consider the example of the shipping-management- 
system that has an externally visible and don't-you-dare-change-it  
IPv4 address. Well, even if we put the thing behind a NAT, changing  
that address is going to have to be done just right, and so on.

	Never underestimate the power of human stupidity.
	Robert A. Heinlein

And the flip side is that NATs don't especially help with application  
architectures other than client-server. I imagine you have taken a  
glance at some of the p2p applications floating around the net. I  
find the level of hijinks they go through for firewall traversal  
bizarre. I'm not among those who bristle at the mention of NATs, but  
I do agree that they represent a significant limitation on the  
application architecture at this point.

>> There are many ways to cut this cookie: the addresses a system  
>> uses can, when treated as an equivalence class, be called a  
>> locator or endpoint identifier .. functionally, we have to have  
>> some solution to the problem that the EID, however we understand  
>> it, solves.
>
> This is kind of what I was alluding to yesterday, when I questioned  
> whether endpoints were really the thing we needed to add a  
> namespace for, or whether it should be some sort of higher-level  
> entity (e.g. a "service", which is actually implemented as a bunch  
> of actual machines in a farm, which are separate fate-sharing  
> entities) - and then went on to muse that perhaps we needed both.
>
> We clearly need names for interfaces, because those are the places  
> that the system of routers delivers packets to. We clearly need  
> names for services, because that's what people (and applications  
> working on their behalf) really care about.
>

Hmm. Is that anything like a TCEPID?

My point in mentioning the NSAP yesterday and the TCEPID (its  
counterpart on the other side of the Transport/Network interface) is  
not to suggest that ISO generated the answers here. It is to observe  
in passing that while their protocols were not necessarily wonderful  
and many are OBE, there is some applicable thought there. This is  
familiar territory.

>> the big problem that we have tripped over in this area is that we  
>> have not kept names at the application layer and network layer  
>> addresses at the network layer. They are in fact in the right  
>> places, but we manage to distribute addressing information to a  
>> part of the system it is irrelevant to, and in so doing shoot  
>> ourselves in the foot.
>
> 'Exactement'. And by now the problem is so widespread we may never  
> fix it. So, once again, jack-up looks good.

Actually, I wonder how much of it could be solved by an appropriate  
redesign of the socket API so that the application only sees names.  
I'll bet that once we do that, it is a matter of time before the  
addresses move out most of the applications.

---

From: Fred Baker <[email-masked]>
Date: Fri, 10 Nov 2006 14:41:42 -0800

> addresses move out most of the applications.

let me put hands and feet on that.

one problem that I have with the socket API is, as I said, that it  
more-or-less requires the application to know something about the  
address. I recognize that there are legitimate applications that have  
this as a requirement - gated is an example. But in my small and not- 
very-wise mind, it seems like one could

	(a) create openSocketByName(char *)
	(b) do something to the existing open-socket-by-address call to make  
it continue to work but become truly undesirable.

Maybe every time it is called it prints out a message that says "oh  
my goodness, no truly cool user uses code that is still using this  
API; it's just so October 2006" or some such thing. Basically, allow  
people to continue shipping systems and applications but put some  
form of "you really want to switch to the new API" in there.

While fixing this, I would really like a user up-call to be built  
into the SYN/SYN-ACK cycle. It would be very nice if the application  
knew it had an incoming connection and could either accept or reject  
it, rather than having it completely opened before the application  
knows.

Note that the above has nothing to do with the id/locator split in  
the address per se. It's about making renumbering less painful.

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 10 Nov 2006 17:53:22 -0500

Java.net already supports connecting to a host name

http://java.sun.com/j2se/1.4.2/docs/api/java/net/SocketImpl.html#connect(java.lang.String,%20int)

(as a random example).

The practical problem is that life is more complicated now that we have 
more than DNS A records. Such an API would have to deal with rather 
application-specific modalities included in various retry algorithms, 
NAPTR, SRV and the like. With security protocol negotiation, this can 
get fairly messy; just take a look at RFC 3263 for the general flavor of 
what "connect to host A" has become. Unfortunately, the semantics of 
this differ from application to application, partially for historical 
reasons, partially because of genuinely different needs.

I also don't think that the socket API is the main problem. Generally, 
the address returned by the socket API is just passed as a blob or 
handle from one place (resolution) to another (socket), without the 
program inspecting it.

Henning

> this as a requirement - gated is an example. But in my small and 
> not-very-wise mind, it seems like one could
> 
> Maybe every time it is called it prints out a message that says "oh my 
> goodness, no truly cool user uses code that is still using this API; 
> it's just so October 2006" or some such thing. Basically, allow people 
> to continue shipping systems and applications but put some form of "you 
> really want to switch to the new API" in there.
> 
> While fixing this, I would really like a user up-call to be built into 
> the SYN/SYN-ACK cycle. It would be very nice if the application knew it 
> had an incoming connection and could either accept or reject it, rather 
> than having it completely opened before the application knows.
> 
> Note that the above has nothing to do with the id/locator split in the 
> address per se. It's about making renumbering less painful.
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 10 Nov 2006 15:33:23 -0800

On Nov 10, 2006, at 2:53 PM, Henning Schulzrinne wrote:

> I also don't think that the socket API is the main problem.  
> Generally, the address returned by the socket API is just passed as  
> a blob or handle from one place (resolution) to another (socket),  
> without the program inspecting it.

Maybe. There seem to be an awful lot of applications that have to be  
restarted to gte them to change the address. I would think that if  
the application was executing

	while (TRUE){
		socket = openSocket(getHostByName(name));
		while (socket is still up) {
			do whatever
		}
	}

then that wouldn't happen.