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