Subject: Re: Terminology [Re: Some Comments on ID/Loc Separation Proposals]

From: [email-masked] (Noel Chiappa)
Date: Tue, 9 Dec 2003 10:37:30 -0500 (EST)

> From: Masataka Ohta <[email-masked]>

    >> could you provide a definition of what do you mean by end system?

    > As I searched reference of the RFC, "end point" seems to be an
    > alternative wording of "end system" that if JNC is saying "endpoint"
    > with the difinition of Saltzer's paper, that is fine.

Which Saltzer paper? "End-End arguments", or RFC-1498 (which is the paper
that first pointed out that we needed to separate location and identity)?

In any event, there is a *significant* difference between my definition, and
Saltzer's paper: he talks (basically) of hosts (i.e. physical boxes), whereas
my "endpoint" definition is deliberately not tied to hardware.

This has the very important *practical* difference that at one particular
location in the network (i.e. whether one thinks that our "location-names"
name interfaces, or are topology-dependent names for end-things) one could
conceivably find *more than one* end-thing - e.g. if a host contains (for
whatever reason) two endpoints. If so, the packet needs to contain some
disambiguator to allow deliver to the proper end-thing.

Many schemes for doing location/identity separation don't provide this. E.g.
naive versions of 8+8, where the lower 64 bits is just the IEEE number,
don't. Whether it's an important engineering goal is not for me to say - I'm
just pointing it out.

Also, although my definition would allow it (unlike Saltzer's), I'm not sure
that in the real world, you'd ever see endpoints which cover more than one
machine.

Since endpoints are names for transport-level entities, in practical terms
this would mean that if one host in a cluster died in the middle of a TCP
connection, another could take up the connection, which would mean it would
have to know which packets had been ACK'ed, etc. In the real world, nobody
builds systems this way - you'd have to do a 2-phase commit or something
between the machines of the server on every packet to the client!

So perhaps this tells me that applications like the Web that want to be
robust need *another*, higher, level of naming, for a service - but that's
not our concern.

	Noel

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 10 Dec 2003 07:02:42 +0900

Noel;

> my "endpoint" definition is deliberately not tied to hardware.

Then, you must find another wording, though there is no point
insisting your point.

> whatever reason) two endpoints.

If end things are found at one particular location, which is
the *PRACTICAL* assumption, they share connectivity fate that
thier is nothing for M6 to worry about.

> If so, the packet needs to contain some

When a host has complex internal structure, feel free to something,
say, a port number, beyond a host address(es) for the disambiguation.

> don't. Whether it's an important engineering goal is not for me to say - I'm

Be practical.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Dec 2003 12:02:30 +0100

Well, this is actually an interesting discussion in the e2e context, but
the co-chairs are definitely of the opinion that it's gone beyond the point
of helping multi6 achieve its goals. So, folks, please continue on some
other list...

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK