[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address pair exploration, flooding and state loss



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