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

From: [email-masked]
Date: Thu, 6 Sep 2007 20:50:58 -0400

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/swmp

---

From: Paul Aslin <[email-masked]>
Date: Thu, 6 Sep 2007 20:51:10 -0700 (PDT)

--- [email-masked] wrote:

[snip]

> When I think about using swmp (or the enlarged version I
http://www1.ietf.org/mail-archive/web/swmp/current/msg00032.html),
> I 

Yeah position updates are a fine example of where data loss
isn't so much an issue. Probably should be some sort of
limiter applied to constantly updateing values, that more
an issue for programmers writing SWMP clients/servers/

I can see instances where programmers will be using SWMP
fields for information which lost data would be noticeable.
Say using a string to transfer chat text, or boolean states
of things like doors.

Perhaps we need to look at a flag, that can be set per
field/node as to the priority of updates to fields. In
other words, 'priority TRUE' would mean use TCP (or UDP
with some way of resending lost packets), FALSE would be
use UDP.

____________________________________________________________________________________
Choose the right car based on your needs.  Check out Yahoo! Autos new Car Finder tool.
http://autos.yahoo.com/carfinder/

---

From: "Jay C. Weber" <[email-masked]>
Date: Fri, 07 Sep 2007 14:18:59 -0700

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

[email-masked] 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)
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.

--

Jay C. Weber, Ph.D.

CTO, Media Machines Inc.

650-279-2311

---

From: Roland Weber <[email-masked]>
Date: Sun, 09 Sep 2007 09:05:05 +0200

Jay C. Weber wrote:
> 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'm missing practical experience here, but this is very intuitive.
Maybe it is oversimplified to just distinguish between TCP and UDP?
UDP in a local network should be much more reliable than UDP over
an internet connection. On the other hand, plain TCP could be
augmented by TLS for client authentication on the initial channel.
And then there's unidirectional multicast (probably reliable?).

How about defining a few channel classes, and leaving it up to
the implementations to choose the transport mechanism based on
configurations and available runtime data? For example:

RSD: reliable and slow, duplex. (TCP, TLS)
RFD: reliable and reasonably fast, duplex. (TCP, UDP/local)
UFD: unreliable and fast, duplex. (UDP)
RFS: reliable and fast, simplex. (multicast)
UFS: unreliable and fast, simplex. (UDP/firewall)

Gateways or proxies would be allowed to change the transport
where appropriate, for example from TCP/internet to UDP/local.

cheers,
  Roland