Re: where the indirection layer belongs

[Robert Honore <robert at digi-data.com>]

Dear Keith Moore,

I do not want to seem to be ganging up on you, but your reply to Mr. 
Hain just prompts more questions.

> 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?)
You might have to explain this really often and in simple language too. 
 But why do you assert that it will take lots of complexity and 
overhead?  Can you point to some code where they tried this?  As far as 
I know, nobody has really given this an earnest try as yet.  At least 
not with any IP protocols.

> 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.

What specific glue do you believe it requires for the L4 to L7 approach? 
 How does that compare to what is needed in an L3 solution?

> 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.

But I would argue that the host or at least the application's designer 
knows whether it will need the stabilisation layer.  Making the 
mechanism that provides the stable network addresses a property of the 
network leaves the question of how.  Even if that were achieved though, 
that still does not completely or effectively address the problem of one 
application process identifying its peer across the network.

Yours sincerely,
Robert Honore.