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

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>

    >> 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