Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: On identifiers: w hat is virtual and what...)

From: [email-masked] (Noel Chiappa)
Date: Fri, 1 Dec 2006 15:44:02 -0500 (EST)

> From: "Fergie" <[email-masked]>

    > I wonder if we happen to be using the term "overloaded" a little too
    > liberally to have a useful dialogue?
    > What is overloaded? ... perhaps it is time we revisit what what that
    > might actually mean.

OK, here's my take. I feel that it does have a pretty specific, defined
meaning (and it's not identical to the general English meaning of "overload",
alas; just as "force" to an engineer means a vector, not a general concept).
My sense is that system architects have taken the term, pretty directly, from
the computer language people.

There, an operator/etc is said to be "overloaded" if it is, in isolation,
ambiguous, and one needs to consider the context to know what it means. A
classic example is the "*" operator in C, which might mean either "multiply",
or "indirect through pointer". (Just for extra grins, in C one used to be able
to say "a = *p" and "a =* p", and they meant totally different things! So that
"a=*p" really was formally ambiguous.)

The extension to the system architectural world is pretty straightforward.
So, to me an identifier is "overloaded" if it can be used for a variety of
entirely different purposes; e.g. an IPvN address can either identify an
entity at one end of an end-end communication (as it does in the TCP,
specifically in the checksum), or it can identify a thing (interface, in the
usual case) that the system of routers will deliver a packet to. Use of IPv6
addresses to serve two different functions, in SHIM6, is overloading (in the
technical sense) of IPv6 addresses. Etc, etc.

	Noel

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

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 3 Dec 2006 18:22:36 -0500

True it could have been on the same machine under a guest OS via XEN or
VMWARE and this is influencing my name too (which I now take back) the
transport connection IDs are also important to the upper applications
(which I don't suggest we dive into) and the instances of
virtualization, clusters, and other forms distributed computing at the
services layers evolving will need to alter the physical space that
handle the connections and I am thinking can we avoid migrating
transport identifiers as doing this with the complete tcp (one example)
state today is quite complex.  A transport identifier would be far
easier to either change or migrate (hand waving here for now clearly)
when it is not associated with location coordinates for network path.
The win here for this discussion and hopeful outcome is far beyond just
the routing core the IAB reported and caused us to begin here (well it
was kind a going on before I know).

> 
> Another important property of this class of protocols which I 
> think needs to be preserved and isn't by SCTP is that all of 
> their functionality is dedicated to a single instance, a 
> single connection. 

Yes SCTP kept that property but an option could enhance where your going
and no chance with TCP.

> There need not be any cross connection shared state.  Whether 
> you do this in actual implementation is your choice, but you 
> don't have to.

Agree.

> 
> It turns out that this focus/isolation has some very nice 
> properties when you start putting things together.

Agree.

> 
> Later,  I have some real work that must get done!

Can fully and completely understand I am trying hard to keep up here it
is important discussion.

/jim

> John

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 3 Dec 2006 18:22:36 -0500

Agree.

Agree.

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 3 Dec 2006 18:22:36 -0500

Interesting and well articulated.  My conern is that for us to get to
the end state for a model to build architecture can we expedite this
process by not overloading the identifier?  Right now I think not
overloading identifier is a fast path for us?

/jim 

> -----Original Message-----
> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Friday, December 01, 2006 3:44 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [arch-d] Some notes about HIP and SHIM6 (was Re: 
> On identifiers:w hat is virtual and what...)
> 
> OK, here's my take. I feel that it does have a pretty 
> specific, defined meaning (and it's not identical to the 
> general English meaning of "overload", alas; just as "force" 
> to an engineer means a vector, not a general concept).
> My sense is that system architects have taken the term, 
> pretty directly, from the computer language people.
> 
> There, an operator/etc is said to be "overloaded" if it is, 
> in isolation, ambiguous, and one needs to consider the 
> context to know what it means. A classic example is the "*" 
> operator in C, which might mean either "multiply", or 
> "indirect through pointer". (Just for extra grins, in C one 
> used to be able to say "a = *p" and "a =* p", and they meant 
> totally different things! So that "a=*p" really was formally 
> ambiguous.)
> 
> So, to me an identifier is "overloaded" if it can be used for 
> a variety of entirely different purposes; e.g. an IPvN 
> address can either identify an entity at one end of an 
> end-end communication (as it does in the TCP, specifically in 
> the checksum), or it can identify a thing (interface, in the 
> usual case) that the system of routers will deliver a packet 
> to. Use of IPv6 addresses to serve two different functions, 
> in SHIM6, is overloading (in the technical sense) of IPv6 
> addresses. Etc, etc.
> 
> 	Noel
>