Subject: Re: wg last call results for mSLP

From: Weibin Zhao <[email-masked]>
Date: Tue, 5 Sep 2000 23:22:01 -0400 (EDT)

Erik, James,

Attached is the draft-08 of mSLP (updating draft-07). The changes are as
follows:

1. I corrected spelling and grammar errors, changed "Data_Dump_Rqst" to
   "Data_Copy_Rqst", and revised Section 9 on security.

2. Section 7.4 in draft-07 (about forwarding UA queries) was dropped.
   It is a complex issue. I plan to address it in a separate draft.

3. I prefer to use the mesh-enhancement extension other than to define a new
   SLP message type (MeshCtrl) for the following reasons.
 
   Let's say that mesh-enhanced DA1 discovers DA2 when it gets a DAAdvert
   message from DA2. DA1 initiates a peering connection to DA2.

   (1) DA1 sends a "Peer_Conn_Indication" DAAdvert to DA2. This gives
       DA2 all information about DA1 as well as indicating the peering
       connection. Using MeshCtrl message type cannot convey DA1's
       information to DA2 promptly. DA2 needs DA1's information provided
       in DA1's DAAdvert messages anyway. So for "Peer_Conn_Indication",
       the DAAdvert with the mesh-enhancement extension is preferred.

   (2) DA1 sends a "Data_Copy_Rqst" DAAdvert to DA2. DA1 specifies the
       scopes of data it wants to download from DA2 in DAAdvert. DA2
       needs this scope information that DA1 is interested to send
       data to DA1.

   (3) "Peer_DAs_Indication" and "Peer_Conn_Keepalive" do not use the 
       information in DAAdvert directly, but DA authentication is very
       important in mSLP (see Section 9 in draft-08), and DAAdvert has
       all informtion about the sending DA including the authentication 
       block, so for authentication purpose and consistency, the DAAdvert 
       with the mesh-enhancement extension is also preferred.

   (4) Each DA multicasts its DAAdvert periodically, so composing DAAdvert
       messages should not be a problem. 

   (5) DAAdvert should be small (fitting into a datagram for multicast),
       so bandwidth consumption should not be an issue.

Thanks a lot.

-Weibin

---

From: Erik Guttman <[email-masked]>
Date: Fri, 15 Sep 2000 13:55:44 +0200 (MET DST)

>    "Data_Copy_Rqst", and revised Section 9 on security.

Good.

>    It is a complex issue. I plan to address it in a separate draft.

Good choice.
 
>        the DAAdvert with the mesh-enhancement extension is preferred.

Why not send a DAAdvert as the next message after a Peer_Conn_Indication?
It is really not good to overload messages for more than one function, 
which was the point of the suggestion to create a new message type.
 
>        needs this scope information that DA1 is interested to send

DA2 already has the scope list from DA1 since they exchanged DAAdverts
when the mesh connection was established.  This would be done by exchanging
2 mesh control messages followed by soliciting of DAAdverts using unicast.
The idea being, if any DA finds out about the location of another DA through
a meshctl message, it will actively solicit the DAAdvert from it as a first
step in establishing  the mesh.

This is less efficient in the sense that two DAs would have to exchange
additional DAAdverts (as the MeshCtl messages are no longer DAAdverts).
On the other hand, it is clearer, since receiving a DAAdvert now only
means adding it to your DA table, not controlling your mesh state.

>        with the mesh-enhancement extension is also preferred.

If the MeshCtl messages are used only to *notify* DAs that they should
request DAAdverts, then DAAdvert authentication still protects mesh 
establishment.  The only operation which would not be protected would
be the Peer_Conn_Keepalive and Data_Copy_Request.  These would waste
resources if sent by DAs which are not 'legitimately' deployed, but not 
cause any errors in operation.

>        messages should not be a problem. 

True.
 
>        so bandwidth consumption should not be an issue.

This isn't really the concern.

-----

The most important thing is whether the MeshCtl message would make the
protocol simpler or more complex.  Weibin - you have implemented the protocol
in various versions.  Would MeshCtl make mesh enhancements more or less
easy to implement, more or less clear in the spec?  I'm sure in your own
implementation it would be easier :-)  The question is, for others, what
is your feeling?

