Keith Moore wrote:
Second, this robs apps of the best endpoint
identifier they have.
Rather than being so locked into topology locators as endpoint identifiers,
we need to be specifying an infrastructure for endpoint identifiers and any
mapping protocol that might be needed. To some degree this is where the
multi6 design team is headed, but they appear to have a goal of
'transparently' stuffing the result in the lower layers. The one thing that
is obvious from that approach is that it will end up breaking something.
It is not worthwhile to suggest that the direct
application/transport
interface be eliminated, but it should be possible for an
application
to specify what kind of service it wants from the
(transport, network)
combination and something is there to handle that where the
requested
service is different from that natively provided by the
(transport,network) combination.
No, it's not worthwhile. Any kind of routing needs to happen
below the transport layer rather than above it. That's not
to say that you can't make something work above the transport
layer, but that to do so you have to re-implement routing,
acknowledgements, buffering and retransmissions, duplicate
suppression, and windowing in this new layer when transport
protocols already provide it.
This is simply wrong. Decisions about topology need to happen below the
application, but that does not equate to below the transport API, unless you
hold to the position that the app/transport interface is a sacred invariant.
...
The first one I explained above in slightly more detail. The
second one should be obvious. If an address becomes invalid
because of a topology change somewhere distant in the
network, how is a layer above layer 4 going to know about it?
It doesn't have access to routing protocol updates - those
happen at layer 3 and aren't normally propagated to hosts
anyway. When you think about it, you probably don't want
hosts to have to listen for information about distant state
changes in the network - that would place a tremendous burden
on small hosts and nets with low-bandwidth connections.
Yet you advocate propagating L3 changes to all host stacks so that some yet
to be defined glue can magically make the change transparent to the app.
Rather than relying on 'sometimes wanted, sometimes not' magic in the lower
layers, it makes much more sense to put an optional layer above L4 to reopen
a path using alternate topology information. This still allows the app to
choose a direct L4 interface, and removes the need to have the app say 'give
me mapping, or turn it off' in the API. That would be implicit in its choice
of the stabilization layer vs. direct L4.
Tony