[Manet-dt] Re: [manet] Re: PacketBB

"Ian Chakeres" <ian.chakeres@gmail.com> Wed, 28 March 2007 14:40 UTC

Return-path: <manet-dt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZKc-0005dr-OB; Wed, 28 Mar 2007 10:40:58 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HWZKa-0005bV-DM for manet-dt@ietf.org; Wed, 28 Mar 2007 10:40:56 -0400
Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HWZKX-0007aj-3O for manet-dt@ietf.org; Wed, 28 Mar 2007 10:40:56 -0400
Received: by ug-out-1314.google.com with SMTP id 72so215027ugd for <manet-dt@ietf.org>; Wed, 28 Mar 2007 07:40:51 -0700 (PDT)
DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FDVTkLAC3FJjsqbpxDa1sUqrxv7iFsaYp0mpCcCZ/QK88iyVKnxX59tkpLwVT2RhSQ6QujhJzx2c0Joj7NkjNqUP6i9+SFXlOaKzhidtayEMEz0KeUz7PkTWej9PiykvwlO7AMweqdp+Nf47+DfvVbXTFnUvOzwkken6L589bnA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=eVLdpYUBANmZgCh2j7v/6mE13cxtGMA/1FQSAx5an240GLodl+CbeAn5gSDaWClY39KDHlogRKPLJ5m2ufBs7/CdBhjQFMkc6FN0nvVYYqM6LHCS42Lsr7DTq0BSsEWgVynasbMMd+n25CXP7LCG5vum4hTugctmI9hxofX1wzk=
Received: by 10.78.138.6 with SMTP id l6mr4272784hud.1175092851401; Wed, 28 Mar 2007 07:40:51 -0700 (PDT)
Received: by 10.78.45.10 with HTTP; Wed, 28 Mar 2007 07:40:51 -0700 (PDT)
Message-ID: <374005f30703280740k196840y32fdd50671535625@mail.gmail.com>
Date: Wed, 28 Mar 2007 20:10:51 +0530
From: Ian Chakeres <ian.chakeres@gmail.com>
To: Romain Thouvenin <romain.thouvenin@gmail.com>
In-Reply-To: <bfe74ee30703280649u5406e0ffva6614ec6a1e081bc@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <019c01c76d85$0e6904f0$165cfa84@SEXTANT> <4607DBF4.8060608@nokia.com> <963155AB-4ECA-4082-96CE-1A003636C9E3@gmail.com> <bfe74ee30703280649u5406e0ffva6614ec6a1e081bc@mail.gmail.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Cc: manet <manet@ietf.org>, manet-dt@ietf.org
Subject: [Manet-dt] Re: [manet] Re: PacketBB
X-BeenThere: manet-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MANET Design Team <manet-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/manet-dt>
List-Post: <mailto:manet-dt@ietf.org>
List-Help: <mailto:manet-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=subscribe>
Errors-To: manet-dt-bounces@ietf.org

Romain, thanks for your implementation experience. It is great to hear
from implementors about what works and more importantly what doesn't
work.

Can you make some specific suggestions regarding PacketBB and what you
think could be improved?

I would love it if you also examine NHDP or OLSRv2 to understand how
PacketBB fulfills the needs of these three protocols. Maybe we can
find something to make it simpler or more efficiency.

I agree PacketBB could be simpler, but I think it would be at the
expense of more bits & less flexibility.

Ian

On 3/28/07, Romain Thouvenin <romain.thouvenin@gmail.com> wrote:
> I had similar thoughts than Charlie.
> I am implementing DYMO on TinyOS, and the default packet size of AM
> messages is 28 bytes (it can be increased to up to about 250 bytes).
> So any saved byte is appreciated.
>
> On <http://tymo.sourceforge.net/packetformat/>, I briefly describe a
> format for DYMO that I think smaller and simpler. I may be wrong, the
> implementation hasn't gone far enough yet to say anything. I only give
> two examples on the page, the sizes with the original format would be
> 37 and 23.
>
> Though the format is specifically designed for dymo, it might help
> improving packetbb. I hope.
>
> Regards,
>
> Romain
>
> On 3/28/07, Ian Chakeres <ian.chakeres@gmail.com> wrote:
> > Charlie, I encouraged you (and others) to review PacketBB and to
> > suggest improvements. If you feel PacketBB is too heavyweight please
> > make specific suggestions to the authors and this list.
> >
> > I personally disagree about the expensive cost of PacketBB and the
> > cost of using a TLV structure. Can you please provide some specific
> > examples where the cost is large? Or where we might save lots of bits/
> > bytes for NHDP, DYMO, or OLSRv2? In my analysis PacketBB almost
> > always results in fewer bits/bytes than a non-compacting format.
> >
> > Ian Chakeres
> >
> > On Mar 26, 2007, at 8:13 PM, Charles E. Perkins wrote:
> >
> > >
> > > Hello folks,
> > >
> > > Once again, I urge that we place as much consideration as
> > > possible on reducing message size to the maximum extent.
> > > I have myself been reluctant to spend a lot of time on reviewing
> > > the document because I worry that my comments will not be
> > > taken as constructive.  Ian has expressed his concern that I
> > > am too late to make any suggestions for substantial change.
> > >
> > > I believe that the TLV structure is very expensive in terms
> > > of byte overhead.  I also think that parseability is far less
> > > important than message size, although both are important.
> > > I would rate the relative importance as 90% vs. 10% for
> > > the parseability/size tradeoff.
> > >
> > > Similar considerations may apply to NHDP.
> > >
> > > It is pretty clear that the trend has been to be more
> > > "IETF"-like in the message design, at the expense of
> > > message size.  In my opinion, this is inappropriate if we
> > > want our work to be applicable for sensors or 6lowpan
> > > or other low-power devices.  When one byte of airtime
> > > consumes as much energy as millions of processor cycles,
> > > it makes sense to favor additional processing to reduce
> > > message size.  IETF protocols typically favor human
> > > readability of the protocol document at the expense
> > > of message size, and for many applications this is wholly
> > > inappropriate.
> > >
> > > I would be very interested to hear opinions from other
> > > members of the working group about this.
> > >
> > > Regards,
> > > Charlie P.
> > >
> > >
> > >
> > >
> > > ext Joe Macker wrote:
> > >> At the manet WG meeting we discussed a workplan prior to moving
> > >> SMF to Last
> > >> Call for Experimental consideration. While some readability
> > >> improvements may
> > >> be done the authors request that the WG provide comments as soon as
> > >> possible.  Positive and general comments are encouraged along with
> > >> others.
> > >> If you an implementor and find something confusing we are
> > >> interested in
> > >> hearing from you.
> > >> Please see the recent briefings on line from the last meeting to
> > >> understand
> > >> the recent changes and upcoming plan.
> > >>
> > >> Thanks,
> > >> Joe
> > >>
> > >>
> > >>
> > >> _______________________________________________
> > >> Manet-dt mailing list
> > >> Manet-dt@ietf.org
> > >> https://www1.ietf.org/mailman/listinfo/manet-dt
> > >>
> > >
> > >
> > > _______________________________________________
> > > Manet-dt mailing list
> > > Manet-dt@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/manet-dt
> >
> >
> > _______________________________________________
> > manet mailing list
> > manet@ietf.org
> > https://www1.ietf.org/mailman/listinfo/manet
> >
>

_______________________________________________
Manet-dt mailing list
Manet-dt@ietf.org
https://www1.ietf.org/mailman/listinfo/manet-dt