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