Erik

---

From: Weibin Zhao <[email-masked]>
Date: Tue, 19 Sep 2000 22:48:07 -0400 (EDT)

Hi Erik, James, Mike, Ira,

Thanks for your comments on mSLP. I totally agree to split the 
functions provided by the mesh-enhancement extension (mSLP draft-07)
into that provided by the mesh control (MeshCtrl) message type and 
the mesh-forwarding extension (mSLP draft-08). This partition
makes mSLP protocol more clear. I attached the new version of mSLP 
draft-08. The changes are summarized as follows.

1. Naming

   (1) mesh control message type: Function-ID = 12
  			          Abbreviation: MeshCtrl
   (2) the original "mesh-enhancement" extension is renamed as
       the "mesh-forwarding" extension

2. MeshCtrl message format

   Its format is determined by its Action-ID.
   (1) Peer_Conn_Indication and Peer_Conn_Keepalive: no Action-Data.
   (2) Peer_DA_Indication: has a DA list.
   (3) Data_Copy_Rqst: has "requested scopes" (length + string)
       (the reason and example for this are given in draft-08)

3. Protocol sequence

   An unsolicted DAAdvert is sent right after the "Peer_Conn_Indication"
   MeshCtrl message.

4. An algorithm is given for constructing the "requested scopes"
   in Data_Copy_Rqst MeshCtrl. This algorithm utilizes the
   DA list in the Peer_DA_Indication MeshCtrl message.

5. The DA list in the Peer_DA_Indication MeshCtrl can have zero URL.
   The URL of the sending DA SHOULD not be included.
   This list is actually the common peer list of the sending DA
   and the receiving DA. A pair of mesh-enhanced peer DAs 
   SHOULD exchange their Peer_DA_Indication MeshCtrl messages 
   no matter the DA list has zero URL or not.

I have made the above changes to my mSLP implementation, which can 
be found at http://www.cs.columbia.edu/~zwb/project/slp/.

-Weibin

---

From: Erik Guttman <[email-masked]>
Date: Wed, 20 Sep 2000 09:07:59 +0200 (MET DST)

You wrote:
> the mesh-forwarding extension (mSLP draft-08). 

The draft looks great to me.  Your integration of the MeshCtrl message
works great.  The new figures are simpler than in the preceding drafts
which is a very positive thing, too.

> This partition makes mSLP protocol more clear.

That's great!

I like the description of the algorithm on page 11.  It needs to be 
reformatted so it doesn't go over column 72.  

One additional thought.  Since the Peer_Conn_Keepalive MeshCtrl 
message is not sent as a DAAdvert extension, the peers may not be
kept up to date about the peer DA state over time.  Consider what
would happen if one DA were to go through a stateless reboot.  I
guess the TCP connection would fail in that case.  But in some
architectures an implementor might separate out the TCP message
handling code from the DA logic:

   +-----+                                             +-----+
   |     |                                   +---+     |     |
   | DA1 | ------------ (TCP) -------------->|TCP|<--->| DA2 |
   |     |   "Peer_Conn_Keepalive" MeshCtrl  +---+ ipc |     |
   +-----+                                             +-----+
   =======                                   =================
   host #1                                        host #2

In this case, host #2's DA2 process may go down and come back up
while the TCP connection remains up between DA1 and (what it thinks
to be) DA2.  Actually, the interprocess communication gets restarted
when DA2 comes back up.

I bring this up because it is possible (I know of at least one SLPv1
implementation which worked this way).

For this reason, shouldn't DA2 send an unsolicited DAAdvert to
DA1 every time it receives a Peer_Conn_Keepalive message - so 
that the DAs retain up-to-date state about each other?

I don't think this is a very big issue - we could leave it out of
the spec at this time and see whether it becomes an issue in reality.
But it would be easy to add, and having a mechanism by which DAs can 
keep state sync'ed seems like a good thing to me.

> be found at http://www.cs.columbia.edu/~zwb/project/slp/.

Wow!  

Erik