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

"Jay C. Weber" <jweber@mediamachines.com> Fri, 07 September 2007 21:18 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 1ITlE7-0002Ld-8q; Fri, 07 Sep 2007 17:18:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ITlE5-0002LX-W2 for swmp@ietf.org; Fri, 07 Sep 2007 17:18:53 -0400
Received: from mx5.roble.com ([206.40.34.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ITlE4-0004Kp-IG for swmp@ietf.org; Fri, 07 Sep 2007 17:18:53 -0400
X-Scanned-By: PostConf Email Solutions
Received: from [192.168.1.101] (h-66-134-93-202.snvacaid.covad.net [66.134.93.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jay) by mail.mediamachines.com (Postfix) with ESMTP id 6876D364435; Fri, 7 Sep 2007 14:18:49 -0700 (PDT)
Message-ID: <46E1C043.5000906@mediamachines.com>
Date: Fri, 07 Sep 2007 14:18:59 -0700
From: "Jay C. Weber" <jweber@mediamachines.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: john_patterson@us.ibm.com
Subject: Re: [SWMP] TCP, UDP, and multicast: are they really equivalent?
References: <OF00B259A5.9B278BBB-ON8525734E.0082106F-8525734F.000491EF@lotus.com>
In-Reply-To: <OF00B259A5.9B278BBB-ON8525734E.0082106F-8525734F.000491EF@lotus.com>
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
Cc: swmp@ietf.org
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="===============1236999321=="
Errors-To: swmp-bounces@ietf.org

John:  I agree with your assessment that (UDP) datagrams are only appropriate for intense streams of field updates, where reliability of individual datagrams is not essential.  But as I'm sure you are aware, just as with intense streams of audio or video data, datagrams can be significantly more efficient in terms of both latency and bandwidth.

I did mean the paper to lend the impression that the "base-message" layer of the protocol is indifferent to transport, by keeping the datagram-specific components (per-message authentication plus sequence number) in the "datagram-message" layer.  My main motivation was so that any message could flow over TCP transport, in case UDP transport is not available.  I agree that it isn't practical to put all messages over UDP.  I think I did say that the first connection between two entities should be over reliable, connection-oriented transport (TCP), and then a datagram (UDP) transport could augment that as possible as useful.

Interesting question who decides when to use datagrams.  The developer of a SWMP message-sender could hard-code application knowledge of the semantics of the fields, e.g. "2nd+ position field updates should be sent as datagrams", so sender would try to establish such a transport for that that field type.  Or, the SWMP library could try to infer this from message-sending behavior, but this could be tricky and would certainly take message history before kicking in.

jay

john_patterson@us.ibm.com wrote:

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" rel="nofollow">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" rel="nofollow">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" rel="nofollow">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" rel="nofollow">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" rel="nofollow">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" rel="nofollow">https://www1.ietf.org/mailman/listinfo/swmp


--
Jay C. Weber, Ph.D.
CTO, Media Machines Inc.
650-279-2311
_______________________________________________
SWMP mailing list
SWMP@ietf.org
https://www1.ietf.org/mailman/listinfo/swmp