Bruce and Eric, I am submitting some proposed changes to the base-12 draft based on the Attach Race Condition discussion as follows (leading "-" is deletion, "+" is addition):
5.4.2.3. Update ... the state change. In general, peers send Update messages to all their adjacencies whenever they detect a topology shift. + + When a peer receives an Attach request with the send_update flag + set to "true" (see 5.5.1.1), it MUST send an Update message back + to the sender of the Attach request after the completion of the + corresponding ICE check and TLS connection. Note that the sender + of a such Attach request may not have joint the overlay yet. 5.5.1.2. Response Definition - - If a peer receives an Attach request, it MUST process the request and - SHOULD generate its own response with a AttachReqAns. A peer which - is overloaded or detects some other kind of error may of course - generate an error instead of an AttachReqAns. It should then begin - ICE checks. When a peer receives an Attach response, it SHOULD parse - the response and begin its own ICE checks. + + If a peer receives an Attach request, it MUST determine how to process + the request as follows: + + o If it has not initiated an Attach request to the originating peer + of this Attach request, it MUST process this request and SHOULD + generate its own response with an AttachReqAns. It should then + begin ICE check. + + o If it has already sent an Attach request to and received the + response from the originating peer of this Attach request, and + as a as a result, an ICE check and TLS connection is in progress, + then it SHOULD generate an error instead of an AttachReqAns. + [[I suggest adding a new error number for this condition.]] + + o If it has already sent an Attach request to but not yet received + the response from the originating peer of this Attach request, + it SHOULD apply the tie-breaker heuristic to determine how to + handle this Attach request and the incomplete Attach request it + has sent out. + + The tie-breaker heuristic is to compare the Node-IDs of both + peers as unsigned integers, and + + * If the peer's own Node-ID is smaller, it MUST cancel its + own incomplete Attach request. It MUST then process this + Attach request, generate an AttachReqAns response, and + proceed with the corresponding ICE check. + + * If the peer's own Node-ID is larger, it MUST generate an + error to this Attach request, then proceed to wait for + and complete the Attach and the corresponding ICE check + it has originated. + + o If the peer is overloaded or detects some other kind of error, it + may generate an error instead of an AttachReqAns. + + When a peer receives an Attach response, it SHOULD parse + the response and begin its own ICE checks. Feel free to change and discuss further. Thanks --Michael On 11/16/2010 11:53 AM, David A. Bryan wrote:
At the meeting, the following issues were presented related to the RELOAD base draft. As planned, I have cut and pasted the proposals from Ekr's slides here to take the discussion to list. Except as noted, there was no discussion on the issue in the meeting, and unless there is list discussion, the proposals mentioned for the open issues without discussion will be deemed as consensus (for the TODOs noted, we assume they will be completed). As the draft is very close to going to the editor, if you have issues, speak up quickly! David (as chair) SLIDES/ISSUES WITH DISCUSSION/OPEN ISSUES RAISED FOR MAILING LIS
...
Join race condition I (Michael Chen) • §9.4: – Step 7: routing table from AP → JP – Step 8: routing table from AP → NP • In some cases (e.g., Chord predecessors) this may cause simultaneous connects between JP and it’s new neighbors Proposed Resolution: Tiebreaker when multiple connections are established between a pair of nodes. Terminate the connection originating from the smaller Node-Id seems like a natural choice. ***NOTE: There was significant list discussion ongoing at the time this slide was presented. Need to reach consensus on list for this item.
...
______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
