[SWMP] TCP, UDP, and multicast: are they really equivalent?
firstname.lastname@example.org Fri, 07 September 2007 00:50 UTC
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 email@example.com; Thu, 06 Sep 2007 20:50:29 -0400
Received: from e35.co.us.ibm.com ([126.96.36.199]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ITS3I-0005PK-D6 for firstname.lastname@example.org; Thu, 06 Sep 2007 20:50:29 -0400
Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [188.8.131.52]) by e35.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l870oHPl006785 for <email@example.com>; Thu, 6 Sep 2007 20:50:17 -0400
Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [184.108.40.206]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l870oHso399506 for <firstname.lastname@example.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 (220.127.116.1160308/8.13.3) with ESMTP id l870oHqW023701 for <email@example.com>; Thu, 6 Sep 2007 18:50:17 -0600
Received: from internet1.lotus.com (internet1.lotus.com [18.104.22.168]) by d03av03.boulder.ibm.com (22.214.171.12460308/8.12.11) with ESMTP id l870oGRY023662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <firstname.lastname@example.org>; Thu, 6 Sep 2007 18:50:17 -0600
Received: from wtfmail02a.edc.lotus.com (wtfmail02a.lotus.com [126.96.36.199]) by internet1.lotus.com (8.14.1/8.14.1) with ESMTP id l870oFP4022636 for <email@example.com>; Thu, 6 Sep 2007 20:50:16 -0400 (EDT)
Subject: [SWMP] TCP, UDP, and multicast: are they really equivalent?
X-Mailer: Lotus Notes Release 7.0 August 18, 2005
Date: Thu, 6 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 (/)
List-Id: Discussion of a Simple Wide-area Multiuser-3D Protocol <swmp.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/swmp>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/swmp>, <mailto:email@example.com?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0160580493=="
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
- [SWMP] TCP, UDP, and multicast: are they really e… john_patterson
- Re: [SWMP] TCP, UDP, and multicast: are they real… Paul Aslin
- Re: [SWMP] TCP, UDP, and multicast: are they real… Jay C. Weber
- Re: [SWMP] TCP, UDP, and multicast: are they real… Roland Weber