Re: address pair exploration, flooding and state loss

[Erik Nordmark <erik.nordmark@sun.com>]

Iljitsch van Beijnum wrote:

> I'm not familiar with DCCP. Will it be implemented directly on top of  
> IP? That won't be much fun in IPv4, with firewalls and NATs and all.  
> Since general purpose transports need port numbers and a checksum  
> anyway, running over UDP is generally a no-brainer.

See draft-ietf-dccp-spec-11.txt
Runs on IP - not on UDP.

> I would agree about actually being able to work. However, the only  
> thing we're talking about here is recovering from state loss. This is  
> hardly a critical function, especially if we can make it work for 95%  
> of all applications without any trouble.

I'm under the impression that one of the reasons to multihome is to get 
better reliability/availability. With that goal in mind it seems a bit 
odd to introduce some new failure mode in the shim protocol - such as 
not being able to recover from state loss.

> Obviously an alternative approach that can do this without any other  
> downsides would be great. But robbing a bit isn't easy.

I recall some noid draft where I and Tony Li had worked out a way to do 
this a long time ago. That approach works when the flow label is used to 
carry the context tag.

If we carry the context tag in a new extension header/option we don't 
need to rob a bit, since the precense of that protocol element would 
indicate that the shim is in use and has failed over to alternate locators.

> This is about state loss, not failure detection.

Sorry, I got confused. More about this in the other thread.

   Erik

> However, if we use the "let me know if you don't see traffic from me  
> for N seconds" approach for failure detection, it could also detect  
> state loss in many cases. (I.e., when the session isn't in idle state.)