Bruce,
As I said in the original post, the premise is JP uses the technique stated in
Section 11 of the draft (and discussed in the thread titled "Clarification of
initial attach procedure"), where JP did not PING and ATTACH to AP or NP before
sending JOIN to AP. Therefore, the race condition is highly likely when both
receive UPDATE from AP and discover that they are not connected, unless:
1) A duplicate ATTACH elimination heuristic is defined by the draft, which can
stop one ATTACH from progressing to an ICE check and TLS overlay link; or
2) NP ignores the new predecessor (JP) in AP's UPDATE in anticipation of
the UPDATE sent by JP if not already arrived.
Thanks
--Michael
On 11/2/2010 6:01 PM, Bruce Lowekamp wrote:
So I think we still ought to have some text somewhere about the
general case of simultaneous Attach.
However, in the case of the join process in 9.4, JP already sent
Attach requests to all of the peers in its neighbor table quite early
in the process (step 3 of the current draft). I think there's the
possibility these may fail (or not complete quickly) and the
implementation moves on with the rest of the process, but I don't
think there's really a significant race condition in this case.
Bruce
On Mon, Nov 1, 2010 at 4:15 PM, Michael Chen<[email protected]> wrote:
What is the purpose of Section 9.4 step 8, where AP sends an UPDATE to NP.
Isn't that redundant since NP will receive the UPDATE sent from JP soon?
If step 8 is eliminated, the race condition is avoided.
--Michael
On 11/1/2010 6:57 AM, Bruce Lowekamp wrote:
I'm tempted to say it may be best to ignore this race condition---how
much harm does it really cause to have two connections?
To fix it, there's not only a race condition with simultaneous Attach,
but also a possible case where one peer has detected a failure of the
connection and tries to re-establish before the other realizes the
connection has failed.
Simply retaining the most recent connection to complete should work
fine in all situations---there shouldn't be a circumstance where both
peers do an immediate re-Attach, so if one accidentally drops the
connection, it should reconnect on a timer.
Another possibility would be implementing the connection table as a
multi-map and limiting the number of entries per peer to two. That
seems like a pretty effective way to deal with this without
introducing too much additional complexity.
Otherwise, I think the heuristic you propose is probably fine.
Requires a bit more complexity in the implementation b/c you need to
remember the transaction ID for each connection in the connection
table, though I don't know if that's harder than other approaches. I
think there would still be problems with one side noticing the failure
before the other, but that's no worse (and rarer) than restricting to
one connection.
I'd prefer to leave this as an implementation detail, maybe with some
text calling out the issue.
Bruce
On Mon, Nov 1, 2010 at 7:23 AM, Michael Chen<[email protected]>
wrote:
Hi,
The scenario is a peer (JP) joins a ring of two peers: AP and NP, where
AP is the admitting peer of JP. Referring to Section 9.4 of the base-11
draft, step 7, AP sends an UPDATE to JP, immediately followed by step 8,
AP sends another UPDATE to NP.
If JP uses the technique discussed in thread "Clarification of initial
attach procedure" in which JP did not (or failed to) PING and ATTACH to
NP before JOIN, then after step 8, both JP and NP could simultaneously
send ATTACH to each other (via AP).
It's possible that both JP and NP receive the ATTACH request from the
other before receiving the reply to its own ATTACH request. The result
is two ICE checks may commence independently and lead to in two TLS
overlay links between JP and NP.
JP NP
--------- ---------
ATTACH_r1 ---->
<---- ATTACH_r2
ATTACH_a2 ---->
<---- ATTACH_a1
ICE-1<--->
<---> ICE-2
TLS-1<--->
<---> TLS-2
Here is the problem. The draft does not define a heuristic to choose
one ATTACH/ICE/TLS among the two and drop the other. For example, a
simple one could be comparing the transaction ID of both ATTACH as an
unsigned 64bit integer and drop the lesser one.
Any opinions on this?
Thanks
--Michael
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
