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