[SWMP] My understanding so far

john_patterson@us.ibm.com Fri, 10 August 2007 06:43 UTC

Return-path: <swmp-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJODm-0004eP-Q5; Fri, 10 Aug 2007 02:43:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJODl-0004eJ-8H for swmp@ietf.org; Fri, 10 Aug 2007 02:43:41 -0400
Received: from e1.ny.us.ibm.com ([32.97.182.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJODj-0002Qu-Lc for swmp@ietf.org; Fri, 10 Aug 2007 02:43:41 -0400
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7A6hdsK024061 for <swmp@ietf.org>; Fri, 10 Aug 2007 02:43:39 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l7A6hdtl484468 for <swmp@ietf.org>; Fri, 10 Aug 2007 02:43:39 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7A6hd8T029035 for <swmp@ietf.org>; Fri, 10 Aug 2007 02:43:39 -0400
Received: from internet1.lotus.com (internet1.lotus.com [9.33.9.11]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7A6hcO6029019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <swmp@ietf.org>; Fri, 10 Aug 2007 02:43:39 -0400
Received: from wtfmail02.edc.lotus.com (wtfmail02.lotus.com [9.33.9.69]) by internet1.lotus.com (8.14.1/8.14.1) with ESMTP id l7A6hcFR021570 for <swmp@ietf.org>; Fri, 10 Aug 2007 02:43:38 -0400 (EDT)
To: swmp@ietf.org
Subject: [SWMP] My understanding so far
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 August 18, 2005
Message-ID: <OFE08B3427.B3EA5603-ON8525732C.0077710F-85257333.0024F03B@lotus.com>
From: john_patterson@us.ibm.com
Date: Fri, 10 Aug 2007 02:44:15 -0400
X-MIMETrack: Serialize by Router on WTFMAIL02/WTF/M/Lotus(Build V703_07292007|July 29, 2007) at 08/10/2007 02:44:18 AM, Serialize complete at 08/10/2007 02:44:18 AM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff
X-BeenThere: swmp@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of a Simple Wide-area Multiuser-3D Protocol <swmp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/swmp>, <mailto:swmp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/swmp>
List-Post: <mailto:swmp@ietf.org>
List-Help: <mailto:swmp-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/swmp>, <mailto:swmp-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1465320130=="
Errors-To: swmp-bounces@ietf.org

I have proposed some changes to the swmp specification and there has not 
been much resistance.  I thought it might help to rearticulate the swmp 
message set with my changes.  There were two main issues that I discussed 
earlier:

A)  As originally specified, swmp does not distinguish between requesting 
a state change and being notified of a state change.  It tends to treat 
the state sharing as largely a replication task with neither network 
element having a controlling role over the state.  I think it is more 
realistic and practical to assume that each network element has control 
over its state and the other network element may request changes and be 
notified when changes happen.  This leads to distinguishing requests from 
notifications.

B)  As originally specified, swmp does an implicit subscription to all 
state once the intitial message is sent.  I believe it makes more sense to 
have explicit subscriptions to some, but not necessarily all of the state.


In addition, I have found that four new issues (not previously identified) 
have prompted me to make some additional changes.

C)  SET is overloaded as both a way to change and create (and probably 
remove) a Field.  I think it is clearer to separate these operations. This 
leads to an ADDFIELD, REMOVEFIELD, and a SETFIELD.  Then for clarity ADD 
and REMOVE need to become ADDNODE and REMOVENODE.

D)  I believe that swmp will need the full complement of CRUD (create, 
read, update, delete) operations.  I think the absence of read methods 
derived from the implicit subscription to all state.  Now, that one can 
subscribe to some, but not all of the state, I believe it will become 
desirable to request the values of unsubscribed state.  This prompted me 
to add a GETNODE and a GETFIELD request, which required GETNODEREPLY and 
GETFIELDREPLY messages to return the response.

E)  The ADD message (now ADDNODE) provided the new value of the node in a 
parsable string.  This seemed both ill-specified (Does it only contain 
fields or can it contain children as well?) and X3D-specific.  While there 
is some appeal to setting all the information in one message, I decided to 
simplify matters by assuming that the node must be built through a series 
of ADDNODE and ADDFIELD messages.  Thus, the parsable nodestr disappeared.

F)  The use of the fieldId on the SET message as a way to allow faster 
field references seemed to require modification.  For one thing, it did 
not seem right that the name/id association was being defined by the 
requesting network element rather than the network element controlling the 
state.  Also, the first opportunity to associate a fieldName with an id 
occurs on the GETFIELDREPLY or ADDFIELDNOTIFY messages.  After moving 
those parameters, the new SETFIELD message reduces to the old SETF 
message.


