RE: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt

[<john.loughney@nokia.com>]

Hi all,

> > Can you explain why the first model wouldn't be able to use negative
> > feedback for faster failure detection? It seems like it could use a
> > trigger from TCP to send a probe earlier than it would otherwise
> > do it.
> 
> I see two potential reasons for not using any negative advice in the 
> NUD-based model.
> 
> 1. If the probing by the shim (which is suppressible by positive advice) 
> have been designed so that a failure can be detected in N seconds, then 
> the shim would satisfy a requirement of detecting any failure in, at 
> worst, N seconds. Is it really useful to sometimes be better, or is 
> worst case the thing that matters? (I guess this is more a question than 
> a reason.)
> 
> 2. When you have multiple ULP "connections" using the same shim context, 
> you have some more complexity to handle when some ULP advice might be 
> negative and some positive at the same time (for the same context). If 
> you place more weight in the negative advice, then you will react more 
> strongly to random packet loss causing one connection to think there is 
> a problem, etc.
> Only using positive advice avoids this complexity, because it implicitly 
> assumes that if anybody ULP finds the locator pair working, then the 
> probes can be suppressed.

I agree with Erik on this.  I remember discussions from trigtran, about 
link-up and link-down events, that many people were worried about 
link-down events because of the reasons Erik lists above and about
fears of DoS attacks forged link-down events.  I'm not sure if this would
be applicable in the shim6 case, but there is a threat, IMO, of this.

However, I think if we wanted to consider negative feedback, we'd have
to consider the aggregate case; if there are multiple ULPs using a single
shim context and they all are reporting negative feedback, then maybe its
a safe assumption that a failure has occured. 

John