> 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

Reply via email to