Subject: RE: Updating of mSLP draft-08

From: Erik Guttman Sun Frankfurt Staff Engineer <[email-masked]>
Date: Mon, 25 Sep 2000 18:21:01 +0-200

Weibin Zhao wrote:
>The idea is that when a mesh-enhanced DA handles the peer relationship 
>setup procedure with peer DAs, it synchronizes data with one peer
>at each time. This can avoid race conditions in data synchronization
>among peer DAs.

I don't believe there is any language in the draft which establishes
a strict ordering between operations.  

Let me know if I understand the problem correctly, please.  

 1   DA1 <------DAAdvert-------- DA2     DA1 discovers DA2
 2   DA1 <=====================> DA2     DA1 and DA2 establish a mesh
                                         connection and begin transfer
                                         of registration state in both
                                         directions.
 3   DA3 <------DAAdvert-------- DA1     DA3 discovers DA1
 4   DA3 <-Peer_DA_Indication{DA2}- DA1  DA3 learns of DA2
 5   DA3 <=====================> DA1     DA3 and DA1 establish a mesh
                                         connection & transfer reg state.
 6   DA3 <=====================> DA1     DA3 and DA1 complete mesh init.
 7   DA1 <=====================> DA2     DA1 and DA2 complete mesh init.
 8   DA3 <=====================> DA2     DA3 establishes a mesh connection
                                         with DA2 and *mistakenly* assumes 
                                         that it has already gotten all the 
                                         registration state from DA2.  It
                                         does not send a Data_Copy_Rqst!

Since the updates between DA3 and DA1 complete (6) before DA1 and DA2 (7), 
DA3 does not get all of DA2's registrations.  DA3 assumes that it has all
of DA2's state, however, since it got a Peer_DA_Indication from DA1 listing
DA2.

If the above is correct, we should at least warn implementors that if they 
ignore the following rule they are open to this race condition:

   "Only send DA URLs in Peer_DA_Indications for which registration 
    forwarding has already completed.  Otherwise, other DAs may 
    mistakenly infer they have consistent state with a particular DA
    when in fact they do not."

Erik

---

From: Weibin Zhao <[email-masked]>
Date: Mon, 25 Sep 2000 16:10:44 -0400 (EDT)

Hi Erik,

The above rule you mentioned is absolutely correct. I enforce this
in my mSLP implementation. Actually, there are two rules for specifying 
the order of the message sequence. I summarize them as follows:

(1) A mesh-enhanced DA sends Peer_DA_Indication to a new peer ONLY when 
    it is not in data synchronization with another DA. It SHOULD synchronize
    data with new peers once at a time.

    A data synchronization with a peer begins with sending 
    "Peer_DA_Indication" to the peer (since "Data_Copy_Rqst" depens on
    "Peer_DA_Indication"), and ends with receiving 
    "Data_Send_Done" from the peer, or ends with receiving
    "Peer_DA_Indication" from the peer and deciding no data
    are needed to get from the peer.

    In other words, a mesh-enhanced DA SHOULD not send "Peer_DA_Indication"
    to a peer if it is still in data synchronization with another peer.

(2) If "Data_Copy_Rqst" is needed to sent to a peer, it MUST be sent 
    *AFTER* "Peer_DA_Indication" has been sent to the peer.

Come back to the example you provided:

*** DA1 SHOULD not send "Peer_DA_Indication" to DA3 since DA1 is still
    in data synchronization with DA2. DA1 SHOULD do this *AFTER* it 
    have got synchronizaed with DA2.

I will add some comments about there message ordering to the draft.

Thanks.

-Weibin