Subject: [Manet-dt] Review Request

From: "Joe Macker" <[email-masked]>
Date: Fri, 23 Mar 2007 15:54:24 -0400

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 26 Mar 2007 07:43:00 -0700

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.

---

From: "Joe Macker" <[email-masked]>
Date: Mon, 26 Mar 2007 16:19:34 -0400

Can you clarify that you are providing more General comments (e.g.,
packetbb/nhdp)?  I am assuming you meant these comments more generally and
perhaps we start them on a separate thread.

My Review Request message (original thread) was for SMF not a general call
on all documents. Those calls should follow but SMF has optional TLV
dependencies,etc and none when operating in certain modes as I presented at
the meeting. Present experimental deployments have no TLV dependencies.  The
main issue in this case is the IPv6 DPD option header.  For IPv4 there is
also optionally no additional message size increase.

>-----Original Message-----
>From: Charles E. Perkins [mailto:[email-masked]] 
>Sent: Monday, March 26, 2007 10:43 AM
>To: ext Joe Macker
>Cc: 'manet'; [email-masked]
>Subject: Re: [Manet-dt] Review Request
>
>
>Hello folks,
>
>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 
>I would rate the relative importance as 90% vs. 10% for the 
>parseability/size tradeoff.
>
>"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
>>
>>
>>

---

From: Ian Chakeres <[email-masked]>
Date: Wed, 28 Mar 2007 15:31:31 +0530

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

---

From: "Ian Chakeres" <[email-masked]>
Date: Wed, 28 Mar 2007 20:10:51 +0530

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Mar 2007 08:32:55 -0700

Hello Ian,

> make specific suggestions to the authors and this list.
I will try to do this by next week.  In order to do so, I will have
to exhibit another packet format for comparison.  This will, of
course, involve certain assumptions that can then provide a lot
of room for discussion and championing alternative assumptions.
But perhaps at least it will provide a baseline for comparison.
> 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 
My goal would be to save some substantial packet size in the average
case.  If I can't show how to do it, then I'll happily go along with
the existing PacketBB structure, since it has been threshed out for
long enough otherwise.

Regards,
Charlie P.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Mar 2007 08:45:42 -0700

> case.

But can you do this without loss of generality?

FWIW, I advocated a TLV approach for packet encoding a
long time ago but was beaten back by forces that preferred
efficiency above all. If you're not careful, what you end
up with is a proprietary solution and/or limited domain of
applicability.

