Re: [SWMP] Re: faster field messages

Roland Weber <ossfwot@dubioso.net> Fri, 31 August 2007 16:33 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 1IR9RI-0006XB-2H; Fri, 31 Aug 2007 12:33:44 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IR9RG-0006Wt-Ic for swmp@ietf.org; Fri, 31 Aug 2007 12:33:42 -0400
Received: from moutng.kundenserver.de ([212.227.126.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IR9RF-0003Dr-UR for swmp@ietf.org; Fri, 31 Aug 2007 12:33:42 -0400
Received: from e180008012.adsl.alicedsl.de [85.180.8.12] (helo=[85.180.8.12]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1IR9R73Lkm-0006xC; Fri, 31 Aug 2007 18:33:37 +0200
Message-ID: <46D842E1.4050201@dubioso.net>
Date: Fri, 31 Aug 2007 18:33:37 +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: swmp@ietf.org
Subject: Re: [SWMP] Re: faster field messages
References: <OF95516987.80B2064B-ON85257346.00579557-85257346.00581671@lotus.com>
In-Reply-To: <OF95516987.80B2064B-ON85257346.00579557-85257346.00581671@lotus.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Provags-ID: V01U2FsdGVkX19R4HVb3rzySSN10CN4eqL8Ztmlqh0CxnphuWf skSdRMBFDGSkrjKXDhZGt+jMtNI8h3H5Pc+yNMmjjVaOv3WT8t 3YUgyTI7Tz0EcwDFduKzeEVTLJd9qxZ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
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

> 
> So each side gets to declare its own mapping and the other is obligated to 
> keep track of that.

What are the limits, like a maximum number of mappings, or a
maximum guaranteed lifetime of mappings? Unlimited mappings
that each peer needs to keep track of open the gate for easy
DoS attacks. Negotiated limits with each peer would not allow
a server to use the same mappings for each client.
One approach would be that a peer advertises how many mappings
it is going to use, so that the partner can decide on whether
to accept that number or cancel the connection. Another is to
define a maximum number in the protocol, like 255 or 256. That
may be too restrictive, but allowing two bytes and more than
65000 mappings will trigger memory problems, in particular on
a server.

>From the paper (I've read it by now) I perceived it rather
as an ad hoc technique used to shrink the size of a group of
messages in an UDP packet. In that case, the lifetime of a
mapping could be restricted to the packet. But that doesn't
map to TCP connections, or your discussion of defining the
mappings on a separate channel.
In the extreme case of ad hoc, you'd have only one mapping
which is defined at the beginning of a sequence of messages
referring to the same node, and overwritten by the next
definition. Actually, that's not even a mapping anymore,
but an implicit argument.

cheers,
  Roland

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