[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Design decisions made at the interim SHIM6 WG meeting
Jari Arkko wrote:
The latter case is indeed not simple! The 2nd para was
saying that IF someone wants to take on such an ambitious
task, then that dictates the solution.
I don't think it does.
If somebody wants to add that down the road, they can explicitly add the
fact that the protocol needs to exchange the views of the addresses from
the two ends (since they can be different due to NATs).
So I don't see why this consideration should be a constraint on the case
protocol.
If the ambition level is lower, then there are two truly
alternative solutions, as noted in 1st para. Here the
solution overall is simpler in any case. But there's still
a difference, I think, compared between a solution
that needs to be in sync vs. one that doesn't. Particularly
if your set of addresses isn't fixed.
I don't think the complexity is very high to manage the generation number.
If the receiver gets an update message with a preference option where
the generation number doesn't match the last one it received in a
locator list option, then it knows that the sender hasn't received an
ack for that new locator list. So it can just ignore the preference option.
The sender of the update retransmits each update (whether it contains a
locator list, locator preferences, or both) until acknowledged.
The sender of the updates can benefit from some "collapsing" of the
retransmissions but that is an optimization. By "collapsing" I mean that
if the sender has an unacknowledged update (e.g., containing a locator
list) and needs to send some other update (e.g., containing a preference
option), then it can (re)transmit an update which contains both. This
increases the probability that the peer will receive both at the same
time, i.e. that the preferences will refer to the current locator list.
Anyway, perhaps we should stop this philosophical debate
and start talking about the specifics. Since we appear to
agree that exploration doesn't use indexes, what does?
I haven't actually read your and Iljitsch' draft update to see how it
handles different cases. I take it just uses the sequence numbers on the
explore messages as the indication of what locator pairs was used (as
you sketched in Amsterdam).
LLU appears to not be able to use indexes, so is the
question only about the update of preferences?
Yep.
And somewhere along the line I think we decided to do full updates and
not add/delete/change type updates.
Thus a preference update would need to include all the locators (and
there preferences).
I think this raises a synchronization issue even if we don't use
indicies. If A has sent {A1, A2} to B as a locator list option in the
past, and then sent {A1, A2, A3} as an update which hasn't been
acknowledged yet.
When A then goes and want to update the preferences and sends {A1, A2,
A3} and their respective preferences, then what would happen if B hasn't
seen the LLU? Would it reject/ignore the preference update?
It is exactly the same issue as when using indices I think.
In the indicies case we represent the locator list using a small
generation number, and here we are sending the complete list of
locators, but the logic to resolve being out of synch still applies.
Erik