Fred
[email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 28 Mar 2007 09:12:14 -0700

Hello Fred,

O.K.  I will try to be careful to avoid the
undesirable results you mentioned.  What
do you think about Romain's proposal?

Regards,
Charlie P.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 28 Mar 2007 09:26:39 -0700

> What do you think about Romain's proposal?

I don't know; I was just starting to look at Wesley's
proposal and hadn't gotten around to Romain's yet. But
on first glance, it seems to be specific to DYMO; can
it be generalized to other protocols? (I probably won't
have much time to look at this in more details...)

Fred

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 28 Mar 2007 20:48:12 +0200

> up with is a proprietary solution and/or limited domain of

I concur with what Fred Templin states above. OSPF went down the same  
route with their LLS...

A lot of efforts were spent on the design of packetbb - in  
particular, in achieving a general format offering extensibility,  
parse-ability and compactness -- the latter through compressable/ 
aggregateable addresses and modular message/packet/tlv headers. And,  
I may add, in an open process where all input that was brought  
forward was carefully reflected on and taken into account as best  
possible. Chris has already cited examples hereof, so I won't do that  
unless prodded to do so.

I'll not reiterate Chris' email, but I agree with the general  
comments he make, that there're requirements pulling in opposite  
directions for the design of packetbb. My point of view is, that  
packetbb offers a good compromise between these requirements. I can  
only speak for OLSR, however message sizes are in the "average case"  
for OLSRv2 expected (and observed) to be less than for OLSRv1 -- with  
the added benefit of a more flexible/extensible format to boost.

I'd really not like to revert to a proprietary packet/message format,  
which will leave us with no extensibility and complicated parsing  
logic. I'd also rather not have to spend another 2+ years in  
development of an alternative format, when one exists which I find to  
be a good compromise.

Thomas

-- 
Thomas Clausen
[email-masked]
http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
http://www.lix.polytechnique.fr/hipercom/

---

From: "SATOH, Hiroki (HitachiSDL)" <[email-masked]>
Date: Thu, 29 Mar 2007 10:23:44 +0900

I agree with the importance of reducing message size especially for  
sensor network. And it could be applicable if we change packet format  
with smart way.
But from industrial point of view,  I also worry about DELAY for the  
standardization. Almost all companies could not follow frequent draft  
update, because of a lot of cost. And MANET WG already advertised  
PacketBB almost Last Call for RFC in 67th and 68th IETF.

So I urge that first of all we move packetBB to RFC. After  
standardization, we start to discuss how improve packet format and  
update RFC in need.
In my opinion packet format applicability depends on the service or  
the application in real world. It may difficult to cover every  
situation by only one document. Because the new service or the new  
situation become available by technological invention day by day. I  
think the merit of Last Call much bigger than that of delayed  
standardization. The improvement update for real application from now  
on will be done after standardization, I think.

Again I strongly recommend accelerate EVERY standardization process.  
Because I hope the MANET technique will be available as soon as  
possible in real world from industrial standpoint, now only use for  
some experimental work or limited field.

Regards,
Hiroki

---------------------------------------------
SATOH, Hiroki
Hitachi, Ltd., Systems Development Laboratory
E-mail : [email-masked]
---------------------------------------------

---

From: "Joe Macker" <[email-masked]>
Date: Thu, 29 Mar 2007 10:11:25 -0400

I would agree with Hiroki. Especially since we have had these designs on the
table for a long time now.  We discussed at previous meetings that if
special adaptations were needed for 6LOWPAN, sensor nets, etc that those
could be debated and potential adapted specific to those applications.

I would also add that fewer messages is often more important than smaller
messages. If you think about the penalty of accessing a shared channel,etc.
Of course, this depends upon the lower layer.

-Joe
>From: SATOH, Hiroki (HitachiSDL) [mailto:[email-masked]] 
>Sent: Wednesday, March 28, 2007 9:24 PM
>To: manet; [email-masked]
>Subject: Re: [manet] Re: [Manet-dt] Review Request
>
>I agree with the importance of reducing message size 
>especially for sensor network. And it could be applicable if 
>we change packet format with smart way.
>But from industrial point of view,  I also worry about DELAY 
>for the standardization. Almost all companies could not follow 
>frequent draft update, because of a lot of cost. And MANET WG 
>already advertised PacketBB almost Last Call for RFC in 67th 
>and 68th IETF.
>
>standardization, we start to discuss how improve packet format 
>and update RFC in need.
>In my opinion packet format applicability depends on the 
>service or the application in real world. It may difficult to 
>cover every situation by only one document. Because the new 
>service or the new situation become available by technological 
>invention day by day. I think the merit of Last Call much 
>bigger than that of delayed standardization. The improvement 
>update for real application from now on will be done after 
>standardization, I think.
>
>Because I hope the MANET technique will be available as soon 
>as possible in real world from industrial standpoint, now only 
>use for some experimental work or limited field.
>
>Regards,
>Hiroki
>
>Hitachi, Ltd., Systems Development Laboratory E-mail : 
>[email-masked]
>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.
>> 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.
>>
>>> At the manet WG meeting we discussed a workplan prior to moving SMF 
>>> to Last Call for Experimental consideration. While some readability 
>>> comments as soon as possible.  Positive and general comments are 
>>> encouraged along with others.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 29 Mar 2007 10:02:31 -0700

Hello Joe,

O.K.  Now I _am_ confused, and ask for advice.

I've been reluctant for quite some months to invest the
number of hours to review these documents, because
I figured that nobody would care what I said about
them very much.  During the last meeting, Thomas and
others convinced me to review them (i.e, that they
_would_ care what I said).

So do I spend the time, or not?  It will take me at least
another 6-7 hours of wall time to go through the
documents and identify editorial revisions, some more
hours to compare against alternative packet formats,
and at least that much time to carry on the e-mail
discussions.  I'm willing to do it, but not if it is a farce
and waste of time.

Please let me know!

Regards,
Charlie P.

ext Joe Macker wrote:
>> members of the 
>>> working group about this.
>>>
>>> Regards,
>>> Charlie P.
>>>
>>>
>>>
>>>
>>> ext Joe Macker wrote:
>>>       
>>>> If you an implementor and find something confusing we are 
>>>>         
>> interested 
>>     
>>>> in hearing from you.

---

From: "Joe Macker" <[email-masked]>
Date: Thu, 29 Mar 2007 17:56:25 -0400

I think your review is useful.  I am just more satisfied with packetbb than
perhaps you are and I felt the group has put a lot of time into it in open
discussion for some time now. The authors can speak for themselves.
-joe

>Sent: Thursday, March 29, 2007 1:03 PM
>To: ext Joe Macker
>Cc: 'SATOH, Hiroki (HitachiSDL)'; 'manet'; [email-masked]
>I've been reluctant for quite some months to invest the number 
>of hours to review these documents, because I figured that 
>nobody would care what I said about them very much.  During 
>the last meeting, Thomas and others convinced me to review 
>them (i.e, that they _would_ care what I said).
>
>another 6-7 hours of wall time to go through the documents and 
>identify editorial revisions, some more hours to compare 
>against alternative packet formats, and at least that much 
>time to carry on the e-mail discussions.  I'm willing to do 
>it, but not if it is a farce and waste of time.
>
>Please let me know!
>
>Regards,
>Charlie P.
>
>
>ext Joe Macker wrote:
>> I would agree with Hiroki. Especially since we have had 
>these designs 
>> on the table for a long time now.  We discussed at previous meetings 
>> that if special adaptations were needed for 6LOWPAN, sensor 
>nets, etc 
>> that those could be debated and potential adapted specific 
>to those applications.
>>
>> I would also add that fewer messages is often more important than 
>> smaller messages. If you think about the penalty of 
>accessing a shared channel,etc.
>reviewing the 
>"IETF"-like in 
>moving SMF

---

From: "SATOH, Hiroki (HitachiSDL)" <[email-masked]>
Date: Fri, 30 Mar 2007 10:22:00 +0900

Hello Charles,

I also think your review is useful for future update. It is worth for  
discussing. I am just afraid of delay for standardization from my  
experience so far.

Regards,
Hiroki

On 2007/03/30, at 2:02, Charles E. Perkins wrote:

>> smaller
>>> From: SATOH, Hiroki (HitachiSDL)  
>>> [mailto:[email-masked]] Sent: Wednesday, March 28,  
>>> 2007 9:24 PM
>>> I agree with the importance of reducing message size especially  
>>> for sensor network. And it could be applicable if we change  
>>> packet format with smart way.
>>> But from industrial point of view,  I also worry about DELAY for  
>>> the standardization. Almost all companies could not follow  
>>> already advertised PacketBB almost Last Call for RFC in 67th and  
>>> 68th IETF.
>>>
>>> In my opinion packet format applicability depends on the service  
>>> or the application in real world. It may difficult to cover every  
>>> situation by only one document. Because the new service or the  
>>> new situation become available by technological invention day by  
>>> day. I think the merit of Last Call much bigger than that of  
>>> delayed standardization. The improvement update for real  
>>> application from now on will be done after standardization, I think.
>>>
>>> Again I strongly recommend accelerate EVERY standardization  
>>> process.  Because I hope the MANET technique will be available as  
>>> soon as possible in real world from industrial standpoint, now  
>>> only use for some experimental work or limited field.
>>>
>>> Regards,
>>> Hiroki
>>>
>>>> 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.
>>>>
>>>> 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
>>>> 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  
>>>>> 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.
>>>>> Please see the recent briefings on line from the last meeting  
>>>>> to understand the recent changes and upcoming plan.
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>>
>>>>>