Re: [SWMP] Re: faster field messages

Roland Weber <ossfwot@dubioso.net> Fri, 31 August 2007 20:29 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 1IRD79-00063z-23; Fri, 31 Aug 2007 16:29:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRD78-000629-FO for swmp@ietf.org; Fri, 31 Aug 2007 16:29:10 -0400
Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRD76-00026v-PY for swmp@ietf.org; Fri, 31 Aug 2007 16:29:10 -0400
Received: from e180008012.adsl.alicedsl.de [85.180.8.12] (helo=[85.180.8.12]) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1IRD751OK1-00029X; Fri, 31 Aug 2007 22:29:07 +0200
Message-ID: <46D87A26.5040408@dubioso.net>
Date: Fri, 31 Aug 2007 22:29:26 +0200
From: Roland Weber <ossfwot@dubioso.net>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.6) Gecko/20070807 SeaMonkey/1.1.4
MIME-Version: 1.0
To: john_patterson@us.ibm.com
Subject: Re: [SWMP] Re: faster field messages
References: <OFC6875CFE.853A1ECD-ON85257348.006A3554-85257348.006BAB09@lotus.com>
In-Reply-To: <OFC6875CFE.853A1ECD-ON85257348.006A3554-85257348.006BAB09@lotus.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Provags-ID: V01U2FsdGVkX1/DBdBWHtinYpqpYt+cYyuGyyobF89la4ACMSG jFxHb2ujpopdRrOaecj0ZPItQ35YnA3YSa4EuSviqEx/bvgipG WO7MhnjdLuh0q1U/kEZXulwrqtJ+P12
X-Spam-Score: 1.7 (+)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
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>
Errors-To: swmp-bounces@ietf.org

Hello John,

> I assume that if a network element cannot formulate a legitimate ID that 
> SET messages may be used in lieu of a SETF message.  This would mean that 
> a pre-established limit would be acceptable, if large enough to cover most 
> situations.

Let's take an example: a server is sending SET/SETF messages to clients.
Is the pre-established limit imposed by the protocol, or negotiated with
each client separately?
In the first case, the server can use the same mappings for all clients,
since they are all required to support that number of mappings. In that
case, the server can build the set of messages once and send it out to
all clients, wrapping it in a client-specific envelope. I believe that
was the idea, but on the other hand a protocol imposed limit reduces the
flexibility of the protocol.
In the second case, let's say that client 1 supports 100 mappings and
client 2 supports 300 mappings. Then the server has the option of main-
taining separate outgoing mappings for each client, or of only using the
smallest number supported. The separate mappings can at least be kept
overlapping, but they will require to build separate messages for the
clients. Using only the smallest number degrades potential performance
for all clients that support more.

> I believe it is an ad hoc mechanism, but I assumed it was to make the 
> processing more efficient.  I'm not sure whether the focus was on 
> networking issues or lookup efficiency on the network elements.

The paper suggests it was introduced to reduce message size. If this
is handled ad hoc with a strictly limited lifetime of the mapping,
it is quite efficient. A network element realizes that the set of
messages to be sent can be efficiently encoded by defining a few
mappings, and does so. The receiver takes the mapping, processes the
messages, and forgets the mapping again. No problem.
But as soon as you're introducing mappings with a longer lifetime,
as was implied in your discussion, you raise the memory question.
The mapping moves from temporary memory (during message processing)
to session memory. In the example above, each client can define
independent mappings, and the server will have to store those somehow.
If there is no limit, a single malicious client can take down the
server simply by defining an ever-growing set of mappings.
If a limit is imposed by the protocol, the worst-case memory consumption
on the server will grow linearly with the number of clients. Negotiation
would allow the server to set a lower limit than the client, allowing
for efficient sending (with many mappings) while limiting the memory
consumption on the receiving side. But the price of negotiation is to
create separate messages for each client with a differing number of
supported mappings.

Jay says that maintaining per-client mappings on the server is not
complicated. That is surely true as long as the server has the memory
to spare. But what happens when the server has to refuse storing more
mappings in order to keep the memory consumption in check? Throwing
out old mappings is an option of course, but the client needs to be
told which mappings are available for message encoding and which can
no longer be used.

Jay, maybe you can tell us how you are handling this situation
in your implementation?

cheers,
  Roland


_______________________________________________
SWMP mailing list
SWMP@ietf.org
https://www1.ietf.org/mailman/listinfo/swmp