Re: [SWMP] Re: faster field messages

john_patterson@us.ibm.com Fri, 31 August 2007 19:36 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 1IRCI3-00052J-Ox; Fri, 31 Aug 2007 15:36:23 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRCI2-00051r-3F for swmp@ietf.org; Fri, 31 Aug 2007 15:36:22 -0400
Received: from e3.ny.us.ibm.com ([32.97.182.143]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IRCI1-00016V-9M for swmp@ietf.org; Fri, 31 Aug 2007 15:36:21 -0400
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e3.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7VJaKoH013482 for <swmp@ietf.org>; Fri, 31 Aug 2007 15:36:20 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7VJaK28436170 for <swmp@ietf.org>; Fri, 31 Aug 2007 15:36:20 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7VJaKle015865 for <swmp@ietf.org>; Fri, 31 Aug 2007 15:36:20 -0400
Received: from internet1.lotus.com (internet1.lotus.com [9.33.9.11]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7VJaJl1015852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 31 Aug 2007 15:36:20 -0400
Received: from wtfmail02.edc.lotus.com (wtfmail02.lotus.com [9.33.9.69]) by internet1.lotus.com (8.14.1/8.14.1) with ESMTP id l7VJaJVO018667; Fri, 31 Aug 2007 15:36:19 -0400 (EDT)
In-Reply-To: <46D842E1.4050201@dubioso.net>
To: Roland Weber <ossfwot@dubioso.net>
Subject: Re: [SWMP] Re: faster field messages
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0 August 18, 2005
Message-ID: <OFC6875CFE.853A1ECD-ON85257348.006A3554-85257348.006BAB09@lotus.com>
From: john_patterson@us.ibm.com
Date: Fri, 31 Aug 2007 15:36:59 -0400
X-MIMETrack: Serialize by Router on WTFMAIL02/WTF/M/Lotus(Build V703_08192007|August 19, 2007) at 08/31/2007 03:37:03 PM, Serialize complete at 08/31/2007 03:37:03 PM
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8
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="===============0420418756=="
Errors-To: swmp-bounces@ietf.org

Roland:

I assumed that the IDs are valid for a session, i.e., the messages between 
the HELLO and the BYE.

I also assume that any network element wishing to use an ID must first 
send a SET message establishing the mapping for that node, which can be 
followed by later SETF messages that use the ID.

I assume that at any time a SET message may be issued to change the ID 
that is being used even if there have been prior SETF messages using an 
earlier ID.

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.

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.  I assume 
the technique was introduced because the X3D data model has within-node 
names for fields. 

jfp

Roland Weber <ossfwot@dubioso.net> wrote on 08/31/2007 12:33:37 PM:

> > 
> > 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
_______________________________________________
SWMP mailing list
SWMP@ietf.org
https://www1.ietf.org/mailman/listinfo/swmp