Keith Moore wrote:
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.
And apps are in exactly that position today. This is still not a valid
reason to insist on adding complexity into the transport or IP layers. If a
connection breaks before closing, the notification up is 'broken', then
whatever is there has to decide if it wants to try something else. Today the
app has to have the complexity, but there is no reason we can't put that
into a stack layer once for any app that wants it.
It's a lot less glue than the L4-L7 approach,
That is a matter of speculation.
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.
I agree, but the lower layers are not designed with that in mind, so to some
it would appear you want a substantial amount of change to something that is
already working well. Never mind the transition/deployment/interoperability
issues.
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.
More speculation. In any case, if it is not used it is simply an idle module
at the top of the stack.
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.
Optimizing before the design is started only ensures that something will get
overlooked or dropped as 'too much overhead'.
I raised the 'right problems' thread after the observation that we had
several embryonic efforts to separate endpoint identifiers from topology
locators, but all of them are focused on inserting complexity into the lower
layers. Those layers don't need complexity to do their job, and any changes
in behavior will break current operational assumptions about how those
layers work. Also everyone agrees that the place that needs the complexity
of the current & future unstable network masked is the application.
Therefore the place we should be focusing solutions is in the interface
between transport & app.
--- Solve the right problem
Tony