john(_dot_)loughney(_at_)nokia(_dot_)com wrote:
A very quick question about your idea. Does this layer have a
protocol / interface to other elements on the network? Or are
you proposing something more like an abstract API?
Simple question, complex answer ... It really depends on where you are
looking at it from, and how the name space discussion gets resolved. As I
was writing that, it occurred to me that from the app perspective what you
want is to provide most of the characteristics of the transport API, making
it somewhat transparent but the layer is really a manager substituting
application name space identifiers for topology references, etc. At the same
time there may need to be some protocol between the layer peers and/or
infrastructure services to establish identities, along the lines of
HIP/DHT/enhanced DNS/etc. As I see it, the hard work is getting this part
done well.
The thought was that the protocol parts of TCP/UDP/SCTP/... do what they do
as directed from above, and do that efficiently. In the abstract, there is
no reason that the entity above them can't deal with changing connection
state, or topology attachment points. In the current environment though, we
have apps parked in that spot, and we agree that dealing with changes is too
much complexity to ask of apps in general.
Historically, since we have apps parked in that spot, there has been an
insistence that all of the topology complexity get resolved in the lower
layers. Pushing complexity into the lower layers makes them less efficient,
and will unnecessarily break many of the operational assumptions that exist.
Providing an optional stabilization layer above transport allows endpoints
to come and go at different points in the topology, while the application
remains oblivious to the changes.
Tony