inline On Tue, Nov 2, 2010 at 8:59 PM, Michael Chen <[email protected]> wrote: > 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.
I believe in the other thread, we concluded that Section 9.4 needs to be revised to use Attach requests rather than Pings as currently written. However, the example in Section 11 currently has JP sending Attach requests to both AP and NP as well as its entire finger table before sending the Join. Section 9.4, step 3 (of the current draft) likewise has Attach requests being sent to the entire routing table before the Join is sent. I don't believe there's a problem here. Bruce > 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
