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.
I don't disagree, but the devil is in the details, and you also have to
pay careful attention to transitions.
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.
I can't comment on multi6 since I'm not up to date on what they are
doing.
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.
You are missing something fundamental here - if a TCP connection breaks
(isn't closed cleanly) then the two endpoints can get out of sync
regarding how much data was delivered. You can't fix this at higher
layers without an unacceptable amount of complexity and overhead.
This has nothing to do with the app/transport interface being a sacred
invariant - it happens any time you try to layer something on top of
transport that has to survive breakage of the transport layer.
(how many ways do I have to explain this?)
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.
It's a lot less glue than the L4-L7 approach, and most of it has to deal
with authentication that would be needed for any kind of
remotely-originated routing update anyway, regardless of what layer it
lived at.
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.
No, it doesn't make sense to add a considerable amount of overhead and
complexity that isn't needed and often won't be used.
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.
Yes you can do that but it presumes that the host knows a priori whether
or not it needs the stabilization layer. I would make the
mechanism used to provide stable addresses a property of the network-
either the network provides "reasonably" stable addresses (i.e. plenty
of prior notice before changing them) or it provides a stabilization
layer. That way, networks that don't need it don't pay the overhead.
Keith