[SWMP] TCP, UDP, and multicast: are they really equivalent?

john_patterson@us.ibm.com Fri, 07 September 2007 00:50 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 1ITS3K-000864-Sc; Thu, 06 Sep 2007 20:50:30 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITS3J-00085y-G4 for swmp@ietf.org; Thu, 06 Sep 2007 20:50:29 -0400
Received: from e35.co.us.ibm.com ([32.97.110.153]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITS3I-0005PK-D6 for swmp@ietf.org; Thu, 06 Sep 2007 20:50:29 -0400
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l870oHPl006785 for <swmp@ietf.org>; Thu, 6 Sep 2007 20:50:17 -0400
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l870oHso399506 for <swmp@ietf.org>; Thu, 6 Sep 2007 18:50:17 -0600
Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l870oHqW023701 for <swmp@ietf.org>; Thu, 6 Sep 2007 18:50:17 -0600
Received: from internet1.lotus.com (internet1.lotus.com [9.33.9.11]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l870oGRY023662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <swmp@ietf.org>; Thu, 6 Sep 2007 18:50:17 -0600
Received: from wtfmail02a.edc.lotus.com (wtfmail02a.lotus.com [9.33.9.70]) by internet1.lotus.com (8.14.1/8.14.1) with ESMTP id l870oFP4022636 for <swmp@ietf.org>; Thu, 6 Sep 2007 20:50:16 -0400 (EDT)
To: swmp@ietf.org
Subject: [SWMP] TCP, UDP, and multicast: are they really equivalent?
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 August 18, 2005
Message-ID: <OF00B259A5.9B278BBB-ON8525734E.0082106F-8525734F.000491EF@lotus.com>
From: john_patterson@us.ibm.com
Date: Thu, 06 Sep 2007 20:50:58 -0400
X-MIMETrack: Serialize by Router on WTFMAIL02a/WTF/M/Lotus(Release 7.0.2FP1|January 10, 2007) at 09/06/2007 08:51:00 PM, Serialize complete at 09/06/2007 08:51:00 PM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
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="===============0160580493=="
Errors-To: swmp-bounces@ietf.org

The original swmp paper lends the impression that the protocol is more or 
less indifferent to its transport.  It is conceded that one should start 
with a TCP connection and that datagrams require a wrapper that is not 
needed for TCP, but otherwise it appears that all messages are equally 
valid for all transports.  In fact, my first impression about the protocol 
was that except for the COMM and ACK messages (which are used to establish 
a secondary transport), the multiple channels were essentially 
independent.  I am now wondering whether all messages will be valid for 
all transports and whether it is even desirable to think of transports as 
independent.

Much of my concern has grown out of our conversation here.

1)  Jay has pointed out 
(http://www1.ietf.org/mail-archive/web/swmp/current/msg00053.html) that a 
desirable pattern is to use SET on a reliable channel to establish a 
mapping from an ID to a <node, field> pair and then use SETF messages via 
UDP in the future.
2)  I have asked 
(http://www1.ietf.org/mail-archive/web/swmp/current/msg00045.html) whether 
we might want to subscribe on a reliable channel for notifications that 
will be delivered on an unreliable channel.
3)  Roland points out 
(http://www1.ietf.org/mail-archive/web/swmp/current/msg00058.html) that 
the HELLO message exchange is problematic for multicast channels.
4)  I have advocated messages 
(http://www1.ietf.org/mail-archive/web/swmp/current/msg00032.html) such as 
GETNODE or GETFIELD that lead to responses and might not be altogether 
suitable for UDP.

Although the protocol specified in the paper provides a sequence number on 
datagram messages, it does not provide a way to request a resend.  This 
leads me to wonder how advisable it would be to send an ADD (add node) or 
REMOVE (remove a node) message via UDP.  Or, for that matter, would I ever 
send COMM or ACK via UDP.

It is hard for me to believe that the correct way to deal with this is to 
add repair mechanisms to swmp.  (Although I think I have seen something 
like that in SIP.)  Presumably, TCP provides these techniques and we do 
not want to reinvent it within swmp.  I'm wondering whether it would be 
better to be clear about the kinds of messages that will actually be used 
via a UDP or multicast channel and structure the protocol accordingly.

When I think about using swmp (or the enlarged version I proposed in 
http://www1.ietf.org/mail-archive/web/swmp/current/msg00032.html), I 
wonder whether I would ever use UDP or multicast for anything other than a 
way to receive notifications as a result of a subscription.  Indeed, I 
doubt I would want to receive all notifications via UDP.  Structural 
changes, such as adding/dropping a node or adding/dropping a field are 
probably sufficiently important that I would want to ensure reliable 
delivery.  Indeed, some update notifications might occur infrequently or 
be critical triggers and I would probably prefer to use TCP for them.

The canonical example of where I really want UDP is updates about the 
position of a moving object.  If I miss one update, I'll just wait for the 
next one.  So long as the coding of the update is to declare the new 
position rather than give me the delta, the improved speed is worth the 
occasional loss.

Given that we are assuming a TCP connection to start with, I wonder 
whether a secondary UDP connection will carry anything other than updates 
to field values (SETFIELDNOTIFY in my formulation.)  Suppose, for example, 
that we provide a way to use COMM and ACK to establish a secondary UDP 
connection and then say that the only message it will ever send is 
SETFIELDNOTIFY.  The subscription would be set up via the TCP connection 
and then redirected for some fields (it might not make sense for all) to 
the secondary UDP channel.  In this scheme, the UDP connection might only 
carry SETFIELDNOTIFY messages.  Or, perhaps, HELLO and BYE as well.

Please help me understand if I am missing something critical here.  I 
assume that there are other aspirations for UDP traffic that I am missing. 
 To me, however, UDP still means unreliable, and it is useful for some, 
but not all situations. 
_______________________________________________
SWMP mailing list
SWMP@ietf.org
https://www1.ietf.org/mailman/listinfo/swmp