RE: [manet] Re: [Manet-dt] Review Request

"Dearlove, Christopher \(UK\)" <Chris.Dearlove@baesystems.com> Fri, 30 March 2007 09:15 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 1HXDD3-000327-O0; Fri, 30 Mar 2007 05:15:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXDD2-000314-1j; Fri, 30 Mar 2007 05:15:48 -0400
Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXDD1-0002AH-6s; Fri, 30 Mar 2007 05:15:48 -0400
Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l2U9FkYj006230; Fri, 30 Mar 2007 10:15:46 +0100 (BST)
Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l2U9FfPn025184; Fri, 30 Mar 2007 10:15:41 +0100
Received: from glkms0001.GREENLNK.NET ([10.15.184.1]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 30 Mar 2007 10:15:53 +0100
Received: from glkms2122.GREENLNK.NET ([10.15.184.26]) by glkms0001.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Fri, 30 Mar 2007 10:05:14 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [manet] Re: [Manet-dt] Review Request
Date: Fri, 30 Mar 2007 10:01:32 +0100
Message-ID: <D6474CBFA00000469EF69CCED4045099206C96@glkms2122>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [manet] Re: [Manet-dt] Review Request
Thread-Index: AcdyJBnDolRwhnh4TmqlEesamlsI+AAKCCWAABZyCJA=
From: "Dearlove, Christopher (UK)" <Chris.Dearlove@baesystems.com>
To: Joe Macker <joseph.macker@nrl.navy.mil>, "Charles E. Perkins" <charles.perkins@nokia.com>
X-OriginalArrivalTime: 30 Mar 2007 09:05:14.0710 (UTC) FILETIME=[87869760:01C772AA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503
Cc: manet <manet@ietf.org>, manet-dt@ietf.org
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

Well, Thomas may or may not be able to speak, as he
has had email problems. My observations would be

- We need to get something out, as all of the MANET
  work is based on this. A major restructuring, let
  alone a complete replacement, could only be
  contemplated if the current structure just didn't
  work, and that is not the case.

- To reinforce that, I was just looking back at
  packetbb-00, over a year ago. (Of course it didn't
  spring into existence in that form, but prior art
  was author drafts, in OLSRv2 etc.) That had
  essentially all the features of packetbb-04. Of
  course there have been refinements - including the
  removal of fragmentation - but the time for putting
  down a marker that this wasn't what was wanted was
  then, or slightly later when DYMO (and Charles is
  an author of DYMO) adopted it. Now is not that time.

- Editorial comment is always appropriate. Small
  changes can have their pros and cons weighted. But
  cons will include both that there are people who
  want things simpler, and that by this point in time
  any change automatically has a strike against it in
  terms of timescales.

- A comparison of packetbb with alternatives would be
  interesting, and I'd be very happy to see one. But
  that does not extend to considering an alternative
  as a replacement (for OLSRv2 at least, and hence
  also for NHDP).

- Both Joe and I have commented on mappings from a
  subset of packetbb to a more compressed format
  (especially I would say if reversible) as of
  interest. Unfortunately I can't commit to working
  on such an idea, best I can offer would be to read
  anyone else's work.


-----Original Message-----
From: Joe Macker [mailto:joseph.macker@nrl.navy.mil] 
Sent: 29 March 2007 22:56
To: 'Charles E. Perkins'
Cc: 'manet'; manet-dt@ietf.org
Subject: RE: [manet] Re: [Manet-dt] Review Request

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

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

>-----Original Message-----
>From: Charles E. Perkins [mailto:charles.perkins@nokia.com] 
>Sent: Thursday, March 29, 2007 1:03 PM
>To: ext Joe Macker
>Cc: 'SATOH, Hiroki (HitachiSDL)'; 'manet'; manet-dt@ietf.org
>Subject: Re: [manet] Re: [Manet-dt] Review Request
>
>
>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:
>> 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
>>   
>>> -----Original Message-----
>>> From: SATOH, Hiroki (HitachiSDL) 
>[mailto:hiroki.satoh.yj@hitachi.com]
>>> Sent: Wednesday, March 28, 2007 9:24 PM
>>> To: manet; manet-dt@ietf.org
>>> 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.
>>>
>>> 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 : 
>>> hiroki.satoh.yj@hitachi.com
>>> ---------------------------------------------
>>>
>>>
>>>
>>> On 2007/03/26, at 23:43, 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
>>   
>



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




********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************


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