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

[Brian E Carpenter <brc@zurich.ibm.com>]

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

Noel Chiappa wrote:
> 
>     > 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

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

NEW ADDRESS <brc@zurich.ibm.com> PLEASE UPDATE ADDRESS BOOK