Re: failure detection

[Paul Jakma <paul@clubi.ie>]

On Thu, 18 Aug 2005, marcelo bagnulo braun wrote:

> There are two possibilities to deal with this, as explained in 
> Ilijtsch draft

Yes, ULP feedback and address-pair exploration (ie n^2 probing).

- n^2 probing, I think I've already given my opinion

- ULP feedback, gave some opinion already

I think the latter is actually promising, honest. However I don't 
think shim6 should rely on it (seems obvious). Simply because:

- Obviously, there likely are implementations without any feedback
  mechanisms and we should not preclude them from shim6, or force
  potentially significant stack reworking to accomodate shim6

- Implementations which do already provide ULP feedback mechanisms
  might /still/ not (initially or ever) be able to provide this
  feedback to shim6, as shim6 sits under IP, not (eg) TCP. Even if
  there is a way for TCP to indicate progress to IP, that information
  might not be able in shim6 (and there mightn't be a clean way to do
  it)

Given the ULP points:

- Shim6 specs *should* provide for a shim6 contained reachibility
  mechanism, to avoid raising bar for implementation

(that seems an uncontraversial point to me)

So what I think we /should/ do is:

- Design some kind of monitoring/reachability protocol inside shim6
  (as Iljitsch discusses in his draft, but dislikes because of
  potential overhead) and in its design simply keep a mind to
  possible optimisations using ULP feedback (eg as NUD does, as you
  pointed out)

Eg, it should be possible for one side to not have ULP feedback 
available and do reachability/monitoring via shim6 while the other 
side /does/ have and use ULP feedback. Seems quite possible to me.

This implies:

- ULP feedback should allow sending of probes to be optional

Hence:

- You can't mandate a shim6 implementation /must/ send probes
  regularly, to allow other side to use for reachability detection

Hence:

- reachability detection itself is unidirectional

  (iljitsch's draft mentions "unidirectional", i know, but wrt
   outside unidirectional issues. I'm proposing the reachability
   mechanism itself be unidirectional in nature. Two unidirectional
   paths == bi-directional :) )

On those principles we can design something, I think. It mightn't be 
far away from NUD either (which I hadn't considered previously, I 
admit). Iljitsch's draft reckons this is too much overhead, but I'm 
not sure why this should be so.

> not sure what you mean by this...

See above.

regards,
--
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
My doctor told me to stop having intimate dinners for four. Unless there
are three other people.