Most of this comes from the paper found at 
http://www.mediamachines.com/hydra/swampweb3d2007.pdf identified in an 
earlier message. 
(http://www1.ietf.org/mail-archive/web/swmp/current/msg00010.html)  I have 
identified the aspects that are changes introduced by me using square 
brackets.  Issues/questions/comments are in squiggly braces.

ASSUMPTIONS

1)  swmp is designed to provide a simple means for propagating low latency 
state changes between network elements.
2)  swmp is peer-to-peer in the sense that neither of the two network 
elements using swmp takes on a distinguished role.  In other words, all 
messages are available for either network element to send to the other. 
(This does not preclude using swmp in a client-server fashion, but this is 
not "built-in" to the protocol.)
3)  swmp is designed for transport by either TCP or UDP.  It is expected 
that applications will begin with a TCP connection and add on UDP 
connections, if needed.
4)  swmp messages are defined as byte-encoded rather than "human readable" 
in an effort to decrease the message latency.  {I am not addressing the 
actual encoding here.}
5)  swmp messages communicate about state [that is managed by one or 
another of the communicating network elements].  This state is organized 
as a hierarchy of Nodes.
6)  swmp Nodes have a name, a type, any number of child Nodes, and any 
number of Fields.  {The paper indicates that the child Nodes form an 
ordered set, but does not provide adequate capability for managing the 
order.  I have not fixed this problem.}
7)  The name of a node must be unique across the entire hierarchy 
maintained by the network element.
8)  Although Nodes may be of many types, the Node types of  X3D scene 
graphs are expected to be basic types.  [Another basic Node type is likely 
to be a shard, meaning a section of virtual real estate.  In all 
likelihood, Node types will be of three varieties: basic (dictatied by the 
standard), conventional (generally agreed upon after the standard's 
specification), and ad hoc (used idiosyncratically by some non-standard 
application.)]
9)  swmp Fields have a name, a type, an identifier, and a value.
10)  The name of a Field must be unique among its Node's Fields, but it 
may be reused for different Nodes.
11)  The identifier of a field must be unique across the entire hierarchy 
maintained by the network element.
12)  Although Fields may be of many types, the Field types of X3D scene 
graphs are expected to be basic types.  Another basic Field type is likely 
to be velocity as identified in the paper.  [In all likelihood, Field 
types will be of three varieties: basic (dictated by the standard), 
conventional (generally agreed upon after the standard's specification), 
and ad hoc (used idiosyncratically by some non-standard application.)]

MESSAGES

Control Messages  (These are for establishing that a connection exists and 
that communication may occur.)

HELLO id ticket -- Both network elements must send a HELLO message as the 
first message on a swmp channel.  They send an id by which they identify 
themselves and a ticket for the other network element to use.  [Although 
the original protocol uses the HELLO message as an implicit subscription 
to all the state of the receiving network element, this implicit 
functionality has been removed here and is subsumed under the SUBSCRIBE 
message below.]  {The id and ticket seem to be needed for UDP messaging. 
Although it is clear that the ticket is used in all future messages, it is 
not clear how the id is used again.}

{BYE -- If we need HELLO to indicate the start of traffic, don't we want 
something to indicate that the traffic has ended.}

COMM protocol host port -- The COMM message is used to indicate a desire 
to initiate another swmp channel over the indicated transport protocol 
using the host and port.

ACK protocol host port -- Following the establishment of a secondary swmp 
channel using the COMM request.  The recipient of a HELLO message on the 
secondary channel {which should be both network elements eventually} must 
send an ACK message over the primary channel.



Content Messages (These are for communicating about the state being 
managed by the network elements.)

[ADDNODE parentName childName] -- This is a request to create a new child 
node for the specified parent.  {This corresponds directly to the ADD 
message in the paper with the nodestr parameter eliminated.  The paper 
indicates that ADD places the new child last in the ordered list of 
children.  If order is important, then this seems like inadequate 
control.}

[REMOVENODE nodeName] -- This is a request to delete a node. {This 
corresponds directly to the REMOVE message in the paper with the 
parentNode parameter removed.  Since nodeNames must be unique over the 
entire Node hierarchy, it is unclear why the parentName was required, so I 
eliminated it.  Although the paper does not say so, presumably a 
REMOVENODE request deletes all the children of the node as well.}

[GETNODE nodeName -- This is a request to retrieve the information about a 
node.  I added this to round out the CRUD capabilities for Node.]

[GETNODEREPLY nodeName listOfChildNodeNames listOfFieldNames -- There are 
several ways to go with a reply like this.  I am assuming I will give you 
enough information to figure out the structure of a node, ie, the names, 
but not the actual values.]

[ADDFIELD nodeName fieldName type value -- This is a request to add a new 
field to an existing node.  The type and value may be specified by the 
requestor.  The fieldId is assigned by the controlling network element and 
is obtained in the ADDFIELDNOTIFY message, if a subscription is in place. 
In the absence of a subscription, a GETFIELD request would be needed to 
obtain the id.  {In the paper, I believe this capability was provided via 
the SET message.}]

[REMOVEFIELD fieldId -- This is a request to remove the specified field. 
The fieldId would have been provided by a prior GETFIELDREPLY or 
ADDFIELDNOTIFY message.  {I'm not sure how this was accomplished in the 
paper.}]

[SETFIELD fieldId value] -- This is a request to update the value of a 
Field. The fieldId would have been provided by a prior GETFIELDREPLY or 
ADDFIELDNOTIFY message.  {This corresponds directly to the SETF message in 
the paper.}

[GETFIELD nodeName fieldName -- This is a request to retrieve the value of 
a field.]

[GETFIELDREPLY nodeName fieldName type fieldID value -- This message sends 
back the information from a GETFIELD request.  This is one way to discover 
the name/id equivalence for a field.]

[SUBSCRIBE nodeName lastId -- This is a request to subscribe to all 
changes associated with this Node and any of its descendants.  If the Node 
is removed, there will be a final REMOVENOTIFY for the Node after which 
the subscription is canceled.  It is permissable for a network element to 
have more than one subscription request active at the same time.  In the 
event that a subscription is added for a descendant of another subscribed 
Node, both subscriptions are active, but only one notification is sent for 
any change that occurs.  A secondary purpose of the SUBSCRIBE request is 
to cause the controlling network element to "dump" the state of the 
subscribed node and its descendants.  This is done as a sequence of 
notifications.  The lastId parameter identifies the last notification from 
the subscribed network element for which an accurate record of the state 
is available. {The paper calls for all messages to contain a sequence 
number.  This seems a sensible candidate for identifying the last 
notification message.}  If the lastId is zero, then the subscribed network 
element should assume that the subscribing network element has no record 
of the subscribed nodes and will intitiate a series of ADDNODENOTIFY 
messages in breadth first order.  Following each ADDNODENOTIFY message 
will be the set of ADDFIELDNOTIFY messages needed to identify all the 
fields of the node.  If the last ID is non-zero, then the subscribed 
network element should assume tat the subscribing network element has an 
accurate record of the state as of the identified notification message. It 
should issue a series of REMOVENODENOTIFY messages, followed by a set of 
ADDNODENOTIFY messages in breadth first order.  Following each 
ADDNODENOTIFY message will be a set of REMOVEFIELDNOTIFY, ADDFIELDNOTIFY, 
and SETFIELDNOTIFY messages for establishing the state of the fields. 
{Note:  The collection of notifications should be efficient and not simply 
a log of all that happened since the prior subscription.}  All such 
notifications received in response to the SUBSCRIBE request should be sent 
prior to sending any notifcations caused by additional changes to the 
state.]

[UNSUBSCRIBE nodeName -- This is a request to cancel an existing 
subscription.  If the corresponding SUBSCRIBE request was never made or 
the subscription was canceled because the Node was removed, the 
UNSUBSCRIBE request is a no-op.  When subscriptions exist for a Node and 
one of its descendants, cancelation of the descendant's subscription will 
not affect the notifications received.  Cancelation of the ancestor's 
subscription reduces the set of subscribed nodes down to the subscribed 
descendant and its descendants.]

[FAILNOTIFY requestId reason -- Since all of the previous methods are 
requests of the network element controlling the state, it is possible that 
the controlling network element will reject the request.  There will need 
to be a way to communicate the failure and bind it to the rejected 
message. {The paper calls for all messages to contain a sequence number. 
This seems a sensible candidate for identifying the rejected message.}]

[ADDNODENOTIFY parentName childName originatorFlag -- This message 
notifies one network element of changes to any subscribed state due to an 
ADDNODE request.  This message is sent to the requesting node as well, if 
a subscription is in place. The originatorFlag is used to signal how the 
originating request was handled.  The flag has three values: 
not-requestor, asis, modified.  The not-requestor value is used when the 
recipient was not the requestor of the change.  The asis value indicates 
that the recipient originated the request and the request was honored 
without modification.  The modified value indicates that the recipient 
originated the request, but the actual value used is not the same as the 
requested value.]

[REMOVENODENOTIFY nodeName originatorFlag -- This message notifies one 
network element of changes to any subscribed state due to a REMOVENODE 
request.  The message is sent to the requesting node as well and the 
originatorFlag has the same meaning as in ADDNODENOTIFY, though it is 
difficult to imagine how the modified value might be used.]

[ADDFIELDNOTIFY nodeName fieldName type fieldId value originatorFlag -- 
This message notifies one network element of changes to any subscribed 
state due to an ADDFIELD request.  The message is sent to the requesting 
node as well and the originatorFlag has the same meaning as in 
ADDNODENOTIFY.  This message communicates the name/id equivalence for the 
field.]

[REMOVEFIELDNOTIFY fieldId originatorFlag -- This message notifies one 
network element of changes to any subscribed state due to a REMOVEFIELD 
request.  The message is sent to the requesting node as well and the 
originatorFlag has the same meaning as in ADDNODENOTIFY, though it is 
difficult to imagine how the modified value might be used.]

[SETFIELDNOTIFY fieldId value originatorFlag -- This message notifies one 
network element of changes to any subscribed state due to a SETFIELD 
request.  The message is sent to the requesting node as well and the 
originatorFlag has the same meaning as in ADDNODENOTIFY.  {Note: Signaling 
the SETFIELD originator is needed for situations like collision detection 
where the actual position of an object ends up being something different 
from the request.}]
_______________________________________________
SWMP mailing list
SWMP@ietf.org
https://www1.ietf.org/mailman/listinfo/swmp