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

Reply via email to