Re: administrivia (on avoiding injury)

[Greg Maxwell <gmaxwell@martin.fl.us>]

On Tue, 10 Apr 2001, Jim Bound wrote:

>  
> > Once talking, all is happy until something fails...
> > 
> > Retransmit is tried against one of the other pairs (later ICMP errors
> > could be used to make the retry process smarter and faster) until
> > connectivity is regained.
> 
> This causes code waiting for pcb connect back to have to leave kernel
> space and head up to user space.  That is a performance hit that is not
> necessary and bascially states the connection must restart from the app as
> opposed to retransmit from the IP layer (best case).  This will work but I
> think we can do better. 

I was assuming that all of the prefixes would be mutually known before
link failure, and that one pair must survive to keep the connection up. I
don't think this is unreasonable at all.
 
> > The SCTP RFC covers a complete protocol implimentation that can do this.
> 
> But as I stated in my mail to Sean SCTP has no mechanism to 'create' a new
> endpoint except from another node telling it to in an association update.

Right. There should be some way for each sites router to push a new prefix
onto each end node, and there is already a draft for a SCTP extension to
add associations.

> Using the ND message extension I proposed it can be generated to the
> association.  I think the SCTP folks could absorb this and would if we
> presented it to them.  
> 
> With IPv6 it could just be a prefix update possible within SCTP.

> But this gets to other problem.  The nodes are not sending to the routers
> ISPx but to the node on the other side.  So other than an intermediate
> endpoint address via IPv6 Source route option it won't help much (but
> could be done and converge fast).

Well, I think a clean implimentation would use source based routing on the
border routers such that traffic with a source prefix of A only flows out
via ISPA. 
 
[snip]
> But doing dns pairwise resending is just a complete retransmit and maybe a
> good default but I think we can do better here.

Eeek no! 

DNS should be used at initation and initation only. DNS should be cached
(i.e. you should expect to have your link fail then suddenly learn via DNS
that the host on the other end has renumbered, at least not over a
reasonable time span). 

There is a proposed SCTP extension to add IP addresses to a live link.
This should be a basic functionality for any transport level multihoming
implimentation. See my assumption at the top.

'You have a new prefix' would be generated by the site router when:
1) It's upstream says to it 'you have a new prefix' (if the site allows this)
2) When the site's admin adds another link.

A future enhancement might add a 'think link is dead jim' message, so that
hosts can not waste their time retransmitting into /dev/null. Other
optimizations are possible, such as using information from other links to
figure out a path is dead, so retransmission is not needed on connections
that were idle when the link died.

I think all of that can safely be left for later as there are
complications, see the message I posted just prior to this one. 

> Plus if we start trying to go up to user space and then back to kernel
> space thats a hack for sure.  

Run away! Run away!