Done. -Ekr
On Nov 18, 2010, at 3:21 PM, Michael Chen wrote: > 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 _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
