I think heuristic 2 could work, though we should add something about a node not initiating a new Attach request if one is in progress. I'm sort of neutral on whether it's worth the effort here, but I think it's fairly minimal and won't break anything.
Bruce On Mon, Nov 8, 2010 at 8:53 PM, Michael Chen <[email protected]> wrote: > On 11/7/2010 2:21 PM, Bruce Lowekamp wrote: >> >> On Fri, Nov 5, 2010 at 4:14 PM, Michael Chen<[email protected]> >> wrote: >>> >>> Eric, >>> >>> Using AttachReqAns.send_update is a fantastic idea. Brilliant! >>> >>> Having AP send an UPDATE before JP send JOIN provides JP a precise set of >>> Node-IDs (S1,S2,S3,P1,P2,P3) to ATTACH. The cost is an extra UPDATE >>> message, but it preempted the race condition (AP's predecessors >>> included), >>> and JP can also do simultaneous attach to S1,S2,S3,P1,P2,P3. It's so >>> worth >>> it! >>> >>> The AttachReqAns.send_update flag was added in base-10 back in August >>> of this year. Our code is quite old. Thanks for the pointer. >>> >> We should probably update the description of how Update is used, since >> JP isn't technically a peer at this point, but I think this is the >> best solution here, given the current protocol. >> >>> I am also glad that we are in agreement on defining a tie-breaker >>> heuristic >>> based on Node-ID comparison to address the race condition. We should >>> move ahead to add it into the next draft. >>> >> Node-ID makes a good comparison, but I think the issue of when to >> apply it to terminate one of two duplicate connections is much more >> complicated. Would need to make sure that both sides perceive they >> have duplicate active connections. For example, if A and B are >> connected and A believes the connection to B is dead, but B hasn't >> detected it yet, it would be bad if B drops A's attempt to >> re-establish the connection because it disagrees about the connection >> state. >> >> I still believe the protocol complexity to handle these situations >> properly is not worth the benefit. >> >> Bruce > > This tie-breaker heuristic will only be use to eliminate concurrent ATTACH > and prevent the ensuing ICE check and TLS session. Here are the details: > > Scenario-1 (Unconditional Rejection) > ========== > Peer-A sends ATTACH to Peer-B and receives its reply. Then Peer-A receives > an ATTACH sent by Peer-B. Peer-A unconditionally rejects this ATTACH from > Peer-B and continue with the ICE check and TLS session derived from the > ATTACH initiated by Peer-A itself. No tie-breaker heuristic is applied. > > Scenario-2 (Heuristic-based Rejection) > ========== > Peer-A and Peer-B sends ATTACH to each other and simultaneously receive > the ATTACH request from the other before receiving the reply to its own > request. Both Peer-A and Peer-B apply the tie-breaker heuristic using > their Node-IDs as unsigned integers. Both Peer-A and Peer-B MUST reject > the ATTACH request sent by the peer with the smaller Node-ID and allow > the other ATTACH and its ensuing ICE check and TLS session to complete. > > Using these two rejection rules, there will never be duplicate ICE check > and TLS links between any two peers. What do you think? > > Thanks > > --Michael > > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
