From manet-bounces@ietf.org Thu Nov 01 03:45:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InUgh-0003Km-8O; Thu, 01 Nov 2007 03:41:59 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InUgf-0003IH-UQ for manet-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 03:41:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InUgf-0003DN-3b for manet@ietf.org; Thu, 01 Nov 2007 03:41:57 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InUgT-0002Jq-PL for manet@ietf.org; Thu, 01 Nov 2007 03:41:52 -0400 Received: (qmail 29644 invoked from network); 1 Nov 2007 08:41:24 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 1 Nov 2007 08:41:23 +0100 From: "Teco Boot" To: "'Ian Chakeres'" References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl> <374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> <003001c81bbf$bbbb31d0$33319570$@nl> <374005f30710310629i3224ed8cy4cc94dc3c71f491e@mail.gmail.com> <004501c81bcf$b3169140$1943b3c0$@nl> <007301c81be7$e1cdb7d0$a5692770$@nl> <374005f30710311917j6ec5d75bi5a16564105de1947@mail.gmail.com> In-Reply-To: <374005f30710311917j6ec5d75bi5a16564105de1947@mail.gmail.com> Subject: RE: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Date: Thu, 1 Nov 2007 08:40:43 +0100 Message-ID: <000001c81c5a$945f5850$bd1e08f0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgcLVvXOqSNemLfSxmHGoPI3852YAAKmusA Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: "'Dearlove, Christopher \(UK\)'" , 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I am sorry. I agree on not handling this in packetbb right now. But I cannot accept that it is not written down and simultaneously the authors of the draft have strong opinions on it. By the way, another author attaches a high value on integrity control in packetbb, another _long_ discussion is happening on the ML. Simply writing down what we do helps. Word "integrity" is not mentioned in packetbb draft. Word "transport" is mentioned, and immediately I am confused. It is about pkt-length, what to do when a transport protocol has length information and when it has not. Different rules on how the pkt-length is being used. Sorry, this needs to be fixed. Otherwise, I am almost sure incompatible implementations will pop up which aims that they are both fully compliant with the standard. I think this is not acceptable. Teco > -----Oorspronkelijk bericht----- > Van: Ian Chakeres [mailto:ian.chakeres@gmail.com] > Verzonden: donderdag 1 november 2007 3:18 > Aan: Teco Boot > CC: Dearlove, Christopher (UK); manet > Onderwerp: Re: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt > > I do not think any modification needs to be made to PacketBB regarding > this matter. In the future, we can specify additional > behavior/protocols if/when it is needed. > > As Chris stated, transport and integrety are not handled in PacketBB. > > I could see the possible insertion of some text in NHDP, DYMO, OLSRv2, > and potentially another draft specifying an integrity TLV. > > Ian > > On 10/31/07, Teco Boot wrote: > > > > Anyway, we have to update the packetbb document for it. Right > now, it > > > is > > > > tailored for UDP and not for IP. > > > > > > Actually, no it isn't. The letters "UDP" do not appear anywhere > > > in it. They used to (but only as an example), now they don't > > > appear at all. This was for this very reason. > > > > Partly agreed: UDP is not mentioned in packetbb. > > Partly not agreed: OLSR, NHDP and DYMO mentions UDP. > > > > My main concern is that if someone wants to use the manet IP_PROTO > and > > packetbb, something is missing. I don't like a transport protocol > that does > > not implement some kind of error detection. > > Ian's proposal that it can be added in a future extension is > acceptable for > > me. Can we add some words on this in packetbb? I prefer text > specifying that > > it is required that lower layers MUST fulfill needs for integrity in > case > > packetbb does not provide such. > > Otherwise, I am against requesting IP_PROTO. > > > > Teco. > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 01 06:16:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InX3U-0007Wy-KE; Thu, 01 Nov 2007 06:13:40 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InX3S-0007Wr-Mf for manet-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 06:13:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InX3S-0007Oz-Ci for manet@ietf.org; Thu, 01 Nov 2007 06:13:38 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InX3D-0001qE-Bt for manet@ietf.org; Thu, 01 Nov 2007 06:13:28 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lA1ACfkx018484 for ; Thu, 1 Nov 2007 10:12:41 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id lA1ACfgs004346 for ; Thu, 1 Nov 2007 10:12:41 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 01 Nov 2007 10:12:40 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 1 Nov 2007 10:12:40 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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: I-D Action:draft-ietf-manet-iana-06.txt Date: Thu, 1 Nov 2007 10:12:39 -0000 Message-ID: In-Reply-To: <000001c81c5a$945f5850$bd1e08f0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Re: I-D Action:draft-ietf-manet-iana-06.txt Thread-Index: AcgcLVvXOqSNemLfSxmHGoPI3852YAAKmusAAAW/PmA= References: <374005f30710252152s7dce305bjb3a8eef2c9e3c550@mail.gmail.com> <009401c81b19$29a04200$7ce0c600$@nl> <374005f30710310345x432a6a6dk82546060d6a2b2a7@mail.gmail.com> <003001c81bbf$bbbb31d0$33319570$@nl> <374005f30710310629i3224ed8cy4cc94dc3c71f491e@mail.gmail.com> <004501c81bcf$b3169140$1943b3c0$@nl> <007301c81be7$e1cdb7d0$a5692770$@nl> <374005f30710311917j6ec5d75bi5a16564105de1947@mail.gmail.com> <000001c81c5a$945f5850$bd1e08f0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ian Chakeres" X-OriginalArrivalTime: 01 Nov 2007 10:12:40.0966 (UTC) FILETIME=[BC824260:01C81C6F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I am sorry. I agree on not handling this in packetbb right now. But I cannot > accept that it is not written down and simultaneously the authors of the > draft have strong opinions on it. Well, in an ideal world I'd sit down and write an integrity TLV ID right now. Unfortunately it is not that real world, and even the time I'm spending on the list is more than I really have to spare. > By the way, another author attaches a high value on integrity control in > packetbb, another _long_ discussion is happening on the ML. Simply writing > down what we do helps. > Word "integrity" is not mentioned in packetbb draft. By intent. > Word "transport" is mentioned, and immediately I am confused. That could/should be changed. Here "transport" really means carrying/ encapsulating, whether strictly a network or transport layer protocol. > It is about > pkt-length, what to do when a transport protocol has length information and > when it has not. Different rules on how the pkt-length is being used. Sorry, > this needs to be fixed. Otherwise, I am almost sure incompatible > implementations will pop up which aims that they are both fully compliant > with the standard. I think this is not acceptable. There's no ambiguity, it doesn't say use either, it says "use packet length here if present, otherwise use length from (transport, but see above) protocol", a clear order of priority. I see no reason to change that. (Had it not given a priority I would have agreed with you.) ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 01 12:15:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InccR-0001U7-Fo; Thu, 01 Nov 2007 12:10:07 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InccP-0001Sh-Mx for manet-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 12:10:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InccP-0001Is-Cf for manet@ietf.org; Thu, 01 Nov 2007 12:10:05 -0400 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InccE-0007U1-Te for manet@ietf.org; Thu, 01 Nov 2007 12:10:01 -0400 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lA1G91bt026471; Thu, 1 Nov 2007 12:09:11 -0400 (EDT) Message-Id: <200711011609.lA1G91bt026471@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007110112090721255 ; Thu, 01 Nov 2007 12:09:07 -0400 From: "Justin Dean" To: "'Charles E. Perkins'" , "'ext Dearlove, Christopher \(UK\)'" Subject: RE: [manet] Regarding packetbb constraints on ordering and uniqueness. Date: Thu, 1 Nov 2007 12:14:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Acgb2nY0Wctg6md4Tv+liyDPjLVPrwAAXI4g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4728A9F5.5040204@nokia.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I would like to address one point of Charles' message with regards to mutual exclusivity in TLVs as I think it's one of the major differences in perception design between some and the packetbb authors. I like to look at TLVs as containers for variables which are then used by the protocol being designed. Variables inherently do not have more than one value. A variable could be a list of values in which case multiple TLVs or an explicit TLV designed to carry multiple values for the whole range of values fits nicely. Could some gains (I would argue very minor ones) be had by allowing multiple values of the same TLV to be included in a packetbb format? Yes, but again very minor. By forcing exclusivity it forces the protocol designer to clearly and explicitly design their TLV types and spaces so as not to be ambiguous. I feel this is very important. What I really have a hard time with myself is I haven't seen a compelling example of something you couldn't do with the current TLV structure including the restrictions. There have been some examples, which have been discussed on this list, which were slightly smaller in size in some cases but which were much less clear in the content which was being conveyed. I am not saying saving bytes is not a worthwhile goal but with the current setup there are already multiple ways to encode data and which is most efficient depends on the data being encoded. In the end it may just be that packetbb will never be as efficient as some might wish it to be, a cost incurred by the added flexibility, and extensibility. That being said the testing I've seen done with OLSRv2 shows packets which are smaller on average than OLSR for most networks. Justin Ps. Charlie I would be more than willing to go over, off list for now, any specific examples you may have with regards to an encoding which seems to need the no more than one TLV type per address restriction needed. > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > Sent: Wednesday, October 31, 2007 12:15 PM > To: ext Dearlove, Christopher (UK) > Cc: Manet > Subject: Re: [manet] Regarding packetbb constraints on > ordering and uniqueness. > > > Hello Chris, > > ext Dearlove, Christopher (UK) wrote: > > > >> I do think the solution as currently > >> specified is a layer violation and relatively difficult to > put into > >> practice. > >> > > > > We do it in OLSRv1. It works, lots of people use it. > OLSRv2, and hence > > since we spun it out, packetbb, is using already proven technology. > > This is self-evidently therefore not difficult to put into practice. > > > The issue is whether or not one has protocol packets of > dissimilar varieties to collect together into the bundle. > This is a matter of timing, or perhaps delaying some messages. > > It is not a comment on the ability to write the code taking > the packets as input parameters. I would be curious to read > about performance studies using realistic data traces, > comparing the bundling vs. non-bundling approach during > "normal" web traffic. I note that the IPv6 working group > already rejected such an approach. Perhaps you claim to know > better somehow. > > I feel that your responses are, more than almost anyone > else's, quite dismissive of concerns that have been raised. > > As for the rest of your points, I'm not going to go through it all > > again. > I do not find this surprising. It takes a long time. It > took me a long time to compose the message. It would take > you a long time to present any realistic and engaging > response. You have to decide whether it is worth the effort. > > > It has been pointed out many times how ordering permits > one-pass easy > > verification of non-duplication. > > > It has been pointed out many times that this feature is not > universally applicable, most likely not economical, and > certainly not inspired by current IETF practice. > > Regards, > Charlie P. > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 01 15:20:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InfX0-0006xg-PS; Thu, 01 Nov 2007 15:16:42 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1InfWz-0006vL-2F for manet-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 15:16:41 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InfWy-0006vB-MW for manet@ietf.org; Thu, 01 Nov 2007 15:16:40 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InfWx-0003IG-HH for manet@ietf.org; Thu, 01 Nov 2007 15:16:40 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA1JGA9S006794; Thu, 1 Nov 2007 21:16:33 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 21:16:00 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 14:15:50 -0500 Received: from [172.18.141.134] ([172.18.141.134]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 14:15:50 -0500 Message-ID: <472A25E5.6050006@nokia.com> Date: Thu, 01 Nov 2007 12:15:49 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Justin Dean Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. References: <200711011609.lA1G91bt026471@s2.itd.nrl.navy.mil> In-Reply-To: <200711011609.lA1G91bt026471@s2.itd.nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2007 19:15:50.0128 (UTC) FILETIME=[9D29BF00:01C81CBB] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: "'ext Dearlove, Christopher \(UK\)'" , 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Justin, I agree with you that the current TLV model in packetbb is modeled after single-value variable assignment. But there are ways to associate "valu-able" information to addresses that do not fit this intuitive model so closely. If some address is to be associated with multiple values of type T, then the the current model needs to have some tricks applied. If addresses 10-20 need to be associated with three values of type T, and addresses [15,25] need to be associated with two more values of type T, then we have a definite problem. Perhaps, in my mind, the most amazing thing about this discussion is just that it is so unnecessary. The type ordering and specific algorithms for sorting really need to be on a per-protocol basis. That would solve the whole problem in my mind, and the only issue raised against that has to do with an internal parser optimization that is wholly outside the realm of typical protocol discussions. In my mind, this is not about whether packetbb is efficient, or about trying to save some more bytes. It is about placing unneeded constraints on associating valu-able information to addresses. Regarding: > What I really have a hard time with myself is I haven't seen a compelling > example of something you couldn't do with the current TLV structure > including the restrictions. There have been some examples, which have been > discussed on this list, which were slightly smaller in size in some cases > but which were much less clear in the content which was being conveyed. If this is about SMURF, then: (a) I showed a MAJOR decrease in packet size. I'd have to go back and check, but I think that the packetbb formats would have _doubled_ the packet size requirement. (b) More to the point, the restrictions would nearly prohibit other works such as I have done, and the restrictions are supposed to be for ALL future protocols, not just the ones we can envision today. (c) The protocol itself works great, so I am sorry for another reason that you do not find my examples compelling. For myself, I think that the arguments _for_ the ordering restrictions are _drastically_ less compelling, compared to arguments about packet bloat and unnecessary restriction (and non-IETF-ness). By the latter, I am referring to the dearth of any examples in other working groups where such ordering restrictions based on numeric type have been imposed. And that is for _any_ protocol, much less for an entire class of all future protocols (!) (I mean _really_!!!). Nobody yet explained either why manet protocols are so special to need this, or why it is better to sort on the sending side for easier checking on the receiving side, versus sorting and checking both on the receiving side. That exposes the proper manner for protocol specification, in that the type checking is done according to the needs of the type, not the existing sort-by-fiat arrangement in the parser. I have raised many other points and variations on these points. I appreciate that you have taken the time to start to respond, and hope we can go forward. Regards, Charlie P. ext Justin Dean wrote: > I would like to address one point of Charles' message with regards to mutual > exclusivity in TLVs as I think it's one of the major differences in > perception design between some and the packetbb authors. I like to look at > TLVs as containers for variables which are then used by the protocol being > designed. Variables inherently do not have more than one value. A variable > could be a list of values in which case multiple TLVs or an explicit TLV > designed to carry multiple values for the whole range of values fits nicely. > Could some gains (I would argue very minor ones) be had by allowing multiple > values of the same TLV to be included in a packetbb format? Yes, but again > very minor. By forcing exclusivity it forces the protocol designer to > clearly and explicitly design their TLV types and spaces so as not to be > ambiguous. I feel this is very important. > > What I really have a hard time with myself is I haven't seen a compelling > example of something you couldn't do with the current TLV structure > including the restrictions. There have been some examples, which have been > discussed on this list, which were slightly smaller in size in some cases > but which were much less clear in the content which was being conveyed. I > am not saying saving bytes is not a worthwhile goal but with the current > setup there are already multiple ways to encode data and which is most > efficient depends on the data being encoded. > > In the end it may just be that packetbb will never be as efficient as some > might wish it to be, a cost incurred by the added flexibility, and > extensibility. That being said the testing I've seen done with OLSRv2 shows > packets which are smaller on average than OLSR for most networks. > > Justin > > Ps. Charlie I would be more than willing to go over, off list for now, any > specific examples you may have with regards to an encoding which seems to > need the no more than one TLV type per address restriction needed. > > >> -----Original Message----- >> From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >> Sent: Wednesday, October 31, 2007 12:15 PM >> To: ext Dearlove, Christopher (UK) >> Cc: Manet >> Subject: Re: [manet] Regarding packetbb constraints on >> ordering and uniqueness. >> >> >> Hello Chris, >> >> ext Dearlove, Christopher (UK) wrote: >> >>>> I do think the solution as currently >>>> specified is a layer violation and relatively difficult to >>>> >> put into >> >>>> practice. >>>> >>>> >>> We do it in OLSRv1. It works, lots of people use it. >>> >> OLSRv2, and hence >> >>> since we spun it out, packetbb, is using already proven technology. >>> This is self-evidently therefore not difficult to put into practice. >>> >>> >> The issue is whether or not one has protocol packets of >> dissimilar varieties to collect together into the bundle. >> This is a matter of timing, or perhaps delaying some messages. >> >> It is not a comment on the ability to write the code taking >> the packets as input parameters. I would be curious to read >> about performance studies using realistic data traces, >> comparing the bundling vs. non-bundling approach during >> "normal" web traffic. I note that the IPv6 working group >> already rejected such an approach. Perhaps you claim to know >> better somehow. >> >> I feel that your responses are, more than almost anyone >> else's, quite dismissive of concerns that have been raised. >> >>> As for the rest of your points, I'm not going to go through it all >>> again. >>> >> I do not find this surprising. It takes a long time. It >> took me a long time to compose the message. It would take >> you a long time to present any realistic and engaging >> response. You have to decide whether it is worth the effort. >> >> >>> It has been pointed out many times how ordering permits >>> >> one-pass easy >> >>> verification of non-duplication. >>> >>> >> It has been pointed out many times that this feature is not >> universally applicable, most likely not economical, and >> certainly not inspired by current IETF practice. >> >> Regards, >> Charlie P. >> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> >> > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 01 15:58:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ing8g-000752-Fp; Thu, 01 Nov 2007 15:55:38 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ing8e-000743-Tq for manet-confirm+ok@megatron.ietf.org; Thu, 01 Nov 2007 15:55:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ing8e-00073Q-JJ for manet@ietf.org; Thu, 01 Nov 2007 15:55:36 -0400 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ing8e-0004ao-1s for manet@ietf.org; Thu, 01 Nov 2007 15:55:36 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA1JtBUE013554; Thu, 1 Nov 2007 21:55:33 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 21:55:11 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 14:55:08 -0500 Received: from [172.18.141.134] ([172.18.141.134]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 14:55:08 -0500 Message-ID: <472A2F1B.6030901@nokia.com> Date: Thu, 01 Nov 2007 12:55:07 -0700 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Ian Chakeres Subject: Re: [manet] PacketBB multimessage format References: <374005f30710311931o319f2288p9041c4942652009@mail.gmail.com> In-Reply-To: <374005f30710311931o319f2288p9041c4942652009@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Nov 2007 19:55:08.0486 (UTC) FILETIME=[1ADA9E60:01C81CC1] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Ian, I hope my follow-up had already clarified that I am not opposing the inclusion of this feature in packetbb. I also hope that [manet] can be viewed as a good mailing list for people to discuss interesting technical details about the specifications under consideration. This should extend even to discussions about clarifying one's understanding and application of the features of the protocols, and comparing them to other related work in other IETF groups. Regards, Charlie P. ext Ian Chakeres wrote: >>> The idea of collecting multiple messages in a packet and transmit >>> these in one transmission is to reduce the MAC overhead >>> > > The multimessage format incurs no overhead for > messages/implementations that do not make use of it. Therefore, I see > little reason to debate this issue. > > Let's try to keep our discussion on improving and finishing PacketBB. > > Ian > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 02 09:59:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inx07-0000e5-Ij; Fri, 02 Nov 2007 09:55:55 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Inx05-0000cO-Pv for manet-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 09:55:53 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inx05-0000bp-6o for manet@ietf.org; Fri, 02 Nov 2007 09:55:53 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Inx04-0007e7-Ud for manet@ietf.org; Fri, 02 Nov 2007 09:55:53 -0400 X-IronPort-AV: E=Sophos;i="4.21,362,1188792000"; d="scan'208";a="136054711" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Nov 2007 09:55:52 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA2DtqT9001847; Fri, 2 Nov 2007 09:55:52 -0400 Received: from dhcp-64-102-198-236.cisco.com (dhcp-64-102-198-236.cisco.com [64.102.198.236]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA2Dtqfo003823; Fri, 2 Nov 2007 13:55:52 GMT Message-ID: <472B2C68.2080308@cisco.com> Date: Fri, 02 Nov 2007 09:55:52 -0400 From: Russ White User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. References: <200711011609.lA1G91bt026471@s2.itd.nrl.navy.mil> <472A25E5.6050006@nokia.com> In-Reply-To: <472A25E5.6050006@nokia.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=880; t=1194011752; x=1194875752; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[manet]=20Regarding=20packetbb=20constraints=20on=20o rdering=20and=20uniqueness. |Sender:=20 |To:=20=22Charles=20E.=20Perkins=22=20; bh=WIDx95BlQ3J35SePk3s/4mJqw+r8wA/kek+c5P3c+OA=; b=uLS1+T39CwELDpqeiljsBXWInJWeJ/i7025KdITKEa2A/pA1GUAlprFoEOYIa6vviXPrncC9 Ch1aWiGHCdzrInLW2e0nU8iguN0KySjURoGNXQO6sDUF2+nFuv7nHiLu; Authentication-Results: rtp-dkim-2; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "'ext Dearlove, Christopher \(UK\)'" , 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Perhaps, in my mind, the most amazing thing about > this discussion is just that it is so unnecessary. The > type ordering and specific algorithms for sorting really > need to be on a per-protocol basis. That would solve the > whole problem in my mind, and the only issue raised > against that has to do with an internal parser optimization > that is wholly outside the realm of typical protocol > discussions. Agreed--putting in the packet ordering as something all protocols using packetbb MUST use is unnecessary--it should be an optional, per protocol/user thing. :-) Russ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKyxoER27sUhU9OQRAuruAJwMZUgzD/FQ/BFCvKhz6t/6d85H3ACgn/fM ojlgXuQEehrtJJqKvtSo/E0= =IrTQ -----END PGP SIGNATURE----- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 02 17:16:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io3mh-0005mG-QP; Fri, 02 Nov 2007 17:10:31 -0400 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Io3mg-0005lP-0p for manet-confirm+ok@megatron.ietf.org; Fri, 02 Nov 2007 17:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io3mf-0005iQ-NC for manet@ietf.org; Fri, 02 Nov 2007 17:10:29 -0400 Received: from rv-out-0910.google.com ([209.85.198.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io3mV-0007rl-Gz for manet@ietf.org; Fri, 02 Nov 2007 17:10:25 -0400 Received: by rv-out-0910.google.com with SMTP id l15so769749rvb for ; Fri, 02 Nov 2007 14:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=Tz9Et3swWt0tgSaldxRN+4lnP1ylkOP78E8EcPtW49M=; b=M7p+xNOvPJp2CHEIFS9TE27sgBNV+rsO0cQeNaNx6d7QfzbElOcec1XIJZMq9JP+KsGr+qpHKPmja+T5M5GyPtImPLnPP/EHmIgi/Hb6IERDY0YiJrTciz82NwIBlz4UttrT/k3XFvqyVqrKvW0XWeBHaysYfjbSfvXp8id8ddQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=MYkRmTZj/YsLYT6CqMFOnqHTZ3nJ05b5Uz5JJQLjEoWpCndbe5CEF8e5w25830Tp0UZkGOxXA9py8jELZUieMgQ+CkVHnskkTJjVZ6THPem3Nmu3ExLSozFLVEEsQXJ/d3egYD/7BP0SHQ6m1Se268F5criYVGTxvZ9s7qHgrpQ= Received: by 10.140.162.21 with SMTP id k21mr1144018rve.1194037788883; Fri, 02 Nov 2007 14:09:48 -0700 (PDT) Received: by 10.141.98.12 with HTTP; Fri, 2 Nov 2007 14:09:43 -0700 (PDT) Message-ID: <13786f330711021409uc66c573v2ab296f2fc04acf7@mail.gmail.com> Date: Fri, 2 Nov 2007 17:09:43 -0400 From: "Joseph Kopena" To: Manet Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. In-Reply-To: <200711011609.lA1G91bt026471@s2.itd.nrl.navy.mil> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4728A9F5.5040204@nokia.com> <200711011609.lA1G91bt026471@s2.itd.nrl.navy.mil> X-Google-Sender-Auth: 1609c003dda079a3 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On 11/1/07, Justin Dean wrote: > What I really have a hard time with myself is I haven't seen a compelling > example of something you couldn't do with the current TLV structure > including the restrictions. There have been some examples, which have been > discussed on this list, which were slightly smaller in size in some cases > but which were much less clear in the content which was being conveyed. I > am not saying saving bytes is not a worthwhile goal but with the current > setup there are already multiple ways to encode data and which is most > efficient depends on the data being encoded. Hi Justin, As I mentioned previously, I'm curious about the consensus encoding for a graph or two-hop neighborhood that preserves fulltype uniqueness. This may have been covered in previous examples but I haven't seen it. If so, I apologize. All I'm coming up with is either cramming multiple values into a single value or using multiple address or message blocks, so I'm curious how to represent this information in PacketBB succinctly. Thx! -- - joe kopena shelter from the storm _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Nov 04 04:15:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IobYV-0003kS-OV; Sun, 04 Nov 2007 04:14:07 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IobYU-0003j7-Jz for manet-confirm+ok@megatron.ietf.org; Sun, 04 Nov 2007 04:14:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IobYU-0003hd-7L for manet@ietf.org; Sun, 04 Nov 2007 04:14:06 -0500 Received: from rv-out-0910.google.com ([209.85.198.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IobYS-0003k1-QX for manet@ietf.org; Sun, 04 Nov 2007 04:14:06 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1066349rvb for ; Sun, 04 Nov 2007 01:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:mime-version:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender; bh=AHRWDjWatG+IU9uyHlqvnOwUsY/Pfwu4a1wwDjQy0Ls=; b=UE6Z+1z1TpNcUG0AQo/IkXBw4lNPiMAgLa4Vq500X5Kn7UmXH/3J+adTuIPN7svPsZ/SwduTaupNGuGIcRI6VBI66k3MhrjeTxuykNe2SH/VsshaSj38BVmPHi56CGewCqMExsgM8FNfDswXSlPMUHrNcTVZeADuLwmMlqoXJvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:mime-version:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender; b=EF+aUXbd/zZldVQp5BmMureLaTPQ/YNBFlcEUbIfZ4I9wnVywWeibhzBjF7hK/uRUf39B5/gmkSeXjr6f3q7Bfw+8JLCr8KhcKyEbXnM5S5MKGS47t6DCguDgjHKxSOG606anBYwS6ZcR/hFB6rA8XOIYKWON9nt5FIeTvYEVjo= Received: by 10.141.99.4 with SMTP id b4mr1766466rvm.1194166074476; Sun, 04 Nov 2007 01:47:54 -0700 (PDT) Received: from ?192.168.0.104? ( [128.97.244.30]) by mx.google.com with ESMTPS id f13sm9416399rvb.2007.11.04.01.47.50 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Nov 2007 01:47:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Giovanni Pau Date: Sun, 4 Nov 2007 16:47:44 +0800 To: manet@ietf.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Subject: [manet] Announcing: MobiView A Google-Earth like Mobility Visualization Tool for Qualnet, GPX, NMEA traces - available for Download X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear Colleagues, Gustavo and I are pleased to announce the release of MobiView, a new visualization tool, developed at the UCLA Vehicular Lab - NRL (http://www.vehicularlab.org/ ). MobiView is based on NASA WorldWind and is capable of rendering Qualnet traces on NASA landsat imagery. MobiView is part of the MobiTools suite, which is intended to aid the research community in the design and assessment of Vehicular Networks. You may download MobiView at: http://www.vehicularlab.org/software.php A technical report on the MobiTools Suite can be found at: http:// fmdb.cs.ucla.edu/Treports/mobitools-2007-main.pdf You are also invited to join the MobiTools mailing list at this page: http://nrl.cs.ucla.edu/mailman/listinfo/mobitools Finally, we wish to thank you our mentor Prof. Mario Gerla for his support. Please feel free to e-mail us for any suggestions of concerns and report any bugs. Gustavo Marfia gmarfia@cs.ucla.edu & Giovanni Pau gpau@cs.ucla.edu ======================================== "As long as I have a want, I have a reason for living. Satisfaction is death." (George Bernard Shaw) ======================================== Giovanni Pau, PhD Research Scientist UCLA - Computer Science Department 3803A BH, Boelter Hall Los Angeles, 90095 CA Ph: (310) - 206-3212 Cell: (310) - 617-4728 Fax: (310)- 825-7578 http://www.cs.ucla.edu/~gpau _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 09:44:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipm8M-0004Sh-3S; Wed, 07 Nov 2007 09:43:58 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ipm8L-0004SU-3Q for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 09:43:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipm8K-0004S8-Oe for manet@ietf.org; Wed, 07 Nov 2007 09:43:56 -0500 Received: from mho-02-bos.mailhop.org ([63.208.196.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipm8H-0003EV-9o for manet@ietf.org; Wed, 07 Nov 2007 09:43:56 -0500 Received: from aste-genev-bois-153-1-16-110.w83-112.abo.wanadoo.fr ([83.112.196.110] helo=[192.168.147.106]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Ipm8G-000K6N-PA for manet@ietf.org; Wed, 07 Nov 2007 14:43:53 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.196.110 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19U485adLNSpM4aIulnDd6p Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <2743F0F2-3273-443F-BDFB-593D7FFA54F2@thomasclausen.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: Manet From: Thomas Clausen Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. Date: Wed, 7 Nov 2007 15:43:43 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On 2Nov , 2007, at 2:55 PM, Russ White wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> Perhaps, in my mind, the most amazing thing about >> this discussion is just that it is so unnecessary. The >> type ordering and specific algorithms for sorting really >> need to be on a per-protocol basis. That would solve the >> whole problem in my mind, and the only issue raised >> against that has to do with an internal parser optimization >> that is wholly outside the realm of typical protocol >> discussions. > > Agreed--putting in the packet ordering as something all protocols > using > packetbb MUST use is unnecessary--it should be an optional, per > protocol/user thing. As has been indicated in (several) previous postings by myself and others, this won't work in that it will give all of the inconveniences and none of the benefits, considering that the MANET wg is designing multiple protocols sharing the same format. I'll not rehash the arguments yet again, but refer to previous postings by Chris and myself on this subject. Thomas -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 11:23:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpngR-0008Kz-SO; Wed, 07 Nov 2007 11:23:15 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IpngQ-0008JM-7i for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 11:23:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpngP-0008JE-T5 for manet@ietf.org; Wed, 07 Nov 2007 11:23:13 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpngP-00067K-AS for manet@ietf.org; Wed, 07 Nov 2007 11:23:13 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA7GMpVC013142; Wed, 7 Nov 2007 18:23:10 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 18:22:08 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 10:22:07 -0600 Received: from [10.162.71.187] ([10.162.71.187]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 10:22:06 -0600 Message-ID: <4731E629.3000301@nokia.com> Date: Wed, 07 Nov 2007 08:22:01 -0800 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Thomas Clausen Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. References: <2743F0F2-3273-443F-BDFB-593D7FFA54F2@thomasclausen.org> In-Reply-To: <2743F0F2-3273-443F-BDFB-593D7FFA54F2@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 16:22:07.0038 (UTC) FILETIME=[56FEEDE0:01C8215A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Thomas, You wrote: >> >> Agreed--putting in the packet ordering as something all protocols using >> packetbb MUST use is unnecessary--it should be an optional, per >> protocol/user thing. > > As has been indicated in (several) previous postings by myself and > others, this won't work in that it will give all of the inconveniences > and none of the benefits, considering that the MANET wg is designing > multiple protocols sharing the same format. I'll not rehash the > arguments yet again, but refer to previous postings by Chris and > myself on this subject. > I have read through every single mailing list message on this matter. Even though you have made this claim before, I don't find any real substantiation for it. And the counterclaim is much more compelling. To rehash (as you say) the matter, the argument for mandating the ordering is that it is claimed to be useful for some protocols, for the purpose of enabling some sort of abbreviated parsing on the receiving side. But I question even whether this is valuable, especially since the sending side then must do some unneeded work. There are several compelling arguments against this mandate. 1. Not all protocols need it (if, indeed, any at all do) 2. Such ordering isn't mandated by any other IETF protocols. 3. By the time the packet has been captured, the major portion of the cost has been expended and the additional parsing cost is negligible in the extreme. And these are just the ones I remember right off the top of my head. For a full recapitulation ("rehash"), please ask and I will do the seemingly thankless task of rehashing the rehashed arguments from months ago. None of these three points has ever been rebutted. Plus we have had several examples of good designs that would be prohibited by these restrictions. I urge you to reconsider. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 11:38:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipnun-0002Sh-9s; Wed, 07 Nov 2007 11:38:05 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ipnul-0002PN-9T for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 11:38:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipnuk-0002OZ-U0 for manet@ietf.org; Wed, 07 Nov 2007 11:38:02 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipnud-0006bp-5n for manet@ietf.org; Wed, 07 Nov 2007 11:38:02 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lA7GbN2L017447 for ; Wed, 7 Nov 2007 11:37:46 -0500 (EST) Message-Id: <200711071637.lA7GbN2L017447@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007110711374619813 for ; Wed, 07 Nov 2007 11:37:46 -0500 From: "Justin Dean" To: "'Manet'" Subject: RE: [manet] Regarding packetbb constraints on ordering and uniqueness. Date: Wed, 7 Nov 2007 11:43:10 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Acgdlav2J4o4ShqsQiGLyUdpwxycwwB/Vx0AAHHZ7YA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: X-Spam-Score: 1.5 (+) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Included in this email is my reply followed by a reply from Chris Dearlove. As for encoding a graph within packetbb. As I see it there are two main ways of using the TLV structure for conveying directed graph information. One is more efficient for sparse types of graphs and one is more efficient for dense graphs. There are other methods and Chris gets into some ideas for sending efficiently sending trees or other structured graphs. General directed dense graph: List in the address block all the nodes within the graph. To convey edge information I would design a multi value TLV which has a bit array for every address listing the outgoing edges. The bit array would have to be of length #ofaddresses rounded up to the nearest byte. The indexes of the bits within the (one address) value would match the indexes of the address block. General directed sparse graph: List in the address block all the nodes within the graph. To convey edge information I would use a TLV for each starting vertex which had a list of indexes indicating the outgoing edges. Chris describes this better in his reply. Both of these methods only use one TLV per address and convey all the information needed. There are many other ways of transmitting this information depending on how the TLV is defined some more efficient than others in different situations. Justin Dean > -----Original Message----- > From: Dearlove, Christopher (UK) > I'm not going to go into this in massive detail, but some comments > > - First, I don't actually find this to be something > that a MANET routing protocol is really going to > need. So I would regard it as sufficient to be > able to do it moderately efficiently, rather than > absolutely efficiently. (You can't make everything > maximally efficient.) There is one exception to > this, my next point. > > - More likely is to want to send a tree, rooted at the > sending node. That's done for example by TBRPF. Sending > a tree has at least one efficient encoding - use an > address block to send the addresses ordered appropriately > to a tree traversal, and use a TLV to indicate how each > relates to the previous (level change). This can be one > multi-value TLV. You may be able to find a yet better > way. > > - With regard to a general graph, I can think of at least two > reasonably efficient approaches. I'm going to assume a > directed graph. The first, and most obvious, is that we > list all the "from" node addresses in an address block, > and each gets a TLV listing the "to" addresses in what > is, in packetbb terms, a single-value TLV, that actually > contains multiple values (addresses). (See what we've > done in timetlv for comparison.) Of course we don't need > to include the full address, as we already have the > addresses listed (add in the ones only appearing as "to" > addresses) so we can just use indices. The second is to > have two address blocks, one for "from" addresses, one > for "to" addresses, both of the same length, and there > is automatically a link from the first to the first, the > second to the second, etc. This is only appropriate for > a sparse graph. (Note that there's absolutely nothing to > stop you assigning meaning to address blocks in this > way.) > > - There's a very good chance that someone who's better at > data structures than I am can find an even better solution, > using packetbb as is. > > Christopher Dearlove > > > -----Original Message----- > From: Joseph Kopena [mailto:tjkopena@cs.drexel.edu] > Sent: 02 November 2007 21:10 > To: Manet > Subject: Re: [manet] Regarding packetbb constraints on > ordering and uniqueness. > > > *** 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. > > On 11/1/07, Justin Dean wrote: > > What I really have a hard time with myself is I haven't seen a > compelling > > example of something you couldn't do with the current TLV structure > > including the restrictions. There have been some examples, > which have > been > > discussed on this list, which were slightly smaller in size in some > cases > > but which were much less clear in the content which was being > conveyed. I > > am not saying saving bytes is not a worthwhile goal but with the > current > > setup there are already multiple ways to encode data and > which is most > > efficient depends on the data being encoded. > > Hi Justin, > > As I mentioned previously, I'm curious about the consensus encoding > for a graph or two-hop neighborhood that preserves fulltype > uniqueness. This may have been covered in previous examples but I > haven't seen it. If so, I apologize. All I'm coming up with is > either cramming multiple values into a single value or using multiple > address or message blocks, so I'm curious how to represent this > information in PacketBB succinctly. > > Thx! > > -- > - joe kopena > shelter from the storm > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 12:07:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpoNK-00029D-TI; Wed, 07 Nov 2007 12:07:34 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IpoNI-000250-3P for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 12:07:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpoNH-00024o-Ni for manet@ietf.org; Wed, 07 Nov 2007 12:07:31 -0500 Received: from mho-02-bos.mailhop.org ([63.208.196.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpoNG-0007wK-U8 for manet@ietf.org; Wed, 07 Nov 2007 12:07:31 -0500 Received: from aste-genev-bois-153-1-16-110.w83-112.abo.wanadoo.fr ([83.112.196.110] helo=[192.168.147.106]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1IpoNG-000D1I-3M; Wed, 07 Nov 2007 17:07:30 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.196.110 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/N29FoTMmoyDKC36wxog8x In-Reply-To: <4731E629.3000301@nokia.com> References: <2743F0F2-3273-443F-BDFB-593D7FFA54F2@thomasclausen.org> <4731E629.3000301@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. Date: Wed, 7 Nov 2007 18:07:20 +0100 To: Charles E. Perkins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Charlie, Hope all is well in your neck of the woods? On 7Nov , 2007, at 5:22 PM, Charles E. Perkins wrote: > > Hello Thomas, > > > You wrote: >>> >>> Agreed--putting in the packet ordering as something all protocols >>> using >>> packetbb MUST use is unnecessary--it should be an optional, per >>> protocol/user thing. >> >> As has been indicated in (several) previous postings by myself and >> others, this won't work in that it will give all of the >> inconveniences and none of the benefits, considering that the >> MANET wg is designing multiple protocols sharing the same format. >> I'll not rehash the arguments yet again, but refer to previous >> postings by Chris and myself on this subject. >> > > I have read through every single mailing list message > on this matter. Even though you have made this > claim before, It is not a claim. Chris has shown in his argumentation the clear benefits in terms of processing overhead. Chris, I and others have pointed out other benefits in detail. > I don't find any real substantiation for > it. And the counterclaim is much more compelling. No, I disagree strongly. > > To rehash (as you say) the matter, the argument for > mandating the ordering is that it is claimed to be useful > for some protocols, No, you've got it wrong here. It has nothing to do with protocols and everything to do with efficiently encoding, transmitting and (uniquely and efficiently) parsing some information. The I-D in question does not specify how information is generated nor processed.....THAT is what the protocols shall do, and that is what they are free to do in whichever order is appropriate. > for the purpose of enabling some > sort of abbreviated parsing on the receiving side. ....that is one of the benefits, yes, although I believe that striving for (and, indeed, in the specification as it is, achieving) linear parsing by a receiving node can not be said to be a bad goal, can it? As you will have seen in previous emails, there are other benefits beyond this. > But I question even whether this is valuable, especially > since the sending side then must do some unneeded > work. If I have the choice, I'd rather have the sending node do some extra work, if that means that the recipient is able to do something more efficient. I'd argue that there are benefits in that, since I suspect that most nodes will receive more incoming messages than the generate themselves. E.g. in a classic link-state protocol, each node will for each message it generates, receive (ignoring duplicate, which makes it even more compelling) n messages in a n+1 nodes large network. So optimising the message content for the receiver seems sensible. So I would argue that this is, indeed, very valuable and that the sending side does very much needed work that has an overall benefit for the network. > There are several compelling arguments against this > mandate. > 1. Not all protocols need it (if, indeed, any at all do) Again, it has nothing to do with protocols and everything to do with efficiently and uniquely encoding, transmitting and parsing information....parsing happening before the encoded and transmitted information is handed off to the protocol. > 2. Such ordering isn't mandated by any other IETF protocols. I don't think that's a valid argument here: the reason may be that in packetbb, there's the two-dimensional (in lack of better terms) aspect of address-block TLVs which is slightly different from other TLV-based protocols out there (and, I add, is different for the purpose of efficient encoding....) -- which necessitates this treatment to be efficient. > 3. By the time the packet has been captured, the > major portion of the cost has been expended and the > additional parsing cost is negligible in the extreme. That's an one-sided assertion. You do have a specific environment in mind where this may be true. I have a different environment in mind where this cost is not negligible at all. I shall add that the constraints were something that I had to be "talked into" initially from people actually building/running OLSRv2, and for whom the costs were everything but negligible. I could add something about the fact that eliminating the per-message- processing-overhead for the receiver has some benefits wrt. DoS also, but I think it suffice to say that I fail to see the argument for making something more costly, when we know how to make it less costly. As an academic, I'll just stick to my send-1-message-process-n- messages example from above as an argument in favour of reducing per- message-processing-overhead, since I believe that it illustrates a point quite nicely. > And these are just the ones I remember right off the > top of my head. For a full recapitulation ("rehash"), > please ask and I will do the seemingly thankless task > of rehashing the rehashed arguments from months ago. > None of these three points has ever been rebutted. > As far as I am concerned, these points have all been addressed and the benefit of retaining the constraint on uniqueness and ordering remain clear. I'd take it that you do not dispute the brief example given previously in this email. > Plus we have had several examples of good designs > that would be prohibited by these restrictions. I disagree. I'll first say that the design examples presented have been hypothetical. Second, the designs examples could equally well be accomplished with the current design of packetbb. So, as such, I do not see that anything has been prohibited. > I urge you to reconsider. > As I see it, there are a great number of benefits to retaining the current design of packetbb as it is (and these benefits have been enumerated elsewhere), and I have seen no compelling benefits presented of altering the design. In particularly not since the alterations proposed incur large penalties in terms of parsing ambiguity and parsing overhead at the receiver. Hence, while I continue to reconsider my position and technical opinion on any matter I am involved in, I do not believe that the constraints on ordering and uniqueness for TLVs in packetbb should be altered since the benefits of doing so are questionable, while the drawbacks considerable. As has been previously pointed out in emails from myself and others. Cheers, Thomas -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 12:49:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipp1d-0002RQ-S3; Wed, 07 Nov 2007 12:49:13 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ipp1c-0002Pd-Kf for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 12:49:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipp1c-0002PO-A7 for manet@ietf.org; Wed, 07 Nov 2007 12:49:12 -0500 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipp1a-0001sA-0Y for manet@ietf.org; Wed, 07 Nov 2007 12:49:12 -0500 Received: by ug-out-1314.google.com with SMTP id u2so563661uge for ; Wed, 07 Nov 2007 09:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=pXTV50cWbp7NEgwmH8P4j33KbtziTsfuAvugo5gQUx0=; b=PfXG53uK6nGj+s+XGsRfnMIgeWz35zB31vbsxvGfGbJK/RPyxevPqT8g+tXWa79X2zldHIcp1JZXwAzj6e4lKZ4s+CIGDFRRTIx68760wy+41mcgeqYsrPHiwUIP7Gx4EShlTZYnvJpO1M+3zIF4vg3PnoAlrHak6Q4TM/EFwOE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=o2vdvPwHCwZx3+kmrQls7vg/+CTIF3LZTuaJwgS4S1KWh2nD1l84t7Icr0IDvyIX7FpVJsKPqZKk2s23qlksD75VMgvcULMbk2UXUDBySRYK+cNQ5ToQE/mA0zYjjZTcFaJT+WZcGQT4jgXTs68B18ZuHBWJKr49BZue2g5nKlw= Received: by 10.78.131.8 with SMTP id e8mr6334168hud.1194457747923; Wed, 07 Nov 2007 09:49:07 -0800 (PST) Received: by 10.78.19.9 with HTTP; Wed, 7 Nov 2007 09:49:07 -0800 (PST) Message-ID: <374005f30711070949i620d3adeo116ea3d4cb64a203@mail.gmail.com> Date: Wed, 7 Nov 2007 23:19:07 +0530 From: "Ian Chakeres" To: manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Christopher Dearlove , Cedric Adjih , "Thomas Heide Clausen \(work\)" Subject: [manet] draft-ietf-manet-packetbb - WGLC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org This note announces the WG Last Call for comments on draft-ietf-manet-packetbb-10.txt, "Generalized MANET Packet/Message Format". The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-10.txt The document is intended to be submitted for publication as a proposed standard document. Please review the document carefully and send your comments to the MANET list and document authors. Given the relatively minor recent changes (added version. added packet size. added special IANA alloc for TLV types 0 to 7.), this last call will end Wed Nov 14th AOE. Thanks, Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 13:26:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ippbw-0001Q6-2M; Wed, 07 Nov 2007 13:26:44 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ippbt-0001Mm-73 for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 13:26:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ippbs-0001Me-Tk for manet@ietf.org; Wed, 07 Nov 2007 13:26:40 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ippbp-0003Z6-AB for manet@ietf.org; Wed, 07 Nov 2007 13:26:40 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA7IQBMO024783; Wed, 7 Nov 2007 20:26:34 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 20:25:53 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 12:25:42 -0600 Received: from [10.162.71.187] ([10.162.71.187]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 12:25:41 -0600 Message-ID: <4732031F.7010103@nokia.com> Date: Wed, 07 Nov 2007 10:25:35 -0800 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Thomas Clausen Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. References: <2743F0F2-3273-443F-BDFB-593D7FFA54F2@thomasclausen.org> <4731E629.3000301@nokia.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 18:25:42.0354 (UTC) FILETIME=[9ADE5B20:01C8216B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Thomas, I'll try to answer your comments here. ext Thomas Clausen wrote: > > It is not a claim. Chris has shown in his argumentation the clear > benefits in terms of processing overhead. Chris, I and others have > pointed out other benefits in detail. I strongly disagree that Chris has shown this. If you will (perhaps in private email) direct me to his strongest argument, I will take another look. Right now, I only remember what seemed to me very vague and unsubstantiated assertions about the way someone's current parser had been written. > > >> >> To rehash (as you say) the matter, the argument for >> mandating the ordering is that it is claimed to be useful >> for some protocols, > > No, you've got it wrong here. It has nothing to do with protocols and > everything to do with efficiently encoding, transmitting and (uniquely > and efficiently) parsing some information. The I-D in question does > not specify how information is generated nor processed.....THAT is > what the protocols shall do, and that is what they are free to do in > whichever order is appropriate. Yes, you are right that I was thinking about the protocols. So since this mandate has nothing to do with protocols, I very strongly believe it should be omitted from the protocol specification. But wait! packetbb is not a protocol specification. No, it is a meta-protocol specification. Thus, the parsing-related mandate is _TWO_ steps removed from appropriateness for inclusion in this document. > >> for the purpose of enabling some >> sort of abbreviated parsing on the receiving side. > > ....that is one of the benefits, yes, although I believe that striving > for (and, indeed, in the specification as it is, achieving) linear > parsing by a receiving node can not be said to be a bad goal, can it? > As you will have seen in previous emails, there are other benefits > beyond this. I am thinking about the quick-abort feature... which I have argued is at least questionable if not downright anti-IETF in flavor. > > >> But I question even whether this is valuable, especially >> since the sending side then must do some unneeded >> work. > > If I have the choice, I'd rather have the sending node do some extra > work, if that means that the recipient is able to do something more > efficient. This is, then, according to your personal taste. However, it does not stand up to logical scrutiny. Here is another formulation to expose what I claim is the fallacy. 1. The receiver wants to make sure of some uniqueness (we don't know why, no general argument was given, only that the authors favor the variable-assignment paradigm). 2. Thus, the sender has to work harder to insure that the receiver can make this check. First, I point out that a protocol could RECOMMEND that the sender implement the ordering. Second, absolutely no malicious behavior is prevented by this mandate. Thus, there are absolutely no efficiency gains evident so far. > I'd argue that there are benefits in that, since I suspect that most > nodes will receive more incoming messages than the generate > themselves. E.g. in a classic link-state protocol, each node will for > each message it generates, receive (ignoring duplicate, which makes it > even more compelling) n messages in a n+1 nodes large network. So > optimising the message content for the receiver seems sensible. It's even better to avoid making the check entirely. And I don't see any downside to the more generous behavior, except for possibly adding another sentence of text to whatever protocol specification seems to have a need for this exclusivity and sorting. > > > So I would argue that this is, indeed, very valuable and that the > sending side does very much needed work that has an overall benefit > for the network. First, let's hope that most networks are not dominated by the kind of one-to-many flooding that seems to be motivating this specification. Second, you _could_ make it for the particular protocol. Third, as pointed out above, the gain in efficiency is really illusory. I think it is really just a gain in mental satisfaction that some packet universe might somehow be more organized. > >> There are several compelling arguments against this >> mandate. >> 1. Not all protocols need it (if, indeed, any at all do) > > Again, it has nothing to do with protocols and everything to do with > efficiently and uniquely encoding, transmitting and parsing > information....parsing happening before the encoded and transmitted > information is handed off to the protocol. Again, if it has nothing to do with protocols, then it just does not belong in the specification. And, the unique encoding is _only_ of interest to fit Justin's model of TLVs as a sort of variable assignment mechanism. TLVs do not have to fit that restrictive model. > >> 2. Such ordering isn't mandated by any other IETF protocols. > > I don't think that's a valid argument here: the reason may be that in > packetbb, there's the two-dimensional (in lack of better terms) aspect > of address-block TLVs which is slightly different from other TLV-based > protocols out there (and, I add, is different for the purpose of > efficient encoding....) -- which necessitates this treatment to be > efficient. Sorry, Thomas, this makes very little sense to me. The variable-assignment model is just not right for many cases. And I cannot yet identify the coordinate axes that would enable me to define some two-dimensional understanding of what you're talking about. Perhaps you meant that the TLV ordering structure is an array of intervals. Then one axis would be [dimensionality on the order of 0.5*(address range^2)]. What would the other axis be? The scalar value for the value to be assigned? Anyway this is a very poor basis for discussing any sort of ordering mandate... > >> 3. By the time the packet has been captured, the >> major portion of the cost has been expended and the >> additional parsing cost is negligible in the extreme. > > That's an one-sided assertion. I think it is quite easy to see in practice. Calculate the energy expenditure from the radio interface, and compare it to the expenditure from reading a string into memory. Calculate the time spent from the bandwidth delay and compare it to the CPU time expenditure by a processing unit made in the last 50 years. You can get a lot of martinis from me if you find that the processing side is anywhere near similar. > You do have a specific environment in mind where this may be true. I > have a different environment in mind where this cost is not negligible > at all. Please do tell! > I shall add that the constraints were something that I had to be > "talked into" initially from people actually building/running OLSRv2, > and for whom the costs were everything but negligible. Any documentation you can share?? But then why isn't this in the OLSRv2 specification instead of packetBB? I really am very skeptical about this. > > I could add something about the fact that eliminating the > per-message-processing-overhead for the receiver has some benefits > wrt. DoS also, but I think it suffice to say that I fail to see the > argument for making something more costly, when we know how to make it > less costly. I very much claim that eliminating the mandate is less costly. There is absolutely no resilience against DoS provided by making this mandate. > > As an academic, I'll just stick to my > send-1-message-process-n-messages example from above as an argument in > favour of reducing per-message-processing-overhead, since I believe > that it illustrates a point quite nicely. Is packetBB intended only for one-to-many protocol processing? Besides that, there just isn't any advantage. At most, your argument seems to mean that the parser can avoid allocating a few most slots for storing the TLV structure data and avoid a subroutine call for the higher-level protocol processing. And for this we are going to pay through the nose by having all of these protocol restrictions and additional parsing steps for protocols that have zero use for the restrictions? I am definitely not seeing it. > >> And these are just the ones I remember right off the >> top of my head. For a full recapitulation ("rehash"), >> please ask and I will do the seemingly thankless task >> of rehashing the rehashed arguments from months ago. >> None of these three points has ever been rebutted. >> > > As far as I am concerned, these points have all been addressed and the > benefit of retaining the constraint on uniqueness and ordering remain > clear. I'd take it that you do not dispute the brief example given > previously in this email. I hope my counterargument for your rebuttal will be of some interest. > >> Plus we have had several examples of good designs >> that would be prohibited by these restrictions. > > I disagree. Gee thanks... I guess you mean that my design is not good, sigh. > I'll first say that the design examples presented have been hypothetical. Well, if it exists in protocol specification, simulation, and code is it still hypothetical? > Second, the designs examples could equally well be accomplished with > the current design of packetbb. Not without drastic packet-size enlargement. In fact, one could do ANYTHING in the variable-assignment model of operation, thusly: - identify all desired multi-sets of values by way of indices from the range [1, googolplex]. - distribute the per-TLV databases to all nodes - use an index to identify the appropriate multiset of values within the packetBB-parsable TLV. I do not think this is a viable model of operation in today's world. > As I see it, there are a great number of benefits to retaining the > current design of packetbb as it is (and these benefits have been > enumerated elsewhere), I am still not seeing it, Thomas. The efficiency gains are either very small or else not even there at all. > and I have seen no compelling benefits presented of altering the > design. In particularly not since the alterations proposed incur large > penalties in terms of parsing ambiguity and parsing overhead at the > receiver. I think that you have unfairly dismissed the non-IETFness of this restriction and exaggerated the occasional benefits by perhaps several orders of magnitude, while dismissing the corresponding costs by pointing out that they are not to your taste. Even aside from the questionable nature of the benefits themselves, I can find nothing in your response that indicates the need for their universal application to all future packetBB protocols. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 14:16:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqO9-00075Z-Og; Wed, 07 Nov 2007 14:16:33 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IpqO7-00074y-Dd for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 14:16:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqO7-00074q-3J for manet@ietf.org; Wed, 07 Nov 2007 14:16:31 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpqO6-0004uQ-IQ for manet@ietf.org; Wed, 07 Nov 2007 14:16:31 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA7JG8Lb011738; Wed, 7 Nov 2007 21:16:27 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 21:16:24 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 13:16:22 -0600 Received: from [10.162.71.187] ([10.162.71.187]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 13:16:22 -0600 Message-ID: <47320F01.7020208@nokia.com> Date: Wed, 07 Nov 2007 11:16:17 -0800 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Ian Chakeres Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <374005f30711070949i620d3adeo116ea3d4cb64a203@mail.gmail.com> In-Reply-To: <374005f30711070949i620d3adeo116ea3d4cb64a203@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 19:16:22.0757 (UTC) FILETIME=[AF170950:01C82172] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Ian, I think that the document is not ready for publication until the mandates for uniqueness and ordering of address TLVs are softened to MAY. Text should be added to indicate that individual protocols that conform to packetBB can mandate the use need for this feature if so desired. Regards, Charlie P. ext Ian Chakeres wrote: > This note announces the WG Last Call for comments on > draft-ietf-manet-packetbb-10.txt, "Generalized MANET Packet/Message > Format". > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-10.txt > > The document is intended to be submitted for publication as a proposed > standard document. > > Please review the document carefully and send your comments to the > MANET list and document authors. > > Given the relatively minor recent changes (added version. added packet > size. added special IANA alloc for TLV types 0 to 7.), this last call > will end Wed Nov 14th AOE. > > Thanks, > Ian Chakeres > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 14:26:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqXM-00019K-Os; Wed, 07 Nov 2007 14:26:04 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IpqXL-00016S-BX for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 14:26:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqXL-00016F-0S for manet@ietf.org; Wed, 07 Nov 2007 14:26:03 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpqXK-0005Mg-LH for manet@ietf.org; Wed, 07 Nov 2007 14:26:02 -0500 X-IronPort-AV: E=Sophos;i="4.21,386,1188792000"; d="scan'208";a="75400150" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2007 14:26:02 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA7JQ20i011350; Wed, 7 Nov 2007 14:26:02 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA7JPrda027722; Wed, 7 Nov 2007 19:26:02 GMT Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 14:25:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] draft-ietf-manet-packetbb - WGLC Date: Wed, 7 Nov 2007 14:25:57 -0500 Message-ID: <7FB7EE0A621BA44B8B69E5F0A09DC76404E7856E@xmb-rtp-208.amer.cisco.com> In-Reply-To: <47320F01.7020208@nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] draft-ietf-manet-packetbb - WGLC Thread-Index: AcghcrlqEDM4Z7/bTJ688m5tZCZ31gAAT3Yg From: "Stan Ratliff (sratliff)" To: "Charles E. Perkins" , "ext Ian Chakeres" X-OriginalArrivalTime: 07 Nov 2007 19:25:59.0385 (UTC) FILETIME=[06C97C90:01C82174] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002 X-TM-AS-Result: No--21.312400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1682; t=1194463562; x=1195327562; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sratliff@cisco.com; z=From:=20=22Stan=20Ratliff=20(sratliff)=22=20 |Subject:=20RE=3A=20[manet]=20draft-ietf-manet-packetbb=20-=20WGLC |Sender:=20 |To:=20=22Charles=20E.=20Perkins=22=20, =0A=20= 20=20=20=20=20=20=20=22ext=20Ian=20Chakeres=22=20; bh=R7QdztuGs7ollVMDVAtJFW+ciF8ER5QCzCx1pkZNTaA=; b=hkVQXYRo5+0pcCnHGDdSnOfK03PbZ9oiDBvgZ5WkJTcIh/+/NFHkjzFsUq/vtpJVq1ZHlRPY qx4mBdjITTSxvDUz8dTISgpxZgTqtdwxB65iKE0HrFrs0mp18bssW77j; Authentication-Results: rtp-dkim-1; header.From=sratliff@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian,=20 I agree with Charlie's recommendation.=20 Regards, Stan =20 >-----Original Message----- >From: Charles E. Perkins [mailto:charles.perkins@nokia.com]=20 >Sent: Wednesday, November 07, 2007 2:16 PM >To: ext Ian Chakeres >Cc: manet >Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC > > >Hello Ian, > >I think that the document is not ready for publication until the >mandates for uniqueness and ordering of address TLVs are >softened to MAY. Text should be added to indicate that >individual protocols that conform to packetBB can mandate >the use need for this feature if so desired. > >Regards, >Charlie P. > > >ext Ian Chakeres wrote: >> This note announces the WG Last Call for comments on >> draft-ietf-manet-packetbb-10.txt, "Generalized MANET Packet/Message >> Format". >> >> The document can be found at: >> http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-10.txt >> >> The document is intended to be submitted for publication as=20 >a proposed >> standard document. >> >> Please review the document carefully and send your comments to the >> MANET list and document authors. >> >> Given the relatively minor recent changes (added version.=20 >added packet >> size. added special IANA alloc for TLV types 0 to 7.), this last call >> will end Wed Nov 14th AOE. >> >> Thanks, >> Ian Chakeres >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> =20 > > > >_______________________________________________ >manet mailing list >manet@ietf.org >https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 14:38:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqjF-00063N-11; Wed, 07 Nov 2007 14:38:21 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IpqjC-0005xk-Lm for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 14:38:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqjC-0005vq-7C for manet@ietf.org; Wed, 07 Nov 2007 14:38:18 -0500 Received: from mho-02-bos.mailhop.org ([63.208.196.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipqj8-0006X0-AJ for manet@ietf.org; Wed, 07 Nov 2007 14:38:18 -0500 Received: from aste-genev-bois-153-1-16-110.w83-112.abo.wanadoo.fr ([83.112.196.110] helo=[192.168.147.106]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Ipqj7-0009vG-5m; Wed, 07 Nov 2007 19:38:13 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.196.110 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+xiNDKpBnpWP+rX6MTXG+H In-Reply-To: <4732031F.7010103@nokia.com> References: <2743F0F2-3273-443F-BDFB-593D7FFA54F2@thomasclausen.org> <4731E629.3000301@nokia.com> <4732031F.7010103@nokia.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E82E368-FF55-4831-8046-F77FD35B7F28@thomasclausen.org> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. Date: Wed, 7 Nov 2007 20:38:03 +0100 To: Charles E. Perkins X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8da0cbf8c1eef8eab03772f2044efec0 Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Charlie, Comments below. On 7Nov , 2007, at 7:25 PM, Charles E. Perkins wrote: > > Hello Thomas, > > I'll try to answer your comments here. > > ext Thomas Clausen wrote: >> >> It is not a claim. Chris has shown in his argumentation the clear >> benefits in terms of processing overhead. Chris, I and others have >> pointed out other benefits in detail. > > I strongly disagree that Chris has shown this. > If you will (perhaps in private email) direct me > to his strongest argument, I will take another > look. Right now, I only remember what seemed > to me very vague and unsubstantiated assertions > about the way someone's current parser had been > written. I remember Chris had a well-phrased argument to this effect in a previous email. I am sure that it is in the archives. >> >> >>> >>> To rehash (as you say) the matter, the argument for >>> mandating the ordering is that it is claimed to be useful >>> for some protocols, >> >> No, you've got it wrong here. It has nothing to do with protocols >> and everything to do with efficiently encoding, transmitting and >> (uniquely and efficiently) parsing some information. The I-D in >> question does not specify how information is generated nor >> processed.....THAT is what the protocols shall do, and that is >> what they are free to do in whichever order is appropriate. > > Yes, you are right that I was thinking about the protocols. > So since this mandate has nothing to do with protocols, > I very strongly believe it should be omitted from the protocol > specification. But wait! packetbb is not a protocol specification. > No, it is a meta-protocol specification. Thus, the parsing-related > mandate is _TWO_ steps removed from appropriateness for > inclusion in this document. I'll try again, then, since it's apparently not yet clear: o packetbb is defining an encoding for exchanging information relevant to a specific problem-domain; o this encoding is made such that this information is transmitted in a way that allows efficient and unique decoding; o subsequent to the decoding, an unique data structure results; o this data structure can be used in a way which is to be specified by a protocol specification. The first 3 is the domain of packetbb -- the last (using the decoded data structure) is the domain of a protocol specification. I do not understand what is meant by "meta-protocol" and the like in your paragraph above -- however as has been explained many times over, the constraints serve to ensure that the encoding can be parsed into unique data structures (and that two nodes receiving the same encoded information will be able to, despite being two different implementations, decode identical data structures) linearly. >> >>> for the purpose of enabling some >>> sort of abbreviated parsing on the receiving side. >> >> ....that is one of the benefits, yes, although I believe that >> striving for (and, indeed, in the specification as it is, >> achieving) linear parsing by a receiving node can not be said to >> be a bad goal, can it? As you will have seen in previous emails, >> there are other benefits beyond this. > I am thinking about the quick-abort feature... which I have > argued is at least questionable if not downright anti-IETF in > flavor. Quick-abort is one, minor, benefit of this encoding. However if you consult previous emails, you will note that the efficiency goes beyond "quick-abort" and has to do with the complexity of the parsing algorithm. >>> But I question even whether this is valuable, especially >>> since the sending side then must do some unneeded >>> work. >> >> If I have the choice, I'd rather have the sending node do some >> extra work, if that means that the recipient is able to do >> something more efficient. > This is, then, according to your personal taste. Not at all. I believe that the example I provided gives ample justification for why a low parsing-overhead is beneficial, and why a little extra effort on the sending side to achieve a gain on the receiver is desirable. I am of the understanding that a low per- packet-parsing-overhead is generally favoured. > However, it does > not stand up to logical scrutiny. > I disagree. > Here is another formulation to expose what I claim is the fallacy. > > 1. The receiver wants to make sure of some uniqueness (we don't > know why, no general argument was given, only that the > authors favor the variable-assignment paradigm). No, Charlie, ample arguments have been given in previous emails as to why this is beneficial. > 2. Thus, the sender has to work harder to insure that the receiver > can make this check. No, the sender has to ensure that the encoding is done as specified, whereby the recipient can parse it linearly. I thought you were agnostic to the cost of "processing"? You argue that processing by the receiver is insignificant, in which case processing by the sender is even MORE insignificant -- and thus, I do not understand why processing in the sender suddenly is important? Recall my simple flooding-example? Each node will send 1 packet but receive n, in a n+1 large network. Hence, if processing-time is insignificant to you, and you are willing to add extraneous overhead in n nodes, why is it not better to add a little overhead in the one node (the one that sends) against a saving of extraneous overhead in the n nodes that receive? Sorry, Charlie, but that does -- to reuse your phrase -- "not stand up to logical scrutiny". > First, I point out that a protocol could RECOMMEND that > the sender implement the ordering. No, not at all since that no longer becomes something that can be done at parse-time, but at a higher level -- which means that the work (without the constraint, now no longer doable in O(n)) of parsing already has been done. So this will clearly lead to inefficiencies. Secondly, you are ignoring the points made regarding the MANET wg doing multiple protocols and genericity (is that a word?) of parsing. > Second, absolutely no > malicious behavior is prevented by this mandate. > No, but the impact of malicious behavior as part of a DoS attack is lower the lower the per-packet-parsing-overhead is. That was kind of my point. > Thus, there are absolutely no efficiency gains evident so far. > Other than that parsing can be done linearly in n nodes, of course..... > >> I'd argue that there are benefits in that, since I suspect that >> most nodes will receive more incoming messages than the generate >> themselves. E.g. in a classic link-state protocol, each node will >> for each message it generates, receive (ignoring duplicate, which >> makes it even more compelling) n messages in a n+1 nodes large >> network. So optimising the message content for the receiver seems >> sensible. > It's even better to avoid making the check entirely. And I don't see > any downside to the more generous behavior, except for possibly > adding another sentence of text to whatever protocol specification > seems to have a need for this exclusivity and sorting. And the fact that the parsing can no longer: - be generic, regardless of which protocol uses packetbb - be linear without backtracking, - ensure that the resulting data structure is unique, specifically - that two implementations will result in the same data structure given the same input Of course, I consider the above to be important, especially when no expressiveness is lost in doing so. >> >> >> So I would argue that this is, indeed, very valuable and that the >> sending side does very much needed work that has an overall >> benefit for the network. > > First, let's hope that most networks are not dominated by the > kind of one-to-many flooding that seems to be motivating this > specification. So what you are saying is that you hope that networks are not dominated by protocols which, say, specify that a node (a source for a traffic flow) issue a request to discover the network topology (say, a Route Request), with this Route Request being flooded throughout the network....? Since in that case, one node generates a message, which is being retransmitted by n nodes in our n+1 large network..... > Second, you _could_ make it for the particular > protocol. No, see the four benefits listed above.... > Third, as pointed out above, the gain in efficiency > is really illusory. I think it is really just a gain in mental > satisfaction > that some packet universe might somehow be more organized. No, not at all. >> >>> There are several compelling arguments against this >>> mandate. >>> 1. Not all protocols need it (if, indeed, any at all do) >> >> Again, it has nothing to do with protocols and everything to do >> with efficiently and uniquely encoding, transmitting and parsing >> information....parsing happening before the encoded and >> transmitted information is handed off to the protocol. > > Again, if it has nothing to do with protocols, then it just does > not belong in the specification. Yes, it belongs in the packetbb specification -- it does NOT belong in a protocol specification using packetbb since this is already *in* packetbb. > And, the unique encoding > is _only_ of interest to fit Justin's model of TLVs as a sort > of variable assignment mechanism. TLVs do not have to > fit that restrictive model. >> >>> 2. Such ordering isn't mandated by any other IETF protocols. >> >> I don't think that's a valid argument here: the reason may be that >> in packetbb, there's the two-dimensional (in lack of better terms) >> aspect of address-block TLVs which is slightly different from >> other TLV-based protocols out there (and, I add, is different for >> the purpose of efficient encoding....) -- which necessitates this >> treatment to be efficient. > > Sorry, Thomas, this makes very little sense to me. The > variable-assignment model is just not right for many cases. > And I cannot yet identify the coordinate axes that would > enable me to define some two-dimensional understanding > of what you're talking about. Perhaps you meant that > the TLV ordering structure is an array of intervals. > Then one axis would be > [dimensionality on the order of 0.5*(address range^2)]. > What would the other axis be? The scalar value for the > value to be assigned? > > Anyway this is a very poor basis for discussing any sort > of ordering mandate... Read the packetbb I-D, and note the difference between packet/message TLVs and address-block TLVs. It should be fairly obvious what I am hinting to. Also note that I said "in lack of better terms" in my comment above. But, it should be fairly obvious why the TLVs are as they are if you read the I-D. >> >>> 3. By the time the packet has been captured, the >>> major portion of the cost has been expended and the >>> additional parsing cost is negligible in the extreme. >> >> That's an one-sided assertion. > I think it is quite easy to see in practice. Calculate the energy > expenditure from the radio interface, and compare it to the > expenditure from reading a string into memory. Calculate the > time spent from the bandwidth delay and compare it to the > CPU time expenditure by a processing unit made in the last > 50 years. You can get a lot of martinis from me if you find > that the processing side is anywhere near similar. Therein our differences: you have an a-priori of having infinite computational/storage capacity and limited power. I am saying that sometimes you have limited computational/storage capacity AND limited power. >> You do have a specific environment in mind where this may be true. >> I have a different environment in mind where this cost is not >> negligible at all. > Please do tell! > Done above. >> I shall add that the constraints were something that I had to be >> "talked into" initially from people actually building/running >> OLSRv2, and for whom the costs were everything but negligible. > > Any documentation you can share?? > Was discussed at Paris and subsequent IETFs -- I believe that you were party to that a long night in Vancouver too. > But then why isn't this in the OLSRv2 specification > instead of packetBB? > Because it belongs in packetbb for the reasons given above and by Chris, Justin, myself and others in other emails. > I really am very skeptical about this. > >> >> I could add something about the fact that eliminating the per- >> message-processing-overhead for the receiver has some benefits >> wrt. DoS also, but I think it suffice to say that I fail to see >> the argument for making something more costly, when we know how to >> make it less costly. > > I very much claim that eliminating the mandate is less costly. > We disagree. > There is absolutely no resilience against DoS > provided by making this mandate. > >> >> As an academic, I'll just stick to my send-1-message-process-n- >> messages example from above as an argument in favour of reducing >> per-message-processing-overhead, since I believe that it >> illustrates a point quite nicely. > > Is packetBB intended only for one-to-many protocol processing? > No, it is intended for many things -- but since in AODV/DYMO/OLSR/ OLSRv2 this seems to be a common scenario, packetbb is designed to also be efficient for that. > Besides that, there just isn't any advantage. We disagree > At most, your > argument seems to mean that the parser can avoid allocating > a few most slots for storing the TLV structure data and avoid > a subroutine call for the higher-level protocol processing. No, that is not what I say. It is a very very small part of the argument. > And for this we are going to pay through the nose by having > all of these protocol restrictions and additional parsing steps > for protocols that have zero use for the restrictions? Protocols can impose their own restrictions. Packetbb is concerned with the encoding as is transmitted over the wire -- not with how protocols process the data structure constructed from successful parsing of a message. There are, therefore, nothing to "pay", no "restrictions", no "additional parsing steps| for protocols. I think that it would be beneficial to re-read the email that I wrote a while ago in which I discussed encoding/parsing/processing in greater details, since I feel that you have a misunderstanding on that front. > > I am definitely not seeing it. See above. > >> >>> And these are just the ones I remember right off the >>> top of my head. For a full recapitulation ("rehash"), >>> please ask and I will do the seemingly thankless task >>> of rehashing the rehashed arguments from months ago. >>> None of these three points has ever been rebutted. >>> >> >> As far as I am concerned, these points have all been addressed and >> the benefit of retaining the constraint on uniqueness and ordering >> remain clear. I'd take it that you do not dispute the brief >> example given previously in this email. > > I hope my counterargument for your rebuttal will > be of some interest. I suspect that you have misunderstood the purpose of packetbb. Any constraints in there are only on how information is encoded, in order to ensure efficiency, genericity and unambiguity -- NOT on how a protocol can use it. >> >>> Plus we have had several examples of good designs >>> that would be prohibited by these restrictions. >> >> I disagree. > > Gee thanks... I guess you mean that my design is not good, sigh. >> I'll first say that the design examples presented have been >> hypothetical. > > Well, if it exists in protocol specification, simulation, and code > is it > still hypothetical? > >> Second, the designs examples could equally well be accomplished >> with the current design of packetbb. > > Not without drastic packet-size enlargement. > > In fact, one could do ANYTHING in the variable-assignment > model of operation, thusly: > - identify all desired multi-sets of values by way of indices > from the range [1, googolplex]. > - distribute the per-TLV databases to all nodes > - use an index to identify the appropriate multiset of values > within the packetBB-parsable TLV. > > I do not think this is a viable model of operation in today's world. > I suspect that you have misunderstood the purpose of packetbb. Any constraints in there are only on how information is encoded, in order to ensure efficiency, genericity and unambiguity -- NOT on how a protocol can use it. > >> As I see it, there are a great number of benefits to retaining the >> current design of packetbb as it is (and these benefits have been >> enumerated elsewhere), > I am still not seeing it, Thomas. The efficiency gains > are either very small or else not even there at all. I refer to my previous example, and respectfully disagree. >> and I have seen no compelling benefits presented of altering the >> design. In particularly not since the alterations proposed incur >> large penalties in terms of parsing ambiguity and parsing overhead >> at the receiver. > > I think that you have unfairly dismissed the > non-IETFness of this restriction and exaggerated > the occasional benefits by perhaps several orders > of magnitude, while dismissing the corresponding > costs by pointing out that they are not to your taste. > > Even aside from the questionable nature of the benefits > themselves, Sorry, Charlie, I will not entertain discussions which call on arguments such as "non-IETFness" or "dismissing based on taste". I further recent that you label my arguments as "occasional benefits" and of "questionable nature" when I present you with a common example (a flooding.....which happens in AODV/OLSR/OLSRv2/DYMO all the time) and point to the balance between in such a case having a (processing) overhead in one node vs. in n nodes. This is a technical argument and a very common scenario -- so common, in fact, that all MANET wg protocols do it....and yet you counter-argument is: > Let's hope that most networks are not dominated by the > kind of one-to-many flooding that seems to be motivating this > specification. I would like to suggest that we return this discussion to sober and technical matters with technical arguments, least I see no point in continuing? > I can find nothing in your response that > indicates the need for their universal application to all > future packetBB protocols. I suspect that you have misunderstood the purpose of packetbb. Any constraints in there are only on how information is encoded, in order to ensure efficiency, genericity and unambiguity -- NOT on how a protocol can use it. The benefits are outlined above, in this and in many other emails from myself and from others. Thomas -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 14:41:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqmV-00014e-TT; Wed, 07 Nov 2007 14:41:43 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IpqmT-00012I-N2 for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 14:41:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqmT-000123-Cw for manet@ietf.org; Wed, 07 Nov 2007 14:41:41 -0500 Received: from mho-02-bos.mailhop.org ([63.208.196.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpqmQ-0006hZ-5g for manet@ietf.org; Wed, 07 Nov 2007 14:41:41 -0500 Received: from aste-genev-bois-153-1-16-110.w83-112.abo.wanadoo.fr ([83.112.196.110] helo=[192.168.147.106]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1IpqmO-000B3C-Sj; Wed, 07 Nov 2007 19:41:37 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.196.110 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18bd47oxR4C6k2SYbUyWmXj In-Reply-To: <7FB7EE0A621BA44B8B69E5F0A09DC76404E7856E@xmb-rtp-208.amer.cisco.com> References: <7FB7EE0A621BA44B8B69E5F0A09DC76404E7856E@xmb-rtp-208.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <548143B0-4F31-4921-A29E-E119B868153D@thomasclausen.org> Content-Transfer-Encoding: 7bit From: Thomas Clausen Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC Date: Wed, 7 Nov 2007 20:41:27 +0100 To: "Stan Ratliff (sratliff)" X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian, I suggest that the arguments presented for changing the mandates from MUST to MAY have been insufficient, and that the consequences of doing so have not been fully considered by the proponents of this change. I furthermore note that the current mandates in packetbb in no way is limiting the applicability within the intended problem domain of MANET protocols, and that therefore -- given the benefits which have been presented elsewhere -- it is timely to move forward with this I- D towards publication. Regards, Thomas On 7Nov , 2007, at 8:25 PM, Stan Ratliff (sratliff) wrote: > Ian, > > I agree with Charlie's recommendation. > > Regards, > Stan > > >> -----Original Message----- >> From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >> Sent: Wednesday, November 07, 2007 2:16 PM >> To: ext Ian Chakeres >> Cc: manet >> Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC >> >> >> Hello Ian, >> >> I think that the document is not ready for publication until the >> mandates for uniqueness and ordering of address TLVs are >> softened to MAY. Text should be added to indicate that >> individual protocols that conform to packetBB can mandate >> the use need for this feature if so desired. >> >> Regards, >> Charlie P. >> >> >> ext Ian Chakeres wrote: >>> This note announces the WG Last Call for comments on >>> draft-ietf-manet-packetbb-10.txt, "Generalized MANET Packet/Message >>> Format". >>> >>> The document can be found at: >>> http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-10.txt >>> >>> The document is intended to be submitted for publication as >> a proposed >>> standard document. >>> >>> Please review the document carefully and send your comments to the >>> MANET list and document authors. >>> >>> Given the relatively minor recent changes (added version. >> added packet >>> size. added special IANA alloc for TLV types 0 to 7.), this last >>> call >>> will end Wed Nov 14th AOE. >>> >>> Thanks, >>> Ian Chakeres >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >>> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 14:46:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqrR-00065q-KJ; Wed, 07 Nov 2007 14:46:49 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IpqrQ-00064M-7k for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 14:46:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpqrP-00064E-UI for manet@ietf.org; Wed, 07 Nov 2007 14:46:47 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpqrK-0006ql-FG for manet@ietf.org; Wed, 07 Nov 2007 14:46:47 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lA7JkaGd027383; Wed, 7 Nov 2007 14:46:36 -0500 (EST) Message-Id: <200711071946.lA7JkaGd027383@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007110714463621078 ; Wed, 07 Nov 2007 14:46:36 -0500 From: "Justin Dean" To: "'Charles E. Perkins'" Subject: RE: [manet] Regarding packetbb constraints on ordering and uniqueness. Date: Wed, 7 Nov 2007 14:52:00 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Acgha/QQcVWzZZTnRIOBuf83wPfrxAACUCyQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4732031F.7010103@nokia.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 1094b1c84fa6e846d476f39271f5074f Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I would like to comment on one of the points being discussed. >> Plus we have had several examples of good designs that would be >> prohibited by these restrictions. > > I disagree. Gee thanks... I guess you mean that my design is not good, sigh. To me its not that your design isn't good. Its that the example which you have presented do not fall within the scope of packetbb, in that it doesn't use the packetbb format to begin with but a more specific, efficient packet format only tangentially related to packetbb. I think your 'hello' example would be more clear, with regards to how the restrictions would negatively effect your design if it actually used packetbb. I honestly think there is still a lot of misunderstanding on what is and isn't possible with the current design. Most examples which use packetbb layout but require a relaxation of the restrictions, seem to me, not to actually require restrictions being lifted if a different TLV design/layout is used. And in most cases I have thought about the new design is often just as efficient and almost always less ambiguous. Justin > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > Sent: Wednesday, November 07, 2007 1:26 PM > To: ext Thomas Clausen > Cc: Manet > Subject: Re: [manet] Regarding packetbb constraints on > ordering and uniqueness. > > > Hello Thomas, > > I'll try to answer your comments here. > > ext Thomas Clausen wrote: > > > > It is not a claim. Chris has shown in his argumentation the clear > > benefits in terms of processing overhead. Chris, I and others have > > pointed out other benefits in detail. > > I strongly disagree that Chris has shown this. > If you will (perhaps in private email) direct me to his > strongest argument, I will take another look. Right now, I > only remember what seemed to me very vague and > unsubstantiated assertions about the way someone's current > parser had been written. > > > > > >> > >> To rehash (as you say) the matter, the argument for mandating the > >> ordering is that it is claimed to be useful for some protocols, > > > > No, you've got it wrong here. It has nothing to do with > protocols and > > everything to do with efficiently encoding, transmitting > and (uniquely > > and efficiently) parsing some information. The I-D in question does > > not specify how information is generated nor processed.....THAT is > > what the protocols shall do, and that is what they are free > to do in > > whichever order is appropriate. > > Yes, you are right that I was thinking about the protocols. > So since this mandate has nothing to do with protocols, I > very strongly believe it should be omitted from the protocol > specification. But wait! packetbb is not a protocol specification. > No, it is a meta-protocol specification. Thus, the > parsing-related mandate is _TWO_ steps removed from > appropriateness for inclusion in this document. > > > >> for the purpose of enabling some > >> sort of abbreviated parsing on the receiving side. > > > > ....that is one of the benefits, yes, although I believe > that striving > > for (and, indeed, in the specification as it is, achieving) linear > > parsing by a receiving node can not be said to be a bad > goal, can it? > > As you will have seen in previous emails, there are other benefits > > beyond this. > I am thinking about the quick-abort feature... which I have > argued is at least questionable if not downright anti-IETF in flavor. > > > > > >> But I question even whether this is valuable, especially since the > >> sending side then must do some unneeded work. > > > > If I have the choice, I'd rather have the sending node do > some extra > > work, if that means that the recipient is able to do something more > > efficient. > This is, then, according to your personal taste. However, it > does not stand up to logical scrutiny. > > Here is another formulation to expose what I claim is the fallacy. > > 1. The receiver wants to make sure of some uniqueness (we don't > know why, no general argument was given, only that the > authors favor the variable-assignment paradigm). > 2. Thus, the sender has to work harder to insure that the receiver > can make this check. > > First, I point out that a protocol could RECOMMEND that the > sender implement the ordering. Second, absolutely no > malicious behavior is prevented by this mandate. > > Thus, there are absolutely no efficiency gains evident so far. > > > > I'd argue that there are benefits in that, since I suspect > that most > > nodes will receive more incoming messages than the generate > > themselves. E.g. in a classic link-state protocol, each > node will for > > each message it generates, receive (ignoring duplicate, > which makes it > > even more compelling) n messages in a n+1 nodes large network. So > > optimising the message content for the receiver seems sensible. > It's even better to avoid making the check entirely. And I > don't see any downside to the more generous behavior, except > for possibly adding another sentence of text to whatever > protocol specification seems to have a need for this > exclusivity and sorting. > > > > > > So I would argue that this is, indeed, very valuable and that the > > sending side does very much needed work that has an overall benefit > > for the network. > > First, let's hope that most networks are not dominated by the > kind of one-to-many flooding that seems to be motivating this > specification. Second, you _could_ make it for the > particular protocol. Third, as pointed out above, the gain > in efficiency is really illusory. I think it is really just > a gain in mental satisfaction that some packet universe might > somehow be more organized. > > > >> There are several compelling arguments against this mandate. > >> 1. Not all protocols need it (if, indeed, any at all do) > > > > Again, it has nothing to do with protocols and everything > to do with > > efficiently and uniquely encoding, transmitting and parsing > > information....parsing happening before the encoded and transmitted > > information is handed off to the protocol. > > Again, if it has nothing to do with protocols, then it just > does not belong in the specification. And, the unique > encoding is _only_ of interest to fit Justin's model of TLVs > as a sort of variable assignment mechanism. TLVs do not have > to fit that restrictive model. > > > >> 2. Such ordering isn't mandated by any other IETF protocols. > > > > I don't think that's a valid argument here: the reason may > be that in > > packetbb, there's the two-dimensional (in lack of better > terms) aspect > > of address-block TLVs which is slightly different from > other TLV-based > > protocols out there (and, I add, is different for the purpose of > > efficient encoding....) -- which necessitates this treatment to be > > efficient. > > Sorry, Thomas, this makes very little sense to me. The > variable-assignment model is just not right for many cases. > And I cannot yet identify the coordinate axes that would > enable me to define some two-dimensional understanding of > what you're talking about. Perhaps you meant that the TLV > ordering structure is an array of intervals. > Then one axis would be > [dimensionality on the order of 0.5*(address range^2)]. > What would the other axis be? The scalar value for the value > to be assigned? > > Anyway this is a very poor basis for discussing any sort of > ordering mandate... > > > >> 3. By the time the packet has been captured, the > >> major portion of the cost has been expended and the > >> additional parsing cost is negligible in the extreme. > > > > That's an one-sided assertion. > I think it is quite easy to see in practice. Calculate the > energy expenditure from the radio interface, and compare it > to the expenditure from reading a string into memory. > Calculate the time spent from the bandwidth delay and compare > it to the CPU time expenditure by a processing unit made in > the last 50 years. You can get a lot of martinis from me if > you find that the processing side is anywhere near similar. > > You do have a specific environment in mind where this may > be true. I > > have a different environment in mind where this cost is not > negligible > > at all. > Please do tell! > > > I shall add that the constraints were something that I had to be > > "talked into" initially from people actually > building/running OLSRv2, > > and for whom the costs were everything but negligible. > > Any documentation you can share?? > > But then why isn't this in the OLSRv2 specification instead > of packetBB? > > I really am very skeptical about this. > > > > > I could add something about the fact that eliminating the > > per-message-processing-overhead for the receiver has some benefits > > wrt. DoS also, but I think it suffice to say that I fail to see the > > argument for making something more costly, when we know how > to make it > > less costly. > > I very much claim that eliminating the mandate is less costly. > > There is absolutely no resilience against DoS provided by > making this mandate. > > > > > As an academic, I'll just stick to my > > send-1-message-process-n-messages example from above as an > argument in > > favour of reducing per-message-processing-overhead, since I believe > > that it illustrates a point quite nicely. > > Is packetBB intended only for one-to-many protocol processing? > > Besides that, there just isn't any advantage. At most, your > argument seems to mean that the parser can avoid allocating a > few most slots for storing the TLV structure data and avoid a > subroutine call for the higher-level protocol processing. > And for this we are going to pay through the nose by having > all of these protocol restrictions and additional parsing > steps for protocols that have zero use for the restrictions? > > I am definitely not seeing it. > > > > >> And these are just the ones I remember right off the top > of my head. > >> For a full recapitulation ("rehash"), please ask and I will do the > >> seemingly thankless task of rehashing the rehashed arguments from > >> months ago. > >> None of these three points has ever been rebutted. > >> > > > > As far as I am concerned, these points have all been > addressed and the > > benefit of retaining the constraint on uniqueness and > ordering remain > > clear. I'd take it that you do not dispute the brief example given > > previously in this email. > > I hope my counterargument for your rebuttal will be of some interest. > > > >> Plus we have had several examples of good designs that would be > >> prohibited by these restrictions. > > > > I disagree. > > Gee thanks... I guess you mean that my design is not good, sigh. > > > I'll first say that the design examples presented have been > hypothetical. > > Well, if it exists in protocol specification, simulation, and > code is it still hypothetical? > > > Second, the designs examples could equally well be > accomplished with > > the current design of packetbb. > > Not without drastic packet-size enlargement. > > In fact, one could do ANYTHING in the variable-assignment > model of operation, thusly: > - identify all desired multi-sets of values by way of indices > from the range [1, googolplex]. > - distribute the per-TLV databases to all nodes > - use an index to identify the appropriate multiset of values > within the packetBB-parsable TLV. > > I do not think this is a viable model of operation in today's world. > > > > As I see it, there are a great number of benefits to retaining the > > current design of packetbb as it is (and these benefits have been > > enumerated elsewhere), > I am still not seeing it, Thomas. The efficiency gains are > either very small or else not even there at all. > > > and I have seen no compelling benefits presented of altering the > > design. In particularly not since the alterations proposed > incur large > > penalties in terms of parsing ambiguity and parsing overhead at the > > receiver. > > I think that you have unfairly dismissed the non-IETFness of > this restriction and exaggerated the occasional benefits by > perhaps several orders of magnitude, while dismissing the > corresponding costs by pointing out that they are not to your taste. > > Even aside from the questionable nature of the benefits > themselves, I can find nothing in your response that > indicates the need for their universal application to all > future packetBB protocols. > > Regards, > Charlie P. > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 14:57:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipr1r-0003d4-Mi; Wed, 07 Nov 2007 14:57:36 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ipr1q-0003cd-Ik for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 14:57:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipr1q-0003by-7z for manet@ietf.org; Wed, 07 Nov 2007 14:57:34 -0500 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipr1p-0006f2-9l for manet@ietf.org; Wed, 07 Nov 2007 14:57:33 -0500 Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 20:57:31 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 20:57:31 +0100 From: "Teco Boot" To: "'Thomas Clausen'" , "'Stan Ratliff \(sratliff\)'" , "'Charles E. Perkins'" , "'Ian Chakeres'" References: <7FB7EE0A621BA44B8B69E5F0A09DC76404E7856E@xmb-rtp-208.amer.cisco.com> <548143B0-4F31-4921-A29E-E119B868153D@thomasclausen.org> In-Reply-To: <548143B0-4F31-4921-A29E-E119B868153D@thomasclausen.org> Subject: RE: [manet] draft-ietf-manet-packetbb - WGLC Date: Wed, 7 Nov 2007 20:57:17 +0100 Message-ID: <002001c82178$6755d690$360183b0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcghdnMKICUM866iQXuyUG+qJDcw+AAAQDRQ Content-Language: nl X-OriginalArrivalTime: 07 Nov 2007 19:57:31.0382 (UTC) FILETIME=[6E815160:01C82178] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Can we come up with a proposal that is acceptable for all of us? We could spend a bit and declare the restrictions active when set (or cleared, using negative logic). This will allow two modes in a single packet, but not two modes in a single message. And protocols can use the restrictions when needed or when CPU cycles are saved. What do you think? Teco > -----Oorspronkelijk bericht----- > Van: Thomas Clausen [mailto:thomas@thomasclausen.org] > Verzonden: woensdag 7 november 2007 20:41 > Aan: Stan Ratliff (sratliff) > CC: manet > Onderwerp: Re: [manet] draft-ietf-manet-packetbb - WGLC > > Ian, > > I suggest that the arguments presented for changing the mandates from > MUST to MAY have been insufficient, and that the consequences of > doing so have not been fully considered by the proponents of this > change. > > I furthermore note that the current mandates in packetbb in no way is > limiting the applicability within the intended problem domain of > MANET protocols, and that therefore -- given the benefits which have > been presented elsewhere -- it is timely to move forward with this I- > D towards publication. > > Regards, > > Thomas > > > On 7Nov , 2007, at 8:25 PM, Stan Ratliff (sratliff) wrote: > > > Ian, > > > > I agree with Charlie's recommendation. > > > > Regards, > > Stan > > > > > >> -----Original Message----- > >> From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > >> Sent: Wednesday, November 07, 2007 2:16 PM > >> To: ext Ian Chakeres > >> Cc: manet > >> Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC > >> > >> > >> Hello Ian, > >> > >> I think that the document is not ready for publication until the > >> mandates for uniqueness and ordering of address TLVs are > >> softened to MAY. Text should be added to indicate that > >> individual protocols that conform to packetBB can mandate > >> the use need for this feature if so desired. > >> > >> Regards, > >> Charlie P. > >> > >> > >> ext Ian Chakeres wrote: > >>> This note announces the WG Last Call for comments on > >>> draft-ietf-manet-packetbb-10.txt, "Generalized MANET Packet/Message > >>> Format". > >>> > >>> The document can be found at: > >>> http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb- > 10.txt > >>> > >>> The document is intended to be submitted for publication as > >> a proposed > >>> standard document. > >>> > >>> Please review the document carefully and send your comments to the > >>> MANET list and document authors. > >>> > >>> Given the relatively minor recent changes (added version. > >> added packet > >>> size. added special IANA alloc for TLV types 0 to 7.), this last > >>> call > >>> will end Wed Nov 14th AOE. > >>> > >>> Thanks, > >>> Ian Chakeres > >>> > >>> > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/manet > >>> > >> > >> > >> > >> _______________________________________________ > >> manet mailing list > >> manet@ietf.org > >> https://www1.ietf.org/mailman/listinfo/manet > >> > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > -- > Thomas Clausen > Thomas@thomasclausen.org > http://www.thomasclausen.org/ > http://hipercom.thomasclausen.org/ > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 15:42:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iprji-0002qj-GD; Wed, 07 Nov 2007 15:42:54 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iprjh-0002nm-8E for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 15:42:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iprjg-0002nN-MH for manet@ietf.org; Wed, 07 Nov 2007 15:42:52 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iprjc-0000HV-BO for manet@ietf.org; Wed, 07 Nov 2007 15:42:52 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA7KgWLk005108; Wed, 7 Nov 2007 22:42:46 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 22:42:17 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 14:42:06 -0600 Received: from [10.162.71.187] ([10.162.71.187]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 14:42:05 -0600 Message-ID: <47322316.2030305@nokia.com> Date: Wed, 07 Nov 2007 12:41:58 -0800 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Thomas Clausen Subject: Re: [manet] Regarding packetbb constraints on ordering and uniqueness. References: <2743F0F2-3273-443F-BDFB-593D7FFA54F2@thomasclausen.org> <4731E629.3000301@nokia.com> <4732031F.7010103@nokia.com> <2E82E368-FF55-4831-8046-F77FD35B7F28@thomasclausen.org> In-Reply-To: <2E82E368-FF55-4831-8046-F77FD35B7F28@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 20:42:06.0168 (UTC) FILETIME=[A8CD4580:01C8217E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ba9cd4f9acda58dbe142afff7265daff Cc: Manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Thomas, I'll try again. ext Thomas Clausen wrote: > > I remember Chris had a well-phrased argument to this effect in a > previous email. I am sure that it is in the archives. It would be nice if you could help me find it. > >>> >>> >>>> >>>> To rehash (as you say) the matter, the argument for >>>> mandating the ordering is that it is claimed to be useful >>>> for some protocols, >>> >>> No, you've got it wrong here. It has nothing to do with protocols >>> and everything to do with efficiently encoding, transmitting and >>> (uniquely and efficiently) parsing some information. The I-D in >>> question does not specify how information is generated nor >>> processed.....THAT is what the protocols shall do, and that is what >>> they are free to do in whichever order is appropriate. >> >> Yes, you are right that I was thinking about the protocols. >> So since this mandate has nothing to do with protocols, >> I very strongly believe it should be omitted from the protocol >> specification. But wait! packetbb is not a protocol specification. >> No, it is a meta-protocol specification. Thus, the parsing-related >> mandate is _TWO_ steps removed from appropriateness for >> inclusion in this document. > > I'll try again, then, since it's apparently not yet clear: > > o packetbb is defining an encoding for exchanging information > relevant to a specific problem-domain; Is this the problem domain of general [manet] protocols, or the problem domain of something considerably more restrictive? > o this encoding is made such that this information is > transmitted in a way that allows efficient and unique decoding; I guess my point has been that it is a mistake to impose the efficiency argument on all protocols for the benefit of a few. > o subsequent to the decoding, an unique data structure results; This is debatable as you have phrased it. I think you meant that a data structure results with the property that all variables have been assigned a unique value. > o this data structure can be used in a way which is to be > specified by a protocol specification. This is a vey general statement, not at issue in the discussion. > > I do not understand what is meant by "meta-protocol" In this context, it means a specification by which other conformant protocols can be specified. > and the like in your paragraph above -- however as has been explained > many times over, the constraints serve to ensure that the encoding can > be parsed into unique data structures (and that two nodes receiving > the same encoded information will be able to, despite being two > different implementations, decode identical data structures) linearly. As stated, this can be done very well without the constraints at issue. > > > > Quick-abort is one, minor, benefit of this encoding. However if you > consult previous emails, you will note that the efficiency goes beyond > "quick-abort" and has to do with the complexity of the parsing algorithm. So now we have "quick-abort" [minor benefit] + parsing complexity. > > ... I believe that the example I provided gives ample justification > for why a low parsing-overhead is beneficial, and why a little extra > effort on the sending side to achieve a gain on the receiver is > desirable. I am of the understanding that a low > per-packet-parsing-overhead is generally favoured. Of course. But you can get even lower parsing overhead by omitting the check entirely. Your example only pertains when every receiver has a strong reason to enforce the mandated behavior, and this is really debatable. More later... > > >> Here is another formulation to expose what I claim is the fallacy. >> >> 1. The receiver wants to make sure of some uniqueness (we don't >> know why, no general argument was given, only that the >> authors favor the variable-assignment paradigm). > > No, Charlie, ample arguments have been given in previous emails as to > why this is beneficial. Arguments have been given many times but they are are, I think, summarizable as '"quick-abort" [minor benefit] + parsing complexity' > >> 2. Thus, the sender has to work harder to insure that the receiver >> can make this check. > > No, the sender has to ensure that the encoding is done as specified this is working harder... > , whereby the recipient can parse it linearly. > > I thought you were agnostic to the cost of "processing"? Agnostic is the wrong word here. I'm much aware of it, being a former assembly language programmer and all, sigh. > You argue that processing by the receiver is insignificant, in which > case processing by the sender is even MORE insignificant -- and thus, > I do not understand why processing in the sender suddenly is important? I did not suggest that the sender processing complexity was the determining factor here, only that it isn't obvious that, in general, the argument should be tilted in favor of minimizing receiver processing for all protocols. > > Recall my simple flooding-example? Each node will send 1 packet but > receive n, in a n+1 large network. Hence, if processing-time is > insignificant to you, and you are willing to add extraneous overhead > in n nodes, why is it not better to add a little overhead in the one > node (the one that sends) against a saving of extraneous overhead in > the n nodes that receive? > > Sorry, Charlie, but that does -- to reuse your phrase -- "not stand up > to logical scrutiny". For flooding, I agree that sender-side processing complexity should be increased to enable a decrease in receiver-side processing complexity. I don't see where I have disagreed with this. But even so, one can reduce complexity on both ends by simply not doing the uniqueness check. You have dismissed my concern about non-IETFness, but you did not present a good argument about why packetBB-conformant protocols have special needs that are not present in other IETF protocols. You just pointed out that it might be possible for them to have special needs. > >> First, I point out that a protocol could RECOMMEND that >> the sender implement the ordering. > > No, not at all since that no longer becomes something that can be done > at parse-time, but at a higher level -- which means that the work > (without the constraint, now no longer doable in O(n)) of parsing > already has been done. So this will clearly lead to inefficiencies. I think it means that you want to have not only a single meta-protocol specification for all [manet] protocols, but even a single parser. That's a bitter pill to swallow. And we could even have a single parser if the parser had the merest bit of type-dependent protocol processing, easily loadable when the kernel is loaded. That's just the first thing that comes to mind; I am sure there are other handy ways to do it. So I do not agree that this argument is clear. > > Secondly, you are ignoring the points made regarding the MANET wg > doing multiple protocols and genericity (is that a word?) of parsing. > >> Second, absolutely no >> malicious behavior is prevented by this mandate. >> > > No, but the impact of malicious behavior as part of a DoS attack is > lower the lower the per-packet-parsing-overhead is. That was kind of > my point. Why, then, wouldn't a smart DoS-er make the nastygrams to be packetBB-conformant? > >> Thus, there are absolutely no efficiency gains evident so far. >> > > Other than that parsing can be done linearly in n nodes, of course..... It still can, when needed, if the behavior is protocol-type-dependent. > >> >> > > And the fact that the parsing can no longer: > > - be generic, regardless of which protocol uses packetbb You can push this genericity entirely too far. I could make a lot of silly examples to prove my point, but my fingers are getting tired already from massaging so many keys. I believe that this specification has already pushed it too far. > - be linear without backtracking, If the indicated checking is needed at all, that is. > - ensure that the resulting data structure is unique, specifically Here, again, I think you mean that the variables have unique assignments. > - that two implementations will result in the same data structure > given the same input The constraints are definitely not needed to insure that. > > Of course, I consider the above to be important, especially when no > expressiveness is lost in doing so. But, expressiveness is very clearly lost by imposing the single-assignment model for all types of variables. > > >>> >>> >>> So I would argue that this is, indeed, very valuable and that the >>> sending side does very much needed work that has an overall benefit >>> for the network. >> >> First, let's hope that most networks are not dominated by the >> kind of one-to-many flooding that seems to be motivating this >> specification. > > So what you are saying is that you hope that networks are not > dominated by protocols which, say, specify that a node (a source for a > traffic flow) issue a request to discover the network topology (say, a > Route Request), with this Route Request being flooded throughout the > network....? Since in that case, one node generates a message, which > is being retransmitted by n nodes in our n+1 large network..... Yes, I think that route discovery should be a minor part of the overall network traffic. We should be working towards making that happen. > > >>> Again, it has nothing to do with protocols and everything to do with >>> efficiently and uniquely encoding, transmitting and parsing >>> information....parsing happening before the encoded and transmitted >>> information is handed off to the protocol. >> >> Again, if it has nothing to do with protocols, then it just does >> not belong in the specification. > > Yes, it belongs in the packetbb specification -- it does NOT belong in > a protocol specification using packetbb since this is already *in* > packetbb. Well, I am writing this to ask you to take it out, so that it can be properly introduced as a per-protocol detail for those protocols that need it. > >>> >>>> 2. Such ordering isn't mandated by any other IETF protocols. >>> >>> I don't think that's a valid argument here: the reason may be that >>> in packetbb, there's the two-dimensional (in lack of better terms) >>> aspect of address-block TLVs which is slightly different from other >>> TLV-based protocols out there (and, I add, is different for the >>> purpose of efficient encoding....) -- which necessitates this >>> treatment to be efficient. >> >> > > Read the packetbb I-D, and note the difference between packet/message > TLVs and address-block TLVs. It should be fairly obvious what I am > hinting to. Also note that I said "in lack of better terms" in my > comment above. > > But, it should be fairly obvious why the TLVs are as they are if you > read the I-D. I did read it, several times. It's obvious that the document authors are very much favorable towards the single-assignment paradigm, and do not seem to believe that other models could ever be useful in the future. > >>> >>>> 3. By the time the packet has been captured, the >>>> major portion of the cost has been expended and the >>>> additional parsing cost is negligible in the extreme. >>> >>> That's an one-sided assertion. >> I think it is quite easy to see in practice. Calculate the energy >> expenditure from the radio interface, and compare it to the >> expenditure from reading a string into memory. Calculate the >> time spent from the bandwidth delay and compare it to the >> CPU time expenditure by a processing unit made in the last >> 50 years. You can get a lot of martinis from me if you find >> that the processing side is anywhere near similar. > > Therein our differences: you have an a-priori of having infinite > computational/storage capacity and limited power. I am saying that > sometimes you have limited computational/storage capacity AND limited > power. Here is a terrible exaggeration. I never said infinite. I believe that for many cases of interest, both are limited. However, that is why you have to be careful against specifying for all cases something that is of value for perhaps only a few cases. If you want to be persuasive here, I think it would be valuable to counter the commonly held belief that radio-transmission and reception demands a lot more energy than processing. This is why your cellphone dies a lot faster when you are blabbering away for hours, compared to when the handset is on standby. This is also why when people first put WiFi into the handsets, the batteries went to zero pretty darned fast. I think the relative tradeoffs here are dramatically clear. And who is saying infinite? > >>> You do have a specific environment in mind where this may be true. I >>> have a different environment in mind where this cost is not >>> negligible at all. >> Please do tell! >> > > Done above. I did not see it. Do you have an example? Just to say "limited processing power" is not very illuminating, especially in comparison with the everyday experience of what people use a lot. > >>> I shall add that the constraints were something that I had to be >>> "talked into" initially from people actually building/running >>> OLSRv2, and for whom the costs were everything but negligible. >> >> Any documentation you can share?? >> > > Was discussed at Paris and subsequent IETFs -- I believe that you were > party to that a long night in Vancouver too. I clearly remember being told that you had inputs from third parties requesting the sorting. I asked who it was and did not get any answer. Besides that, the beer was very good. > > >> And for this we are going to pay through the nose by having >> all of these protocol restrictions and additional parsing steps >> for protocols that have zero use for the restrictions? > > Protocols can impose their own restrictions. Packetbb is concerned > with the encoding as is transmitted over the wire -- not with how > protocols process the data structure constructed from successful > parsing of a message. There are, therefore, nothing to "pay", no > "restrictions", no "additional parsing steps| for protocols. This is wrong. One has to pay the following costs: - Prohibition of designs that do not conform to the single-assignment paradigm for variable initialization - Processing cost of sorting - Packet enlargement for protocols that might otherwise be designed differently. > > I think that it would be beneficial to re-read the email that I wrote > a while ago in which I discussed encoding/parsing/processing in > greater details, since I feel that you have a misunderstanding on that > front. Do you still think I misunderstand -- or do you instead see that I am characterizing the benefits as not justifying the costs on various levels? > > I suspect that you have misunderstood the purpose of packetbb. Any > constraints in there are only on how information is encoded, in order > to ensure efficiency, genericity and unambiguity -- NOT on how a > protocol can use it. What about for protocols that want to assign potentially multiple values to variables in a way prohibited by packetBB? > >> >> >> >> Not without drastic packet-size enlargement. >> >> In fact, one could do ANYTHING in the variable-assignment >> model of operation, thusly: >> - identify all desired multi-sets of values by way of indices >> from the range [1, googolplex]. >> - distribute the per-TLV databases to all nodes >> - use an index to identify the appropriate multiset of values >> within the packetBB-parsable TLV. >> >> I do not think this is a viable model of operation in today's world. >> > > I suspect that you have misunderstood the purpose of packetbb. Any > constraints in there are only on how information is encoded, in order > to ensure efficiency, genericity and unambiguity -- NOT on how a > protocol can use it. Actually, it is my main point that some protocols cannot use it. It is a second point that the claimed efficiencies are either not important (in some cases), or never important enough to support the universal mandate (in other cases). > >>> and I have seen no compelling benefits presented of altering the >>> design. In particularly not since the alterations proposed incur >>> large penalties in terms of parsing ambiguity and parsing overhead >>> at the receiver. >> >> I think that you have unfairly dismissed the >> non-IETFness of this restriction and exaggerated >> the occasional benefits by perhaps several orders >> of magnitude, while dismissing the corresponding >> costs by pointing out that they are not to your taste. >> >> Even aside from the questionable nature of the benefits >> themselves, > > > Sorry, Charlie, I will not entertain discussions which call on > arguments such as "non-IETFness" or "dismissing based on taste". By the former, I mean to compare against the experience of other working groups. You should entertain that discussion. We can dispense with any discussions based on tastefulness, but I was responding to some particular wording in your note about what would happen if you had your choice. > I further recent that you label my arguments as "occasional > benefits" and of "questionable nature" when I present you with a > common example (a flooding.....which happens in AODV/OLSR/OLSRv2/DYMO > all the time) and point to the balance between in such a case having a > (processing) overhead in one node vs. in n nodes. This is a technical > argument and a very common scenario -- so common, in fact, that all > MANET wg protocols do it....and yet you counter-argument is: > >> Let's hope that most networks are not dominated by the >> kind of one-to-many flooding that seems to be motivating this >> specification. > > I would like to suggest that we return this discussion to sober and > technical matters with technical arguments, least I see no point in > continuing? Hey, I'm not drunk! But I maintain that we should strive towards networks that are not dominated by flooding costs. Nevertheless, I am all in favor of reducing the costs ascribed to flooding. Presumably you are also, and then we ought to be talking about reducing packet size [ref: bloat]. > > >> I can find nothing in your response that >> indicates the need for their universal application to all >> future packetBB protocols. > > > I suspect that you have misunderstood the purpose of packetbb. Well I hope by now you no longer ascribe my disagreement to simple misunderstanding. > Any constraints in there are only on how information is encoded, in > order to ensure efficiency, genericity and unambiguity -- NOT on how a > protocol can use it. But a protocol cannot use it, if the protocol operation already specifically does not conform to the single-assignment paradigm for typed variables. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 16:05:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ips5q-0001Sf-2I; Wed, 07 Nov 2007 16:05:46 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ips5n-0001RI-LM for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 16:05:43 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ips5m-0001PZ-Tj for manet@ietf.org; Wed, 07 Nov 2007 16:05:42 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ips5m-000189-Ew for manet@ietf.org; Wed, 07 Nov 2007 16:05:42 -0500 X-IronPort-AV: E=Sophos;i="4.21,386,1188802800"; d="scan'208";a="185445268" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2007 13:05:42 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id lA7L5f5R013387; Wed, 7 Nov 2007 13:05:41 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA7L4tg9010450; Wed, 7 Nov 2007 21:05:41 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 16:05:34 -0500 Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 16:05:34 -0500 Message-ID: <47322878.6000702@cisco.com> Date: Wed, 07 Nov 2007 16:04:56 -0500 From: Russ White User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Clausen Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <7FB7EE0A621BA44B8B69E5F0A09DC76404E7856E@xmb-rtp-208.amer.cisco.com> <548143B0-4F31-4921-A29E-E119B868153D@thomasclausen.org> In-Reply-To: <548143B0-4F31-4921-A29E-E119B868153D@thomasclausen.org> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 21:05:34.0087 (UTC) FILETIME=[EFFCA970:01C82181] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002 X-TM-AS-Result: No--9.750000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2076; t=1194469541; x=1195333541; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[manet]=20draft-ietf-manet-packetbb=20-=20WGLC |Sender:=20; bh=YPsxP+ueLQxI5e8KrEkYJqxUpjave6jD5O8w1ZfgSFA=; b=TbN4XuXvRVbSzf1nj/r6vr1sGpFqAORaRtwYS2XskjAUL4jtyoZZSOsQhV8OQhoASYrJnMv6 ossa6ARr2+ev0wJNqQuNQ4ynQZqI4tO9fUFmZjMRKk/P7mS60JcF4EIl; Authentication-Results: sj-dkim-4; header.From=riw@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: manet , "Stan Ratliff \(sratliff\)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I suggest that the arguments presented for changing the mandates from > MUST to MAY have been insufficient, and that the consequences of doing > so have not been fully considered by the proponents of this change. > > I furthermore note that the current mandates in packetbb in no way is > limiting the applicability within the intended problem domain of MANET > protocols, and that therefore -- given the benefits which have been > presented elsewhere -- it is timely to move forward with this I-D > towards publication. I would suggest that if the packet ordering constraints are left as they are, many protocols will find them to be so restrictive, and so unuseful, as to make packetbb unuseful. That would defeat the entire purpose of creating a standard in this area, IMHO. Alternate suggestions have been aired on the list, and roundly ignored. For instance, the packet format could have an indicator in the header indicating if the TLVs are "in order" or not. Or, the TLV space could be divided in half, so that each TLV actually has two TLV numbers, one of which must be used in order, the other of which does not. Or, the packet could be divided through the use of TLVs so some part of the packet is in order, and the remainder is not. Some protocols could place all their TLVs in the "in order" section, some could place all their TLVs in the "out of order" section, and other protocols could place some in each section, as they see fit. There are a lot of creative solutions lying around here. I don't understand why none of them have been considered before the draft got to the last call point, nor do I understand how the draft got to last call with this large of an issue outstanding. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMih3ER27sUhU9OQRAmS4AKCR/lGNFLh2wbgbrSwmm8JTMDjoqQCgx5YF 8oxxhbFLO3bcFq3WmJKgtso= =EedL -----END PGP SIGNATURE----- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 16:51:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipsnn-0003ln-0k; Wed, 07 Nov 2007 16:51:11 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ipsnl-0003kr-Cv for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 16:51:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipsnl-0003kj-3K for manet@ietf.org; Wed, 07 Nov 2007 16:51:09 -0500 Received: from mho-02-bos.mailhop.org ([63.208.196.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipsnj-00045c-Cr for manet@ietf.org; Wed, 07 Nov 2007 16:51:09 -0500 Received: from aste-genev-bois-153-1-28-167.w83-112.abo.wanadoo.fr ([83.112.74.167] helo=[192.168.147.106]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Ipsni-000NJR-K4; Wed, 07 Nov 2007 21:51:06 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.74.167 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+HfDYCmBynROab8dtcoyix Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Clausen Date: Wed, 7 Nov 2007 22:50:56 +0100 To: manet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.3 (+) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: "Stan Ratliff \(\(sratliff\)\)" Subject: [manet] (no subject) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Russ, All The short answer (and a short answer is all I have time for, it's 10:30PM here and I've still not had dinner yet....) to all of the below is that doing "half" (i.e. having some things be optional, or the type-space divided etc) accomplishes nothing in that one gets all the inconveniences (parsing can not guarantee anything re. unambiguity etc, nor can it be done linearly in a single pass etc.) with none of the benefits that the ordering and uniqueness constraints would otherwise have. I.e. having half gives us worse- than-nothing.... And, as I have stated repeatedly, I have not seen any tangible benefits presented of making the ordering and uniqueness constraints go away presented that would outweigh the inconveniences in making them go away. Rather, removing these constraints complicate things greatly, as stated elsewhere. So, since "half is worse than nothing", I'm firmly against "half". Since the benefits of not having the constraints are unclear but the inconveniences are quite considerable, whereas having the constraints presents considerable benefits with little or no inconveniences, then I see no reasons not to maintain and move forward with the constraints in place. Justin said it elegantly, so I'll cite him: > I honestly think there is still a lot of misunderstanding on what > is and > isn't possible with the current design. Most examples which use > packetbb > layout but require a relaxation of the restrictions, seem to me, > not to > actually require restrictions being lifted if a different TLV > design/layout > is used. And in most cases I have thought about the new design is > often > just as efficient and almost always less ambiguous. Finaly, to pound back at Russ' last sentence, which went: > I don't > understand why none of them have been considered before the draft > got to > the last call point, nor do I understand how the draft got to last > call > with this large of an issue outstanding. I will just add that I do not understand why this issue was only addressed only well AFTER (~ 20 days after) the WGLC of this I-D closed on July 24, and not in the two years preceding where this has been in place IN THE CURRENT FORM in the I-D and the I-D has been discussed widely within the MANET wg. While the design was still wide open might just have been the time to address this -- not weeks AFTER a WGLC of an essentially done and widely implemented specification. So one clearly wonders why this was brought forward at such a late time.... And now, off to the bbq pork roast (which, if it's burned, I'll blame on y'all) -- until tomorrow ;) Thomas On 7Nov , 2007, at 10:04 PM, Russ White wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> I suggest that the arguments presented for changing the mandates from >> MUST to MAY have been insufficient, and that the consequences of >> doing >> so have not been fully considered by the proponents of this change. >> >> I furthermore note that the current mandates in packetbb in no way is >> limiting the applicability within the intended problem domain of >> MANET >> protocols, and that therefore -- given the benefits which have been >> presented elsewhere -- it is timely to move forward with this I-D >> towards publication. > > I would suggest that if the packet ordering constraints are left as > they > are, many protocols will find them to be so restrictive, and so > unuseful, as to make packetbb unuseful. That would defeat the entire > purpose of creating a standard in this area, IMHO. > > Alternate suggestions have been aired on the list, and roundly > ignored. > For instance, the packet format could have an indicator in the header > indicating if the TLVs are "in order" or not. Or, the TLV space > could be > divided in half, so that each TLV actually has two TLV numbers, one of > which must be used in order, the other of which does not. Or, the > packet > could be divided through the use of TLVs so some part of the packet is > in order, and the remainder is not. Some protocols could place all > their > TLVs in the "in order" section, some could place all their TLVs in the > "out of order" section, and other protocols could place some in each > section, as they see fit. > > There are a lot of creative solutions lying around here. I don't > understand why none of them have been considered before the draft > got to > the last call point, nor do I understand how the draft got to last > call > with this large of an issue outstanding. > > :-) > > Russ > -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 17:01:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpsyC-0003rZ-As; Wed, 07 Nov 2007 17:01:56 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IpsyA-0003m5-1P for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 17:01:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipsy9-0003kJ-MA for manet@ietf.org; Wed, 07 Nov 2007 17:01:53 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipsy5-0004RQ-Ve for manet@ietf.org; Wed, 07 Nov 2007 17:01:53 -0500 X-IronPort-AV: E=Sophos;i="4.21,386,1188802800"; d="scan'208";a="248149438" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 07 Nov 2007 14:01:39 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA7M1dGD004935; Wed, 7 Nov 2007 14:01:39 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA7M17g9007992; Wed, 7 Nov 2007 22:01:38 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 17:01:35 -0500 Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 17:01:34 -0500 Message-ID: <47323598.50000@cisco.com> Date: Wed, 07 Nov 2007 17:00:56 -0500 From: Russ White User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Clausen References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 22:01:34.0618 (UTC) FILETIME=[C304FFA0:01C82189] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002 X-TM-AS-Result: No--6.399700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3359; t=1194472899; x=1195336899; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20 |Sender:=20; bh=trCNqkYOtcBjczgC7xzOSMuv0ZFCMAECq3N5kBstuo8=; b=S3age1uDUkumh9DITRy+Oy+khp4VjO7zIx8NFMKmdtXej1jFnMAcLlmAeqisvi37W1sibq1J ck68SnulsZF7MxL4pazf5D7VPPQIdNYhueshGBaqMJbyDv4Kovs4EenbBSvQfeE2tvMXnr6Kjk rlbAybDj7SLZZkuCLLs1q8Y5Q=; Authentication-Results: sj-dkim-1; header.From=riw@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: manet , "Stan Ratliff \(\(sratliff\)\)" Subject: [manet] Re: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The short answer (and a short answer is all I have time for, it's > 10:30PM here and I've still not had dinner yet....) to all of the below > is that doing "half" (i.e. having some things be optional, or the > type-space divided etc) accomplishes nothing in that one gets all the > inconveniences (parsing can not guarantee anything re. unambiguity etc, > nor can it be done linearly in a single pass etc.) with none of the > benefits that the ordering and uniqueness constraints would otherwise > have. I.e. having half gives us worse-than-nothing.... I strongly disagree. Doing it correctly actually gives you the best of all worlds--those protocols that wish to use ordering can use it, and those which do not don't use it. I don't see ANY argument that shows how it's more efficient for a protocol that does NOT want or need to use in order TLVs will be accommidated in this proposal. In fact, I have a sneaking suspicion that if this were to become a standard, it would result in a large number of threads where sentences like this are sent on list: "Well, our proposal is more efficient than yours with the standard (!) packet formatting described in RFC XXXX, so the WG should adopt our proposal over yours, no matter the other advantages and disadvantages." > And, as I have stated repeatedly, I have not seen any tangible benefits > presented of making the ordering and uniqueness constraints go away > presented that would outweigh the inconveniences in making them go away. > Rather, removing these constraints complicate things greatly, as stated > elsewhere. It complicates things for some protocols, and makes life easier for others. > So, since "half is worse than nothing", I'm firmly against "half". And I'm firmly against the whole. Either the WG finds a compromise, or I will oppose this draft through the entire process. And I think we could find enough opposition to squash this draft in it's entirety, in the end. >> I don't >> understand why none of them have been considered before the draft got to >> the last call point, nor do I understand how the draft got to last call >> with this large of an issue outstanding. > > I will just add that I do not understand why this issue was only > addressed only well AFTER (~ 20 days after) the WGLC of this I-D closed > on July 24, and not in the two years preceding where this has been in > place IN THE CURRENT FORM in the I-D and the I-D has been discussed > widely within the MANET wg. Actually, I could go back quite a ways and point to emails I've sent to the list asking this specific question. And I could point to multiple emails from others stating the current draft is not acceptable. What I don't understand, on the other hand, is how this got so far when there were widely known and documented issues with it. Those emails were roundly ignored. If you ignore objections early in the process, then they tend to come back much more forcefully at the end of the process. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMjWYER27sUhU9OQRAgvuAJ9kRoXcSRhdn2f90gug31xxalaBIgCcDSAm qdqUAMFv8A6Xu4BT2StIozo= =TbD6 -----END PGP SIGNATURE----- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 17:42:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iptbf-0004Pd-CX; Wed, 07 Nov 2007 17:42:43 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iptbd-0004GL-Rt for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 17:42:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iptbd-0004EY-GR for manet@ietf.org; Wed, 07 Nov 2007 17:42:41 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iptbd-0005C0-5F for manet@ietf.org; Wed, 07 Nov 2007 17:42:41 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lA7MgQZw005079 for ; Wed, 7 Nov 2007 17:42:31 -0500 (EST) Message-Id: <200711072242.lA7MgQZw005079@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007110717422622132 for ; Wed, 07 Nov 2007 17:42:26 -0500 From: "Justin Dean" To: "'Manet'" Subject: RE: [manet] draft-ietf-manet-packetbb - WGLC Date: Wed, 7 Nov 2007 17:47:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcghghKBZCY9cAeZSC6vR9+oNrwF1AAC+euA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <47322878.6000702@cisco.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > -----Original Message----- > From: Russ White [mailto:riw@cisco.com] > Sent: Wednesday, November 07, 2007 4:05 PM > To: Thomas Clausen > Cc: manet; Stan Ratliff (sratliff) > Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC ... > I would suggest that if the packet ordering constraints are > left as they are, many protocols will find them to be so > restrictive, and so unuseful, as to make packetbb unuseful. > That would defeat the entire purpose of creating a standard > in this area, IMHO. ... I would again like to reiterate that I honestly think there is A LOT of confusion on what the restrictions actually restrict. I would like to ask for solid examples of protocol behaviors which people feel are not possible using the packetbb format. I feel a few good examples of what can be done with the current format, will go a long way in illustrating what the TLV restrictions are actually doing and what they are not doing. The restriction of TLV order only restricts encoding/decoding and not protocol processing which can happen in any order. The single TLV type value per address does not restrict TLVs to carry only one 'value' in the value field. TLV's can be defined to carry an arbitrary list of values in one value field which can be used however the protocol wishes. Justin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 18:55:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpukU-0001iS-JM; Wed, 07 Nov 2007 18:55:54 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IpukS-0001gf-H7 for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 18:55:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpukS-0001gX-5K for manet@ietf.org; Wed, 07 Nov 2007 18:55:52 -0500 Received: from mho-01-bos.mailhop.org ([63.208.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpukR-0007c6-A7 for manet@ietf.org; Wed, 07 Nov 2007 18:55:52 -0500 Received: from aste-genev-bois-153-1-28-167.w83-112.abo.wanadoo.fr ([83.112.74.167] helo=[192.168.147.106]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1IpukP-000Gi4-5r for manet@ietf.org; Wed, 07 Nov 2007 23:55:49 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 83.112.74.167 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/1MkVwIoPwsgGZMWwJfPsF Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: manet From: Thomas Clausen Subject: RE: [manet] draft-ietf-manet-packetbb - WGLC Date: Thu, 8 Nov 2007 00:55:39 +0100 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On 7Nov , 2007, at 11:00 PM, Russ White wrote: > >> The short answer (and a short answer is all I have time for, it's >> 10:30PM here and I've still not had dinner yet....) to all of the >> below >> is that doing "half" (i.e. having some things be optional, or the >> type-space divided etc) accomplishes nothing in that one gets all the >> inconveniences (parsing can not guarantee anything re. unambiguity >> etc, >> nor can it be done linearly in a single pass etc.) with none of the >> benefits that the ordering and uniqueness constraints would otherwise >> have. I.e. having half gives us worse-than-nothing.... > > I strongly disagree. Doing it correctly actually gives you the best of > all worlds--those protocols that wish to use ordering can use it, and > those which do not don't use it. > And neither would get any benefits and none of the advantages but both would get the disadvantages in full. > I don't see ANY argument that shows how it's more efficient for a > protocol that does NOT want or need to use in order TLVs will be > accommidated in this proposal. As I have mentioned a number of times now, why would the order that a TLV appear encoded in a message be of any interest to the protocol, then? The encoding order would be 0, 1, 2, 3, 4, but RRP (Russ' Routing Protocol) could specify for itself that every Friday, except if it's full moon in which case it depends on the direction of the wind, the processing order should be 4, 2, 1, 3 and "0 should be ignored", and all other days the processing order would be 4, 3, 2, 1, 0. And this would be ENTIRELY up to the specification of RRP to state, of course. How would having the encoding-order in any way, shape or form impair on the ability of RRP to specify its own processing order? Keeping the encoding-order fixed in packetbb would be a great win for RRP -- for an implementer could grab a piece of generic code, for example that written by Chris, Justin or myself, and already be halfway through writing your protocol implementation. Also, that parser will be able to decode the packet/message for you in a single linear pass and provide you with a datastructure that you can process as you wish in any order you wish. For encoding-purposes, order and uniqueness can be done simply, if you have a bit of spare memory then through an array and you should be good to go in something like O(n) also (so no penalty in complexity there). I don't see ANY arguments that shows how this is more inefficient for a protocol. > In fact, I have a sneaking suspicion that > if this were to become a standard, it would result in a large > number of > threads where sentences like this are sent on list: "Well, our > proposal > is more efficient than yours with the standard (!) packet formatting > described in RFC XXXX, so the WG should adopt our proposal over yours, > no matter the other advantages and disadvantages." And the WG would then reasonably reply as above.... > >> And, as I have stated repeatedly, I have not seen any tangible >> benefits >> presented of making the ordering and uniqueness constraints go away >> presented that would outweigh the inconveniences in making them go >> away. >> Rather, removing these constraints complicate things greatly, as >> stated >> elsewhere. > > It complicates things for some protocols, and makes life easier for > others. > Would you be so kind as to explain to me how it complicates things for some protocols? By your own admission it "makes life easier" for some protocols -- but it has nowhere been made clear why it complicates life for others. Justin's point is excellent and so I will repeat it: > > The restriction of TLV order only restricts encoding/decoding and not > protocol processing which can happen in any order. > > The single TLV type value per address does not restrict TLVs to > carry only > one 'value' in the value field. TLV's can be defined to carry an > arbitrary > list of values in one value field which can be used however the > protocol > wishes. > >> So, since "half is worse than nothing", I'm firmly against "half". > > And I'm firmly against the whole. Either the WG finds a compromise, > or I > will oppose this draft through the entire process. And I think we > could > find enough opposition to squash this draft in it's entirety, in > the end. > I believe this comment to be entirely out of place. >>> I don't >>> understand why none of them have been considered before the draft >>> got to >>> the last call point, nor do I understand how the draft got to >>> last call >>> with this large of an issue outstanding. >> >> I will just add that I do not understand why this issue was only >> addressed only well AFTER (~ 20 days after) the WGLC of this I-D >> closed >> on July 24, and not in the two years preceding where this has been in >> place IN THE CURRENT FORM in the I-D and the I-D has been discussed >> widely within the MANET wg. > > Actually, I could go back quite a ways and point to emails I've > sent to > the list asking this specific question. According to the emails I have on my computer, the first email from you to MANET on this subject was August 13 2007 -- I have nothing before that. The WGLC ended July 24 2007 (if I recall correctly). Earlier than that, my archives contain no mention of this issue from anyone. > And I could point to multiple > emails from others stating the current draft is not acceptable. What I > don't understand, on the other hand, is how this got so far when there > were widely known and documented issues with it. > > Those emails were roundly ignored. If you ignore objections early > in the > process, then they tend to come back much more forcefully at the > end of > the process. > To my knowledge, the first objection(s) that were raised were raised by me in the Paris meeting :) -- but I was convinced eventually. The next objections that I saw raised were raised ~20 days AFTER the packetbb WGLC had closed, i.e. ~2 years after the Paris-meeting. Quickly consulting the mailing-list mails on my computer, as well as the WG meeting minutes, I see no evidence of this having been brought forward before, or else I or any of my co-authors should be aware hereof. I specifically note that none of these issues were brought forward during the WGLC. I do not appreciate the insinuation that these are objections which were raised early in the process and which were ignored. The objections that you present were, as far as I am aware, only raised very late in the process, specifically after the WGLC in the summer 2007. Which leads me to wonder -- again -- why this issue was brought up only so late in the process, that the WGLC had closed, and not before -- at least before or in the days immediately following the closure of the WGLC? Or, at the Chicago-meeting (also after the WGLC)? -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 18:58:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpumY-00064r-RM; Wed, 07 Nov 2007 18:58:02 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IpumW-00062P-EH for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 18:58:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpumW-00062H-4d for manet@ietf.org; Wed, 07 Nov 2007 18:58:00 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpumR-0007u1-Hj for manet@ietf.org; Wed, 07 Nov 2007 18:57:59 -0500 X-IronPort-AV: E=Sophos;i="4.21,387,1188792000"; d="scan'208";a="75428115" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 07 Nov 2007 18:57:54 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA7NvtVj016292; Wed, 7 Nov 2007 18:57:55 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA7NvtdQ010117; Wed, 7 Nov 2007 23:57:55 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 18:57:54 -0500 Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 18:57:54 -0500 Message-ID: <473250DC.8020407@cisco.com> Date: Wed, 07 Nov 2007 18:57:16 -0500 From: Russ White User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Justin Dean Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <200711072242.lA7MgQZw005079@s2.itd.nrl.navy.mil> In-Reply-To: <200711072242.lA7MgQZw005079@s2.itd.nrl.navy.mil> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Nov 2007 23:57:54.0379 (UTC) FILETIME=[034801B0:01C8219A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002 X-TM-AS-Result: No--4.091300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3660; t=1194479875; x=1195343875; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[manet]=20draft-ietf-manet-packetbb=20-=20WGLC |Sender:=20 |To:=20Justin=20Dean=20; bh=oteV8sL3JAceR93w+R2b9tKpELvAilzgCpDzwO0dfVs=; b=yTsJF+KYKaEW3J9jCU4eivH1KLgExvUInRDUZCyDWe4bBxFeyW68Y6jTH/kNdaml/HIRPU6a edkXJVDVMh3WfmU9BTCv2N406kD0JRXYVPMGHGgs02pkvcJUlIDNG2NX; Authentication-Results: rtp-dkim-2; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I would again like to reiterate that I honestly think there is A LOT of > confusion on what the restrictions actually restrict. I would like to ask > for solid examples of protocol behaviors which people feel are not possible > using the packetbb format. I feel a few good examples of what can be done > with the current format, will go a long way in illustrating what the TLV > restrictions are actually doing and what they are not doing. > > The restriction of TLV order only restricts encoding/decoding and not > protocol processing which can happen in any order. 1. You cannot hold items in a structure, and encode them in the structure order. You must always maintain your internal structure in the same order as the information in the packet is allowed to appear. 2. It's a bit disingenuous to say you can process things in any order, you just have to encode them and decode them in this order. If you must put them in the packet in a specific order, then you must process them in that order when building the packet. Since these are TLVs, and you cannot know where one TLV starts until you reach the end of the current TLV, you also cannot efficiently process the information in the packet, unless you process it in the order it's carried in the packet. > The single TLV type value per address does not restrict TLVs to carry only > one 'value' in the value field. TLV's can be defined to carry an arbitrary > list of values in one value field which can be used however the protocol > wishes. This means you cannot insert multiple copies of the same data (IE, multiple next hops, or multiples of anything) without creating a TLV with subTLVs for the pertinent information. Let me put it another way. If a protocol would like to process information in a specific order, there's nothing stopping it from specifying, in a standard that explains how to apply packetbb to the protocol, that the TLVs must be carried in a specific order. There is no reason to restrict all protocols to a specific order simply because it happens to make some protocols more efficient. Standards should not be unnecessarily restrictive, especially when they can apply to a wide range of protocols. Finally, forcing the order assumes that no possible optimization are ever possible beyond the ones that have been invented to this point, and covered in this specific draft. This is an unacceptable assumption on the part of the draft authors. There's more than just what we know today to consider. I understand that you don't think any of the examples or problems are problems--it makes one or two protocols more efficient, it doesn't appear to make the others less efficient, so we should go forth and conquer. When you show me in your crystal ball that it will never impact the performance of any possible protocol, and when you show me why the protocols that do benefit from this restriction cannot include this restriction in a separate draft, then I'll agree. Since my crystal ball broke last week, and since no-one can seem to offer a reason why these protocol specific restrictions couldn't be placed in a protocol specific draft, I don't see any reason to move forward with this draft. The packet ordering requirements in the packetbb draft aren't a good idea. Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMlDcER27sUhU9OQRAmIKAJ91M7gZbH9FLD8R6fD5tlOH4v2e1QCg8U3/ vrPpaNnL5UYmlCtTL5QHflk= =3gAX -----END PGP SIGNATURE----- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 19:06:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipuud-0007i9-LC; Wed, 07 Nov 2007 19:06:23 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ipuuc-0007i4-Nf for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 19:06:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipuuc-0007hw-Dy for manet@ietf.org; Wed, 07 Nov 2007 19:06:22 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpuuZ-0008RG-0y for manet@ietf.org; Wed, 07 Nov 2007 19:06:22 -0500 X-IronPort-AV: E=Sophos;i="4.21,387,1188792000"; d="scan'208";a="136308242" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Nov 2007 19:06:19 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA806IhX018861; Wed, 7 Nov 2007 19:06:18 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA805tWf021097; Thu, 8 Nov 2007 00:06:18 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 19:03:02 -0500 Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 19:03:02 -0500 Message-ID: <47325210.7050704@cisco.com> Date: Wed, 07 Nov 2007 19:02:24 -0500 From: Russ White User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Thomas Clausen Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: In-Reply-To: X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 00:03:02.0379 (UTC) FILETIME=[BADD13B0:01C8219A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002 X-TM-AS-Result: No--4.515300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2501; t=1194480378; x=1195344378; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[manet]=20draft-ietf-manet-packetbb=20-=20WGLC |Sender:=20 |To:=20Thomas=20Clausen=20; bh=u3x0e10uhSH3lgBgA1GoLg2uGD2UUpX5GrLWSi549DA=; b=WVXdF5SXl4o0U6IUG0BCJ191OtY+9F7MK4gtg0WhRJtfazekiT44Yr6BW+JyHqq92WrP3ztw H74UW8onz5Pr18E2d2P/JKFmO7iPwNi+92mgHWsMN331Qo9cQ0+uNbx8; Authentication-Results: rtp-dkim-2; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > And neither would get any benefits and none of the advantages but both > would get the disadvantages in full. Baloney. > As I have mentioned a number of times now, why would the order that a > TLV appear encoded in a message be of any interest to the protocol, then? Then why does it matter if it's in this draft? Why not put it in the drafts of the protocols that require this? > How would having the encoding-order in any way, shape or form impair on > the ability of RRP to specify its own processing order? *sigh* This is a red herring. The order of the TLVs in the packet necessarily determines the processing order, in any realistic implementation. > I don't see ANY arguments that shows how this is more inefficient for a > protocol. I don't see ANY arguments that shows how the required ordering will be more efficient for all possible protocols in all possible implementations. >> In fact, I have a sneaking suspicion that >> if this were to become a standard, it would result in a large number of >> threads where sentences like this are sent on list: "Well, our proposal >> is more efficient than yours with the standard (!) packet formatting >> described in RFC XXXX, so the WG should adopt our proposal over yours, >> no matter the other advantages and disadvantages." > > And the WG would then reasonably reply as above.... But it would be too late, wouldn't it, because, after all--the packet format is now a standard. You seem awful eager to limit future innovation in favor of a current protocol, for some reason. Particularly when that packet ordering could easily be specified elsewhere--in the protocol specific draft--if it's so important. >> And I'm firmly against the whole. Either the WG finds a compromise, or I >> will oppose this draft through the entire process. And I think we could >> find enough opposition to squash this draft in it's entirety, in the end. >> > > I believe this comment to be entirely out of place. I believe it's entirely in place, since I'm a member of the routing area directorate, and someone who works for a large implementor of such protocols. Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMlIQER27sUhU9OQRAhC8AKDDJNG7LCnZQU+tq5WfCFbXl/F3DwCfZ/Ci cKWmf/hsFKMkfGvcddOqf8U= =Xybk -----END PGP SIGNATURE----- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 19:12:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipv0H-00034S-89; Wed, 07 Nov 2007 19:12:13 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ipv0G-000349-6x for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 19:12:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipv0F-000333-Q6 for manet@ietf.org; Wed, 07 Nov 2007 19:12:11 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipv0C-0000Cf-Bv for manet@ietf.org; Wed, 07 Nov 2007 19:12:11 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA80BiQq006521; Thu, 8 Nov 2007 02:12:05 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 02:12:04 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 18:11:58 -0600 Received: from [172.18.141.152] ([172.18.141.152]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 18:11:58 -0600 Message-ID: <47325447.1090307@nokia.com> Date: Wed, 07 Nov 2007 16:11:51 -0800 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <7FB7EE0A621BA44B8B69E5F0A09DC76404E7856E@xmb-rtp-208.amer.cisco.com> <548143B0-4F31-4921-A29E-E119B868153D@thomasclausen.org> In-Reply-To: <548143B0-4F31-4921-A29E-E119B868153D@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 00:11:58.0331 (UTC) FILETIME=[FA50DCB0:01C8219B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Ian, Clearly, I disagree with Thomas. I believe that packetBB must be considered as applicable to not only current specifications, but also specifications that may be important for future work in [manet]. Sufficient objections have been raised to indicate that the mandates should be softened. This can be done in a way that would not represent any significant delay to the progress of the document, once agreement in principle is obtained on the wisdom of relaxing the mandate. Regards, Charlie P. ext Thomas Clausen wrote: > Ian, > > I suggest that the arguments presented for changing the mandates from > MUST to MAY have been insufficient, and that the consequences of doing > so have not been fully considered by the proponents of this change. > > I furthermore note that the current mandates in packetbb in no way is > limiting the applicability within the intended problem domain of MANET > protocols, and that therefore -- given the benefits which have been > presented elsewhere -- it is timely to move forward with this I-D > towards publication. > > Regards, > > Thomas > > > On 7Nov , 2007, at 8:25 PM, Stan Ratliff (sratliff) wrote: > >> Ian, >> >> I agree with Charlie's recommendation. >> >> Regards, >> Stan >> >> >>> -----Original Message----- >>> From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >>> Sent: Wednesday, November 07, 2007 2:16 PM >>> To: ext Ian Chakeres >>> Cc: manet >>> Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC >>> >>> >>> Hello Ian, >>> >>> I think that the document is not ready for publication until the >>> mandates for uniqueness and ordering of address TLVs are >>> softened to MAY. Text should be added to indicate that >>> individual protocols that conform to packetBB can mandate >>> the use need for this feature if so desired. >>> >>> Regards, >>> Charlie P. >>> >>> >>> ext Ian Chakeres wrote: >>>> This note announces the WG Last Call for comments on >>>> draft-ietf-manet-packetbb-10.txt, "Generalized MANET Packet/Message >>>> Format". >>>> >>>> The document can be found at: >>>> http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-10.txt >>>> >>>> The document is intended to be submitted for publication as >>> a proposed >>>> standard document. >>>> >>>> Please review the document carefully and send your comments to the >>>> MANET list and document authors. >>>> >>>> Given the relatively minor recent changes (added version. >>> added packet >>>> size. added special IANA alloc for TLV types 0 to 7.), this last call >>>> will end Wed Nov 14th AOE. >>>> >>>> Thanks, >>>> Ian Chakeres >>>> >>>> >>>> _______________________________________________ >>>> manet mailing list >>>> manet@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/manet >>>> >>> >>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >>> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet >> > > --Thomas Clausen > Thomas@thomasclausen.org > http://www.thomasclausen.org/ > http://hipercom.thomasclausen.org/ > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 19:36:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpvNb-0000NY-Fh; Wed, 07 Nov 2007 19:36:19 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IpvNZ-0000L1-Hv for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 19:36:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpvNZ-0000Kt-1Z for manet@ietf.org; Wed, 07 Nov 2007 19:36:17 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpvNU-0000un-Kf for manet@ietf.org; Wed, 07 Nov 2007 19:36:17 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA80a2li004896; Thu, 8 Nov 2007 02:36:10 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 02:36:08 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 18:36:06 -0600 Received: from [172.18.141.152] ([172.18.141.152]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 18:36:06 -0600 Message-ID: <473259F5.4070503@nokia.com> Date: Wed, 07 Nov 2007 16:36:05 -0800 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Thomas Clausen Subject: Re: [manet] (no subject) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 00:36:06.0234 (UTC) FILETIME=[595553A0:01C8219F] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Thomas, ext Thomas Clausen wrote: > > The short answer (and a short answer is all I have time for, it's > 10:30PM here and I've still not had dinner yet....) to all of the > below is that doing "half" (i.e. having some things be optional, or > the type-space divided etc) accomplishes nothing in that one gets all > the inconveniences (parsing can not guarantee anything re. unambiguity > etc, nor can it be done linearly in a single pass etc.) with none of > the benefits that the ordering and uniqueness constraints would > otherwise have. I.e. having half gives us worse-than-nothing.... If the protocol specification tells the parser to enforce the constraints, then why cannot the protocol processing rely on the parser enforcing the constraints? I really don't see this argument at all. I'd give it 0.01 out of ten. > > > And, as I have stated repeatedly, I have not seen any tangible > benefits presented of making the ordering and uniqueness constraints > go away presented that would outweigh the inconveniences in making > them go away. Rather, removing these constraints complicate things > greatly, as stated elsewhere. It would only require that the protocols themselves specify the constraints. This is not complicating things "greatly". > > So, since "half is worse than nothing", I'm firmly against "half". I think your premise is very difficult to accept, thus I cannot be sympathetic about your conclusion. > > Since the benefits of not having the constraints are unclear but the > inconveniences are quite considerable, whereas having the constraints > presents considerable benefits with little or no inconveniences, then > I see no reasons not to maintain and move forward with the constraints > in place. I think it is very handy that you have admitted that the inconveniences are quite considerable. I also think that any protocol designer that wanted the constraints would be _delighted_ to find that they were already properly available as a packetBB optional feature. What is wrong with this picture? I just don't see why packetBB has to mandate something to protect against the future contingency that some protocol designers might not take their medicine. Yuck! > >> I honestly think there is still a lot of misunderstanding on what is and >> isn't possible with the current design. Most examples which use >> packetbb >> layout but require a relaxation of the restrictions, seem to me, not to >> actually require restrictions being lifted if a different TLV >> design/layout >> is used. And in most cases I have thought about the new design is often >> just as efficient and almost always less ambiguous. I presented a [1..googolplex] example to show that any design one can really imagine would be specifiable under packetBB. This does not make it a good thing. And, to the extent that the design departs from the logical framework in which the designers understands their problem space, it is a bad thing even apart from the inconvenience. Any example I would propose would immediately become a puzzle for the packetBB authors to redefine in a way that is compliant to the ordering constraints. What fun and all, but really missing the point that they belong properly in the protocol specification, not the metaprotocol specification. > > Finaly, to pound back at Russ' last sentence, which went: > >> I don't >> understand why none of them have been considered before the draft got to >> the last call point, nor do I understand how the draft got to last call >> with this large of an issue outstanding. > > I will just add that I do not understand why this issue was only > addressed only well AFTER (~ 20 days after) the WGLC of this I-D > closed on July 24, and not in the two years preceding where this has > been in place IN THE CURRENT FORM in the I-D and the I-D has been > discussed widely within the MANET wg. Here is one area where you can fault me. But I was under the impression that reviews were earnestly solicited, whether or not the reviewers had done their homework for the previous year. Perhaps it was not really the case that close reviews were desired. > > While the design was still wide open might just have been the time to > address this -- not weeks AFTER a WGLC of an essentially done and > widely implemented specification. So one clearly wonders why this was > brought forward at such a late time.... On the other hand, it is true that the constraints were stuck in there without much fanfare and, as far as I can tell, zero motivation derived from mailing list discussion. > > And now, off to the bbq pork roast (which, if it's burned, I'll blame > on y'all) -- until tomorrow ;) Wow, I had leftovers. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 07 20:53:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipwaf-0001Af-AH; Wed, 07 Nov 2007 20:53:53 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ipwae-00017x-B3 for manet-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 20:53:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipwae-000178-12 for manet@ietf.org; Wed, 07 Nov 2007 20:53:52 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ipwab-0003M4-Nh for manet@ietf.org; Wed, 07 Nov 2007 20:53:52 -0500 X-IronPort-AV: E=Sophos;i="4.21,387,1188792000"; d="scan'208";a="136314596" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 07 Nov 2007 20:53:47 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA81rl6s019707; Wed, 7 Nov 2007 20:53:47 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA81rYdk010827; Thu, 8 Nov 2007 01:53:47 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 20:52:21 -0500 Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 20:52:21 -0500 Message-ID: <47326BAE.4050008@cisco.com> Date: Wed, 07 Nov 2007 20:51:42 -0500 From: Russ White User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <7FB7EE0A621BA44B8B69E5F0A09DC76404E7856E@xmb-rtp-208.amer.cisco.com> <548143B0-4F31-4921-A29E-E119B868153D@thomasclausen.org> <47325447.1090307@nokia.com> In-Reply-To: <47325447.1090307@nokia.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 01:52:21.0301 (UTC) FILETIME=[00492650:01C821AA] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15530.002 X-TM-AS-Result: No--13.644300-8.000000-4 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=967; t=1194486827; x=1195350827; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[manet]=20draft-ietf-manet-packetbb=20-=20WGLC |Sender:=20 |To:=20=22Charles=20E.=20Perkins=22=20; bh=LDknPPQ2WObBKSUmM149jowmHU5qsp8crzyIr5yHhHg=; b=KgzaJ9FhEDs0xNqzOn4pWlWQ46X4WT2HKDs2OLXvBBgl/05iNvHZ9YJuokIm2NKb28oVM6pO DteHNSjFdDM1g5r2XTt0X2RlnMulwHdDsCIJ46aMvcozKJCTKEpOhM2c; Authentication-Results: rtp-dkim-2; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Sufficient objections have been raised to indicate that the > mandates should be softened. This can be done in a way > that would not represent any significant delay to the progress > of the document, once agreement in principle is obtained on > the wisdom of relaxing the mandate. I completely agree with this, and would like to see a "mailing list hum" on this.... There appears to be a very small group of people involved in the discussion, but I'm getting some off list email supporting this position. I'd like to see what the real concensus looks like, and not just a small group of folks discussing it. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHMmuuER27sUhU9OQRAupgAJ9oTii42YPlO3odtcyYMXK8BMbMvwCdEWtS JAVQG6QkY84yM4pIUx7QGRc= =zEow -----END PGP SIGNATURE----- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 08 03:30:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq2mp-0008Uc-IE; Thu, 08 Nov 2007 03:30:51 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iq2mn-0008Tb-Ug for manet-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 03:30:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq2mm-0008TS-UI for manet@ietf.org; Thu, 08 Nov 2007 03:30:48 -0500 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq2mj-0005BJ-LJ for manet@ietf.org; Thu, 08 Nov 2007 03:30:48 -0500 Received: by nf-out-0910.google.com with SMTP id d21so46139nfb for ; Thu, 08 Nov 2007 00:30:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=sjpGOxzdcDhOUnAfCjx/9Nz8Bu4B/pBzJdKPEfngU/g=; b=Wp8rOAy9bJnJjUEp4v7OB35AemoEVM8ewhqZrdppZxUqBobi7OD8mkuw6EnhyFLnevNYERyJxbY5hF3akaoB8wJmpLxen0/O60JqSxkBzE4hGUk2gxecTxPEgbNGqrLjT2ef5cMna854HSmkxGSK8Io/sMiVeVP81mt9ki5vmfk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=BNN872cKrbMVEvIWrChmooVWzHDahgUQRr+eXL6zdXWRn78bo9DNo8vZ7BImYld2MCozNTMD9Kjb6ROvPP6tmKz3YObtcK7O+GAbAfG7FF7oJylLHBI00Ye36CSJitDAoQH17WGyZSwPVmZG0Dl6DGTL74I4oaTJME50uxG9qiM= Received: by 10.78.21.7 with SMTP id 7mr235237huu.1194510644611; Thu, 08 Nov 2007 00:30:44 -0800 (PST) Received: by 10.78.19.9 with HTTP; Thu, 8 Nov 2007 00:30:44 -0800 (PST) Message-ID: <374005f30711080030t15fea95ex2c26e0214683cc9f@mail.gmail.com> Date: Thu, 8 Nov 2007 14:00:44 +0530 From: "Ian Chakeres" To: manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 3.6 (+++) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [manet] PacketBB X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thanks to everyone for the lively discussion about PacketBB. Regarding the constraints issue, I think we are at an impasse between conflicting opinions. Joe and I will talk about the best way to proceed on this issue and make a recommendation next week. Independently, I would like to encourage people to perform a final review PacketBB, and bring forward any other technical issues during WGLC. Thank you, Ian Chakeres "Progress is impossible without change, and those who cannot change their minds cannot change anything." - Shaw _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 08 12:03:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAmA-0006mr-7B; Thu, 08 Nov 2007 12:02:42 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqAm8-0006mf-6c for manet-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 12:02:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAm7-0006lz-Sw for manet@ietf.org; Thu, 08 Nov 2007 12:02:39 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqAm4-0003mD-2U for manet@ietf.org; Thu, 08 Nov 2007 12:02:39 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lA8H2X4Q009843 for ; Thu, 8 Nov 2007 12:02:33 -0500 (EST) Message-Id: <200711081702.lA8H2X4Q009843@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007110812023325734 for ; Thu, 08 Nov 2007 12:02:33 -0500 From: "Justin Dean" To: "'Manet'" Subject: RE: [manet] draft-ietf-manet-packetbb - WGLC Date: Thu, 8 Nov 2007 12:07:58 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Acghmgc6QMLjpPTeR8eI612e7K7o1QAgAVQgAAJ30OA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Spam-Score: 1.5 (+) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline > -----Original Message----- > From: Russ White [mailto:riw@cisco.com] > Sent: Wednesday, November 07, 2007 6:57 PM > To: Justin Dean > Cc: 'Manet' > Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > I would again like to reiterate that I honestly think there > is A LOT > > of confusion on what the restrictions actually restrict. I > would like > > to ask for solid examples of protocol behaviors which > people feel are > > not possible using the packetbb format. I feel a few good > examples of > > what can be done with the current format, will go a long way in > > illustrating what the TLV restrictions are actually doing > and what they are not doing. > > > > The restriction of TLV order only restricts > encoding/decoding and not > > protocol processing which can happen in any order. > > 1. You cannot hold items in a structure, and encode them in the > structure order. You must always maintain your internal structure in > the same order as the information in the packet is allowed to appear. > Well yes and no but I think this comment comes at the heart of what might be confusing. You can't hold items in an arbitrary structure order and encode them in that order directly. I agree with that. But to say that you must maintain the internal structure order in the same order in which packets will be encoding seems wrong to me. Its quite easy to encoded in any random order regardless of the structure order. Transformation of the information needs to take place to build the TLV in any case so even it were in order a straight mapping of a data structure into a TLV would not really be practical unless it were in a single value field and in which case its perfectly okay to do so. Packet.AddTlv(mystruct.a); Packet.AddTlv(mystruct.b); Packet.AddTlv(mystruct.c); Is no harder than. Packet.AddTlv(mystruct.c); Packet.AddTlv(mystruct.b); Packet.AddTlv(mystruct.a); > 2. It's a bit disingenuous to say you can process things in any order, > you just have to encode them and decode them in this order. This I partly agree with although the encoding part should be trivial. Decoding I will talk abut more. > If you must put them in the packet in a specific order, then you must > process them in that order when building the packet. Since these are > TLVs, and you cannot know where one TLV starts until you reach the end > of the current TLV, you also cannot efficiently process the > information in the packet, unless you process it in the order it's > carried in the packet. It really depends on the data being transmitted. With MOST of the proposed TLV definitions the order in which they are processed does not matter either the entire packet needs to be processed or there is no harm in processing the data which has so far arrived. There are a few which should come before others in terms of processing on the receiving end we the space was split up to accommodate this type of behavior. > > The single TLV type value per address does not restrict > TLVs to carry > > only one 'value' in the value field. TLV's can be defined > to carry an > > arbitrary list of values in one value field which can be > used however > > the protocol wishes. > > This means you cannot insert multiple copies of the same data (IE, > multiple next hops, or multiples of anything) without creating a TLV > with subTLVs for the pertinent information. > This is a misconception. You can insert multiple copies of similar data (I use "similar" instead of same as I think its was meant, multiples of the same data would be better represented by a single value and a number) using a single TLV without using the subTLV area. One just has to define their TLV's value field to carry the list of information instead of a single value. Packetbb allows this list to be defined in a variable length fashion. The advantage of this is that a protocol can use the information in whatever way makes sense and even lowers the TLV overhead from including multiples of the same TLV. > Let me put it another way. If a protocol would like to process > information in a specific order, there's nothing stopping it from > specifying, in a standard that explains how to apply packetbb to the > protocol, that the TLVs must be carried in a specific order. There is > no reason to restrict all protocols to a specific order simply because > it happens to make some protocols more efficient. Standards should not > be unnecessarily restrictive, especially when they can apply to a wide > range of protocols. This I think hits very close to the difference of opinion. Packetbb and the TLV structure was designed in such a way in that the information contained within the packet (other than the address block) does not rely on ordering. > > Finally, forcing the order assumes that no possible optimization are > ever possible beyond the ones that have been invented to this point, > and covered in this specific draft. > This is an unacceptable assumption on the part of the draft authors. > There's more than just what we know today to consider. > > I understand that you don't think any of the examples or problems are > problems--it makes one or two protocols more efficient, it doesn't > appear to make the others less efficient, so we should go forth and > conquer. When you show me in your crystal ball that it will never > impact the performance of any possible protocol, and when you show me > why the protocols that do benefit from this restriction cannot include > this restriction in a separate draft, then I'll agree. > I guess this is kind of the point. We can't predict the future but we do have some real examples which have gains. I have repeatedly asked for specific examples using packetbb on what one would like to do but can't because of the restrictions and am still looking forward to seeing some. I haven't ever argued that there is no tradeoff, indeed there will be some efficiently loses for certain types of wanted behaviors but as they are as of yet unspecified. Going with what is best for the current specified protocols seems to me to be the correct course of action. > Since my crystal ball broke last week, and since no-one can seem to > offer a reason why these protocol specific restrictions couldn't be > placed in a protocol specific draft, I don't see any reason to move > forward with this draft. > I somewhat agree with Thomas that this gives in many cases the worst of both worlds and reduces the gains of each. However this or some other similar compromise may be the only way forward although to me it greatly reduces the benefits. > The packet ordering requirements in the packetbb draft aren't a good > idea. > I will try to remain open minded to be convinced of this. I have also not given up trying to convince everyone otherwise. Justin > Russ > > - -- > riw@cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFHMlDcER27sUhU9OQRAmIKAJ91M7gZbH9FLD8R6fD5tlOH4v2e1QCg8U3/ > vrPpaNnL5UYmlCtTL5QHflk= > =3gAX > -----END PGP SIGNATURE----- > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 08 12:15:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAyb-0001ae-4s; Thu, 08 Nov 2007 12:15:33 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqAyZ-0001ZA-1U for manet-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 12:15:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqAyY-0001Yy-M1 for manet@ietf.org; Thu, 08 Nov 2007 12:15:30 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqAyY-0005ug-3V for manet@ietf.org; Thu, 08 Nov 2007 12:15:30 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lA8HFQrx010502 for ; Thu, 8 Nov 2007 12:15:26 -0500 (EST) Message-Id: <200711081715.lA8HFQrx010502@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007110812152525823 for ; Thu, 08 Nov 2007 12:15:25 -0500 From: "Justin Dean" To: "'Manet'" Subject: RE: [manet] (no subject) Date: Thu, 8 Nov 2007 12:20:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Acghn5fHqqpJIUqGT0SC7EjqzKboJwAiqfbw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <473259F5.4070503@nokia.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > Sent: Wednesday, November 07, 2007 7:36 PM > To: ext Thomas Clausen > Cc: manet > Subject: Re: [manet] (no subject) > >> I honestly think there is still a lot of misunderstanding > on what is and > >> isn't possible with the current design. Most examples which use > >> packetbb > >> layout but require a relaxation of the restrictions, seem > to me, not to > >> actually require restrictions being lifted if a different TLV > >> design/layout > >> is used. And in most cases I have thought about the new > design is often > >> just as efficient and almost always less ambiguous. > > I presented a [1..googolplex] example to show that any design > one can really imagine would be specifiable under packetBB. > This does not make it a good thing. And, to the extent that the > design departs from the logical framework in which the designers > understands their problem space, it is a bad thing even apart > from the inconvenience. > The [1..googolplex] is a straw mans argument. I am sure we can both agree that although possible it is a bad idea on how packetbb should be used for almost any set of information. I am much more interested in talking/discussing/exploring encoding methods using packetbb with, and without, the restrictions, using encodings which would actually be used. I feel this would help demonstrate the REAL possible effects due to the restrictions. > Any example I would propose would immediately become a > puzzle for the packetBB authors to redefine in a way that > is compliant to the ordering constraints. What fun and all, > but really missing the point that they belong properly in the > protocol specification, not the metaprotocol specification. > > I am sorry you feel this way but specific examples are exactly what I would need to be convinced that the restrictions are a bad idea. I also feel that these "puzzles" would be good for the community to see what is actually possible with the restrictions still in place and how they really are not that restrictive. Furthermore I have a hunch that the ending result would be just as efficient if not possibly more so within the packetbb framework. If I am wrong well that would be constructive as well. Justin > > Regards, > Charlie P. > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 08 12:19:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqB2H-0005fv-5R; Thu, 08 Nov 2007 12:19:21 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqB2F-0005fm-8v for manet-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 12:19:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqB2D-0005da-Qi for manet@ietf.org; Thu, 08 Nov 2007 12:19:18 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqB2C-00064n-Es for manet@ietf.org; Thu, 08 Nov 2007 12:19:17 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA8HIuvE025367; Thu, 8 Nov 2007 19:19:12 +0200 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 19:18:55 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 11:18:47 -0600 Received: from [10.162.57.108] ([10.162.57.108]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 11:18:46 -0600 Message-ID: <473344ED.2060500@nokia.com> Date: Thu, 08 Nov 2007 09:18:37 -0800 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Justin Dean Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <200711081702.lA8H2X4Q009843@s2.itd.nrl.navy.mil> In-Reply-To: <200711081702.lA8H2X4Q009843@s2.itd.nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 17:18:46.0960 (UTC) FILETIME=[6BEB9B00:01C8222B] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Justin, I have made some examples to show useful constructions that are disallowed by packetBB. Here is one. Assume there are address ranges R1:=[A1,A3] and R2 := [A2,A4], where A1 < A2 < A3 < A4. Suppose that for address in range R1, we want to ascribe characteristic X1 [e.g., a service, or a multicast address, or any one of an un-knowable number of values of some type]. And then for addresses in range R2, we want to assign from the same type, characteristic X2. As I understand it, this is not possible. The type value might even be a structure, of length hundreds of bytes (e.g., a certificate). This would be wrong to duplicate just because of the unwanted packetBB constraints. Regards, Charlie P. ext Justin Dean wrote: > Comments inline > > >> -----Original Message----- >> From: Russ White [mailto:riw@cisco.com] >> Sent: Wednesday, November 07, 2007 6:57 PM >> To: Justin Dean >> Cc: 'Manet' >> Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> >>> I would again like to reiterate that I honestly think there >>> >> is A LOT >> >>> of confusion on what the restrictions actually restrict. I >>> >> would like >> >>> to ask for solid examples of protocol behaviors which >>> >> people feel are >> >>> not possible using the packetbb format. I feel a few good >>> >> examples of >> >>> what can be done with the current format, will go a long way in >>> illustrating what the TLV restrictions are actually doing >>> >> and what they are not doing. >> >>> The restriction of TLV order only restricts >>> >> encoding/decoding and not >> >>> protocol processing which can happen in any order. >>> >> 1. You cannot hold items in a structure, and encode them in the >> structure order. You must always maintain your internal structure in >> the same order as the information in the packet is allowed to appear. >> >> > Well yes and no but I think this comment comes at the heart of what might be > confusing. You can't hold items in an arbitrary structure order and encode > them in that order directly. I agree with that. But to say that you must > maintain the internal structure order in the same order in which packets > will be encoding seems wrong to me. Its quite easy to encoded in any random > order regardless of the structure order. Transformation of the information > needs to take place to build the TLV in any case so even it were in order a > straight mapping of a data structure into a TLV would not really be > practical unless it were in a single value field and in which case its > perfectly okay to do so. > > Packet.AddTlv(mystruct.a); > Packet.AddTlv(mystruct.b); > Packet.AddTlv(mystruct.c); > Is no harder than. > Packet.AddTlv(mystruct.c); > Packet.AddTlv(mystruct.b); > Packet.AddTlv(mystruct.a); > > > >> 2. It's a bit disingenuous to say you can process things in any order, >> you just have to encode them and decode them in this order. >> > This I partly agree with although the encoding part should be trivial. > Decoding I will talk abut more. > > >> If you must put them in the packet in a specific order, then you must >> process them in that order when building the packet. Since these are >> TLVs, and you cannot know where one TLV starts until you reach the end >> of the current TLV, you also cannot efficiently process the >> information in the packet, unless you process it in the order it's >> carried in the packet. >> > > It really depends on the data being transmitted. With MOST of the proposed > TLV definitions the order in which they are processed does not matter either > the entire packet needs to be processed or there is no harm in processing > the data which has so far arrived. There are a few which should come before > others in terms of processing on the receiving end we the space was split up > to accommodate this type of behavior. > > > >>> The single TLV type value per address does not restrict >>> >> TLVs to carry >> >>> only one 'value' in the value field. TLV's can be defined >>> >> to carry an >> >>> arbitrary list of values in one value field which can be >>> >> used however >> >>> the protocol wishes. >>> >> This means you cannot insert multiple copies of the same data (IE, >> multiple next hops, or multiples of anything) without creating a TLV >> with subTLVs for the pertinent information. >> >> > This is a misconception. You can insert multiple copies of similar data (I > use "similar" instead of same as I think its was meant, multiples of the > same data would be better represented by a single value and a number) using > a single TLV without using the subTLV area. One just has to define their > TLV's value field to carry the list of information instead of a single > value. Packetbb allows this list to be defined in a variable length > fashion. The advantage of this is that a protocol can use the information > in whatever way makes sense and even lowers the TLV overhead from including > multiples of the same TLV. > > >> Let me put it another way. If a protocol would like to process >> information in a specific order, there's nothing stopping it from >> specifying, in a standard that explains how to apply packetbb to the >> protocol, that the TLVs must be carried in a specific order. There is >> no reason to restrict all protocols to a specific order simply because >> it happens to make some protocols more efficient. Standards should not >> be unnecessarily restrictive, especially when they can apply to a wide >> range of protocols. >> > > This I think hits very close to the difference of opinion. Packetbb and the > TLV structure was designed in such a way in that the information contained > within the packet (other than the address block) does not rely on ordering. > > > >> Finally, forcing the order assumes that no possible optimization are >> ever possible beyond the ones that have been invented to this point, >> and covered in this specific draft. >> This is an unacceptable assumption on the part of the draft authors. >> There's more than just what we know today to consider. >> >> I understand that you don't think any of the examples or problems are >> problems--it makes one or two protocols more efficient, it doesn't >> appear to make the others less efficient, so we should go forth and >> conquer. When you show me in your crystal ball that it will never >> impact the performance of any possible protocol, and when you show me >> why the protocols that do benefit from this restriction cannot include >> this restriction in a separate draft, then I'll agree. >> >> > I guess this is kind of the point. We can't predict the future but we do > have some real examples which have gains. I have repeatedly asked for > specific examples using packetbb on what one would like to do but can't > because of the restrictions and am still looking forward to seeing some. I > haven't ever argued that there is no tradeoff, indeed there will be some > efficiently loses for certain types of wanted behaviors but as they are as > of yet unspecified. Going with what is best for the current specified > protocols seems to me to be the correct course of action. > > > >> Since my crystal ball broke last week, and since no-one can seem to >> offer a reason why these protocol specific restrictions couldn't be >> placed in a protocol specific draft, I don't see any reason to move >> forward with this draft. >> >> > I somewhat agree with Thomas that this gives in many cases the worst of both > worlds and reduces the gains of each. However this or some other similar > compromise may be the only way forward although to me it greatly reduces the > benefits. > > >> The packet ordering requirements in the packetbb draft aren't a good >> idea. >> >> > I will try to remain open minded to be convinced of this. I have also not > given up trying to convince everyone otherwise. > > Justin > >> Russ >> >> - -- >> riw@cisco.com CCIE <>< Grace Alone >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (MingW32) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> iD8DBQFHMlDcER27sUhU9OQRAmIKAJ91M7gZbH9FLD8R6fD5tlOH4v2e1QCg8U3/ >> vrPpaNnL5UYmlCtTL5QHflk= >> =3gAX >> -----END PGP SIGNATURE----- >> >> > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 08 12:38:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBKK-0001Qc-Pp; Thu, 08 Nov 2007 12:38:00 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqBKJ-0001OC-Cm for manet-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 12:37:59 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBKJ-0001O2-1r for manet@ietf.org; Thu, 08 Nov 2007 12:37:59 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqBKI-0006pQ-E5 for manet@ietf.org; Thu, 08 Nov 2007 12:37:58 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA8HbnWo001705 for ; Thu, 8 Nov 2007 19:37:56 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 19:37:55 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 11:37:47 -0600 Received: from [10.162.57.108] ([10.162.57.108]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 11:37:46 -0600 Message-ID: <47334960.1070101@nokia.com> Date: Thu, 08 Nov 2007 09:37:36 -0800 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Charles E. Perkins" References: <473259F5.4070503@nokia.com> In-Reply-To: <473259F5.4070503@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 17:37:47.0278 (UTC) FILETIME=[139A52E0:01C8222E] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: manet Subject: [manet] Something I mis-read in Thomas's earlier message... X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello folks, In the voluminous exchanges from yesterday, I mis-took the sense of something written by Thomas: Charles E. Perkins wrote: > >> >> Since the benefits of not having the constraints are unclear but the >> inconveniences are quite considerable, whereas having the constraints >> presents considerable benefits with little or no inconveniences, then >> I see no reasons not to maintain and move forward with the >> constraints in place. > > I think it is very handy that you have admitted that the inconveniences > are quite considerable. ... I see now that Thomas meant something other than the meaning I derived during my too-quick read of this sentence. Please excuse my confusion -- but reading through the rest of that email I reckon that I did not make any further use of this small thought anyway. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 08 13:13:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBsh-0008KZ-1V; Thu, 08 Nov 2007 13:13:31 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqBsf-0008HL-Io for manet-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 13:13:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBsf-0008HB-93 for manet@ietf.org; Thu, 08 Nov 2007 13:13:29 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqBsZ-0006TT-F1 for manet@ietf.org; Thu, 08 Nov 2007 13:13:29 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lA8IDJw1013382; Thu, 8 Nov 2007 13:13:22 -0500 (EST) Message-Id: <200711081813.lA8IDJw1013382@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007110813132226149 ; Thu, 08 Nov 2007 13:13:22 -0500 From: "Justin Dean" To: "'Charles E. Perkins'" Subject: RE: [manet] draft-ietf-manet-packetbb - WGLC Date: Thu, 8 Nov 2007 13:18:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcgiK4DOsitmscEqSpaBf/tOyv5WuQAATjoA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <473344ED.2060500@nokia.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: a5d64674af3d12893846a18a44c07b83 Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Great! I think you beat me to my one reply which now makes it look silly well done! Good example by the way. First I would like to separate the issue into two different problems as I am not sure what information is meant to be conveyed. Does the sender want the "second" TLV to override the first or be part of a list? Which are correct? A1 = [X1], A2 = [X2], A3 = [X2], A4 = [X2] Or A1 = [X1], A2 = [X1,X2], A3 = [X1,X2], A4 = [X2] The first situation where the information (X2) is meant to override the first type (X2) of information could be encoded in various ways here are a few: 1) Use a multivalue TLV, mTLV1 for the entire range R mTLV1 R = [X1,X2,X2,X2]. Overhead grows with size of the set however. But for this example there is only one TLV overhead cost. 2) Use a combination of a single TLV, TLV1, for the first entry and a single multivalue TLV, mTLV1 with one value for the range R2. TLV1 A1 = [X1] mTLV1 R2 = [X2] (note the difference between this multivalue, one value, and the previous, value for each entry, both are allowed) This has the overhead of 2 different TLVs but does not encode multiple X2 values. The growth is slower because of this as well as long as X2 remains the value for the addresses in that order. Both of the above examples use only one TLV type of which does not need to use the full type. 3) Another way which would use more than one TLV type but would more closely resemble what you are doing would be to define two TLVs. The first TLV would be defined the same, it ascribes characteristic X to an address A or range R. The second one TLV2 would be similar but different in meaning, it would convey the "no X is really this" TLV which by definition overrides the first defined TLV One could then use mTLV1 R1 = [X1] mTLV2 R2 = [X2] The drawback with this is that a TLV type for each really in the "no REALLY REALLY" would have to be defined. Sub types would work well in this case although if only one was needed (and I honestly don't see more than 2 actually being useful) then 2 separate TLVs types could be assigned. This last example would work exactly the same as with no restrictions except that you would define two TLVs for use. And in fact the order within the packet does not change the meaning of the information, being conveyed. These are just 3 examples and there are many more ways of encoding this type of information. The second situation is similar but very different in meaning. Here are a few examples of how one could encode the information using packetbb. 1) One could simply use single TLVs with the values to be associated with the addresses. TLV1 A1 = [X1] TLV1 A2 = [X1,X2] TLV1 A3 = [X1,X2] TLV1 A4 = [X2] There is a TLV overhead for each address which has a value when using this method but its simple and straight forward. 2) Use 2 single TLVs and one multivalue TLVs defined such that TLV1 A1 = [X1] mTLV1 R3 = [X1,X2] (this TLV would be defined in such a way that there is only a single value to be mapped to each address in R3, R3:=[A2,A3] TLV A4 = [X2] There is less overhead in this example rather than the first in that there is one less TLV and the shared information is only included once. 3) Again similar to the last example I gave further up a second TLV could be defined (TLV3 so as not to conflict with TLV2 above) which conveys the meaning "these values as well" or even "not really these values" to subtract entries. For this example "these values as well" TLV3 is used. mTLV1 R1 = [X1] mTLV3 R2 = [X2] Notice how the layout is the same as in the last example for the first situation and indeed Charlie's initial example as well, but the definition of the TLV2 and TLV3 explicitly state what the meaning of the information is. There is a draw back when adding in multiple passes require more TLVs but again I see diminishing returns on having more than 1 level of addition. I feel these are good examples of what can be done but are by no means exhaustive. I hope that it helps illustrate what behaviors are allowed and furthermore demonstrates the explicitness of the information being conveyed, even without protocol knowledge, by conforming to the restrictions allows. More complicated examples can lead to more complicated solutions for certain. I am sure there is enough flexibility within the current draft, that papers can be written on how to best optimize encoding of information within packetbb. I would like to thank you Charlie for giving me this example to work with. Justin > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > Sent: Thursday, November 08, 2007 12:19 PM > To: ext Justin Dean > Cc: 'Manet' > Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC > > > Hello Justin, > > I have made some examples to show useful constructions that > are disallowed by packetBB. > Here is one. > > Assume there are address ranges R1:=[A1,A3] and R2 := > [A2,A4], where A1 < A2 < A3 < A4. > Suppose that for address in range R1, we want to ascribe > characteristic X1 [e.g., a service, or a multicast address, > or any one of an un-knowable number of values of some type]. > And then for addresses in range R2, we want to assign from > the same type, characteristic X2. > > As I understand it, this is not possible. > > The type value might even be a structure, of length hundreds > of bytes (e.g., a certificate). > This would be wrong to duplicate just because of the unwanted > packetBB constraints. > > Regards, > Charlie P. > > > > ext Justin Dean wrote: > > Comments inline > > > > > >> -----Original Message----- > >> From: Russ White [mailto:riw@cisco.com] > >> Sent: Wednesday, November 07, 2007 6:57 PM > >> To: Justin Dean > >> Cc: 'Manet' > >> Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC > >> > >> -----BEGIN PGP SIGNED MESSAGE----- > >> Hash: SHA1 > >> > >> > >> > >>> I would again like to reiterate that I honestly think there > >>> > >> is A LOT > >> > >>> of confusion on what the restrictions actually restrict. I > >>> > >> would like > >> > >>> to ask for solid examples of protocol behaviors which > >>> > >> people feel are > >> > >>> not possible using the packetbb format. I feel a few good > >>> > >> examples of > >> > >>> what can be done with the current format, will go a long way in > >>> illustrating what the TLV restrictions are actually doing > >>> > >> and what they are not doing. > >> > >>> The restriction of TLV order only restricts > >>> > >> encoding/decoding and not > >> > >>> protocol processing which can happen in any order. > >>> > >> 1. You cannot hold items in a structure, and encode them in the > >> structure order. You must always maintain your internal > structure in > >> the same order as the information in the packet is allowed > to appear. > >> > >> > > Well yes and no but I think this comment comes at the heart of what > > might be confusing. You can't hold items in an arbitrary structure > > order and encode them in that order directly. I agree with > that. But > > to say that you must maintain the internal structure order > in the same > > order in which packets will be encoding seems wrong to me. > Its quite > > easy to encoded in any random order regardless of the > structure order. > > Transformation of the information needs to take place to > build the TLV > > in any case so even it were in order a straight mapping of a data > > structure into a TLV would not really be practical unless > it were in a > > single value field and in which case its perfectly okay to do so. > > > > Packet.AddTlv(mystruct.a); > > Packet.AddTlv(mystruct.b); > > Packet.AddTlv(mystruct.c); > > Is no harder than. > > Packet.AddTlv(mystruct.c); > > Packet.AddTlv(mystruct.b); > > Packet.AddTlv(mystruct.a); > > > > > > > >> 2. It's a bit disingenuous to say you can process things in any > >> order, you just have to encode them and decode them in this order. > >> > > This I partly agree with although the encoding part should > be trivial. > > Decoding I will talk abut more. > > > > > >> If you must put them in the packet in a specific order, > then you must > >> process them in that order when building the packet. Since > these are > >> TLVs, and you cannot know where one TLV starts until you reach the > >> end of the current TLV, you also cannot efficiently process the > >> information in the packet, unless you process it in the order it's > >> carried in the packet. > >> > > > > It really depends on the data being transmitted. With MOST of the > > proposed TLV definitions the order in which they are processed does > > not matter either the entire packet needs to be processed > or there is > > no harm in processing the data which has so far arrived. > There are a > > few which should come before others in terms of processing on the > > receiving end we the space was split up to accommodate this > type of behavior. > > > > > > > >>> The single TLV type value per address does not restrict > >>> > >> TLVs to carry > >> > >>> only one 'value' in the value field. TLV's can be defined > >>> > >> to carry an > >> > >>> arbitrary list of values in one value field which can be > >>> > >> used however > >> > >>> the protocol wishes. > >>> > >> This means you cannot insert multiple copies of the same data (IE, > >> multiple next hops, or multiples of anything) without > creating a TLV > >> with subTLVs for the pertinent information. > >> > >> > > This is a misconception. You can insert multiple copies of similar > > data (I use "similar" instead of same as I think its was meant, > > multiples of the same data would be better represented by a single > > value and a number) using a single TLV without using the > subTLV area. > > One just has to define their TLV's value field to carry the list of > > information instead of a single value. Packetbb allows > this list to > > be defined in a variable length fashion. The advantage of this is > > that a protocol can use the information in whatever way makes sense > > and even lowers the TLV overhead from including multiples > of the same TLV. > > > > > >> Let me put it another way. If a protocol would like to process > >> information in a specific order, there's nothing stopping it from > >> specifying, in a standard that explains how to apply > packetbb to the > >> protocol, that the TLVs must be carried in a specific > order. There is > >> no reason to restrict all protocols to a specific order simply > >> because it happens to make some protocols more efficient. > Standards > >> should not be unnecessarily restrictive, especially when they can > >> apply to a wide range of protocols. > >> > > > > This I think hits very close to the difference of opinion. > Packetbb > > and the TLV structure was designed in such a way in that the > > information contained within the packet (other than the > address block) does not rely on ordering. > > > > > > > >> Finally, forcing the order assumes that no possible > optimization are > >> ever possible beyond the ones that have been invented to > this point, > >> and covered in this specific draft. > >> This is an unacceptable assumption on the part of the > draft authors. > >> There's more than just what we know today to consider. > >> > >> I understand that you don't think any of the examples or > problems are > >> problems--it makes one or two protocols more efficient, it doesn't > >> appear to make the others less efficient, so we should go > forth and > >> conquer. When you show me in your crystal ball that it will never > >> impact the performance of any possible protocol, and when > you show me > >> why the protocols that do benefit from this restriction cannot > >> include this restriction in a separate draft, then I'll agree. > >> > >> > > I guess this is kind of the point. We can't predict the > future but we > > do have some real examples which have gains. I have > repeatedly asked > > for specific examples using packetbb on what one would like > to do but > > can't because of the restrictions and am still looking forward to > > seeing some. I haven't ever argued that there is no > tradeoff, indeed > > there will be some efficiently loses for certain types of wanted > > behaviors but as they are as of yet unspecified. Going with what is > > best for the current specified protocols seems to me to be > the correct course of action. > > > > > > > >> Since my crystal ball broke last week, and since no-one > can seem to > >> offer a reason why these protocol specific restrictions > couldn't be > >> placed in a protocol specific draft, I don't see any > reason to move > >> forward with this draft. > >> > >> > > I somewhat agree with Thomas that this gives in many cases > the worst > > of both worlds and reduces the gains of each. However this or some > > other similar compromise may be the only way forward > although to me it > > greatly reduces the benefits. > > > > > >> The packet ordering requirements in the packetbb draft > aren't a good > >> idea. > >> > >> > > I will try to remain open minded to be convinced of this. I > have also > > not given up trying to convince everyone otherwise. > > > > Justin > > > >> Russ > >> > >> - -- > >> riw@cisco.com CCIE <>< Grace Alone > >> > >> -----BEGIN PGP SIGNATURE----- > >> Version: GnuPG v1.4.6 (MingW32) > >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >> > >> iD8DBQFHMlDcER27sUhU9OQRAmIKAJ91M7gZbH9FLD8R6fD5tlOH4v2e1QCg8U3/ > >> vrPpaNnL5UYmlCtTL5QHflk= > >> =3gAX > >> -----END PGP SIGNATURE----- > >> > >> > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 08 17:44:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqG6M-0006gF-Ta; Thu, 08 Nov 2007 17:43:54 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqG6K-0006dt-TB for manet-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 17:43:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqG6K-0006d5-Dn for manet@ietf.org; Thu, 08 Nov 2007 17:43:52 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqG6I-0000lo-2Y for manet@ietf.org; Thu, 08 Nov 2007 17:43:52 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA8MhAQF012439; Fri, 9 Nov 2007 00:43:46 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 00:43:39 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 16:43:24 -0600 Received: from [172.18.141.137] ([172.18.141.137]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 16:43:24 -0600 Message-ID: <4733910B.60609@nokia.com> Date: Thu, 08 Nov 2007 14:43:23 -0800 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Justin Dean Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <200711081813.lA8IDJw1013382@s2.itd.nrl.navy.mil> In-Reply-To: <200711081813.lA8IDJw1013382@s2.itd.nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Nov 2007 22:43:24.0089 (UTC) FILETIME=[C531A290:01C82258] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 559439f19b20fd64c5cd872aef84c6f3 Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Justin, My example was meant to associate both values, not to over-ride the first value with the second value. Also, my ranges were supposed to be intervals of perhaps many addresses, so that for instance [A1,A3] might contain thousands of addresses. With this understanding, I can still apply your examples. It seems to me that several of your variations do serve to exemplify the additional complications which are introduced by the constraints. Having to define such a "not really" type is, I think, unprecedented in the IETF world of TLVs. At least I have never heard of it, and honestly I'd be afraid to get up to a mike and propose such a thing in public. There are, of course, some removal TLVs, but they are designed to be sent a lot _later_, not at the same time(!). Since I have your attention, can you explain again why in the heck these constraints cannot be mandated per protocol? The last attempt by Thomas really rated quite low on my scale of believability. For this case: > 1) One could simply use single TLVs with the values to be associated with > the addresses. > TLV1 A1 = [X1] > TLV1 A2 = [X1,X2] > TLV1 A3 = [X1,X2] > TLV1 A4 = [X2] > There is a TLV overhead for each address which has a value when using this > method but its simple and straight forward. the nasty thing is that you are repeating the data. As I mentioned, this may introduce unwanted kilobytes of overhead in the representation. For your second example 3: > 3) Again similar to the last example I gave further up a second TLV could be > defined (TLV3 so as not to conflict with TLV2 above) which conveys the > meaning "these values as well" or even "not really these values" to subtract > entries. For this example "these values as well" TLV3 is used. > mTLV1 R1 = [X1] > mTLV3 R2 = [X2] I am still scratching my head and puzzling over this, but anyway the two alternatives you suggest in this example are not at all like each other. Or it could be that this is where my interval ranges are not compatible in interpretation with your interpretation as ordered pairs. As a general comment, though, given a common understanding that one wants to assign perhaps several values to addresses in overlapping ranges of addresses, I think the solution that I am requesting is dramatically simpler than the alternatives suggested. Please let me know whether viewing [A1,A3] and [A2,A4] as intervals instead of ordered pairs makes a difference in your suggested alternatives. Lastly, regarding [1..googolplex].... The point was to show that just because one can reformulate a solution in order to conform to the packetBB constraints, does not make it a good idea to have to make the reformulation. And, as your alternatives below are showing, in order to reformulate, one can be required to do various "non-IETF-ful" things. Regards, Charlie P. ext Justin Dean wrote: > Great! I think you beat me to my one reply which now makes it look silly > well done! > Good example by the way. First I would like to separate the issue into two > different problems as I am not sure what information is meant to be > conveyed. > Does the sender want the "second" TLV to override the first or be part of a > list? > Which are correct? > A1 = [X1], A2 = [X2], A3 = [X2], A4 = [X2] > Or > A1 = [X1], A2 = [X1,X2], A3 = [X1,X2], A4 = [X2] > > The first situation where the information (X2) is meant to override the > first type (X2) of information could be encoded in various ways here are a > few: > > 1) Use a multivalue TLV, mTLV1 for the entire range R > mTLV1 R = [X1,X2,X2,X2]. > Overhead grows with size of the set however. But for this example there is > only one TLV overhead cost. > > 2) Use a combination of a single TLV, TLV1, for the first entry and a single > multivalue TLV, mTLV1 with one value for the range R2. > TLV1 A1 = [X1] > mTLV1 R2 = [X2] (note the difference between this multivalue, one value, and > the previous, value for each entry, both are allowed) > This has the overhead of 2 different TLVs but does not encode multiple X2 > values. The growth is slower because of this as well as long as X2 remains > the value for the addresses in that order. > > Both of the above examples use only one TLV type of which does not need to > use the full type. > > 3) Another way which would use more than one TLV type but would more closely > resemble what you are doing would be to define two TLVs. > The first TLV would be defined the same, it ascribes characteristic X to an > address A or range R. The second one TLV2 would be similar but different in > meaning, it would convey the "no X is really this" TLV which by definition > overrides the first defined TLV > One could then use > mTLV1 R1 = [X1] > mTLV2 R2 = [X2] > The drawback with this is that a TLV type for each really in the "no REALLY > REALLY" would have to be defined. Sub types would work well in this case > although if only one was needed (and I honestly don't see more than 2 > actually being useful) then 2 separate TLVs types could be assigned. This > last example would work exactly the same as with no restrictions except that > you would define two TLVs for use. And in fact the order within the packet > does not change the meaning of the information, being conveyed. > > These are just 3 examples and there are many more ways of encoding this type > of information. > > The second situation is similar but very different in meaning. Here are a > few examples of how one could encode the information using packetbb. > 1) One could simply use single TLVs with the values to be associated with > the addresses. > TLV1 A1 = [X1] > TLV1 A2 = [X1,X2] > TLV1 A3 = [X1,X2] > TLV1 A4 = [X2] > There is a TLV overhead for each address which has a value when using this > method but its simple and straight forward. > > 2) Use 2 single TLVs and one multivalue TLVs defined such that > TLV1 A1 = [X1] > mTLV1 R3 = [X1,X2] (this TLV would be defined in such a way that there is > only a single value to be mapped to each address in R3, R3:=[A2,A3] > TLV A4 = [X2] > There is less overhead in this example rather than the first in that there > is one less TLV and the shared information is only included once. > > 3) Again similar to the last example I gave further up a second TLV could be > defined (TLV3 so as not to conflict with TLV2 above) which conveys the > meaning "these values as well" or even "not really these values" to subtract > entries. For this example "these values as well" TLV3 is used. > mTLV1 R1 = [X1] > mTLV3 R2 = [X2] > Notice how the layout is the same as in the last example for the first > situation and indeed Charlie's initial example as well, but the definition > of the TLV2 and TLV3 explicitly state what the meaning of the information > is. There is a draw back when adding in multiple passes require more TLVs > but again I see diminishing returns on having more than 1 level of addition. > > > I feel these are good examples of what can be done but are by no means > exhaustive. I hope that it helps illustrate what behaviors are allowed and > furthermore demonstrates the explicitness of the information being conveyed, > even without protocol knowledge, by conforming to the restrictions allows. > More complicated examples can lead to more complicated solutions for > certain. I am sure there is enough flexibility within the current draft, > that papers can be written on how to best optimize encoding of information > within packetbb. I would like to thank you Charlie for giving me this > example to work with. > > Justin > > > >> -----Original Message----- >> From: Charles E. Perkins [mailto:charles.perkins@nokia.com] >> Sent: Thursday, November 08, 2007 12:19 PM >> To: ext Justin Dean >> Cc: 'Manet' >> Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC >> >> >> Hello Justin, >> >> I have made some examples to show useful constructions that >> are disallowed by packetBB. >> Here is one. >> >> Assume there are address ranges R1:=[A1,A3] and R2 := >> [A2,A4], where A1 < A2 < A3 < A4. >> Suppose that for address in range R1, we want to ascribe >> characteristic X1 [e.g., a service, or a multicast address, >> or any one of an un-knowable number of values of some type]. >> And then for addresses in range R2, we want to assign from >> the same type, characteristic X2. >> >> As I understand it, this is not possible. >> >> The type value might even be a structure, of length hundreds >> of bytes (e.g., a certificate). >> This would be wrong to duplicate just because of the unwanted >> packetBB constraints. >> >> Regards, >> Charlie P. >> >> >> >> ext Justin Dean wrote: >> >>> Comments inline >>> >>> >>> >>>> -----Original Message----- >>>> From: Russ White [mailto:riw@cisco.com] >>>> Sent: Wednesday, November 07, 2007 6:57 PM >>>> To: Justin Dean >>>> Cc: 'Manet' >>>> Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC >>>> >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> >>>> >>>> >>>>> I would again like to reiterate that I honestly think there >>>>> >>>>> >>>> is A LOT >>>> >>>> >>>>> of confusion on what the restrictions actually restrict. I >>>>> >>>>> >>>> would like >>>> >>>> >>>>> to ask for solid examples of protocol behaviors which >>>>> >>>>> >>>> people feel are >>>> >>>> >>>>> not possible using the packetbb format. I feel a few good >>>>> >>>>> >>>> examples of >>>> >>>> >>>>> what can be done with the current format, will go a long way in >>>>> illustrating what the TLV restrictions are actually doing >>>>> >>>>> >>>> and what they are not doing. >>>> >>>> >>>>> The restriction of TLV order only restricts >>>>> >>>>> >>>> encoding/decoding and not >>>> >>>> >>>>> protocol processing which can happen in any order. >>>>> >>>>> >>>> 1. You cannot hold items in a structure, and encode them in the >>>> structure order. You must always maintain your internal >>>> >> structure in >> >>>> the same order as the information in the packet is allowed >>>> >> to appear. >> >>>> >>>> >>> Well yes and no but I think this comment comes at the heart of what >>> might be confusing. You can't hold items in an arbitrary structure >>> order and encode them in that order directly. I agree with >>> >> that. But >> >>> to say that you must maintain the internal structure order >>> >> in the same >> >>> order in which packets will be encoding seems wrong to me. >>> >> Its quite >> >>> easy to encoded in any random order regardless of the >>> >> structure order. >> >>> Transformation of the information needs to take place to >>> >> build the TLV >> >>> in any case so even it were in order a straight mapping of a data >>> structure into a TLV would not really be practical unless >>> >> it were in a >> >>> single value field and in which case its perfectly okay to do so. >>> >>> Packet.AddTlv(mystruct.a); >>> Packet.AddTlv(mystruct.b); >>> Packet.AddTlv(mystruct.c); >>> Is no harder than. >>> Packet.AddTlv(mystruct.c); >>> Packet.AddTlv(mystruct.b); >>> Packet.AddTlv(mystruct.a); >>> >>> >>> >>> >>>> 2. It's a bit disingenuous to say you can process things in any >>>> order, you just have to encode them and decode them in this order. >>>> >>>> >>> This I partly agree with although the encoding part should >>> >> be trivial. >> >>> Decoding I will talk abut more. >>> >>> >>> >>>> If you must put them in the packet in a specific order, >>>> >> then you must >> >>>> process them in that order when building the packet. Since >>>> >> these are >> >>>> TLVs, and you cannot know where one TLV starts until you reach the >>>> end of the current TLV, you also cannot efficiently process the >>>> information in the packet, unless you process it in the order it's >>>> carried in the packet. >>>> >>>> >>> It really depends on the data being transmitted. With MOST of the >>> proposed TLV definitions the order in which they are processed does >>> not matter either the entire packet needs to be processed >>> >> or there is >> >>> no harm in processing the data which has so far arrived. >>> >> There are a >> >>> few which should come before others in terms of processing on the >>> receiving end we the space was split up to accommodate this >>> >> type of behavior. >> >>> >>> >>>>> The single TLV type value per address does not restrict >>>>> >>>>> >>>> TLVs to carry >>>> >>>> >>>>> only one 'value' in the value field. TLV's can be defined >>>>> >>>>> >>>> to carry an >>>> >>>> >>>>> arbitrary list of values in one value field which can be >>>>> >>>>> >>>> used however >>>> >>>> >>>>> the protocol wishes. >>>>> >>>>> >>>> This means you cannot insert multiple copies of the same data (IE, >>>> multiple next hops, or multiples of anything) without >>>> >> creating a TLV >> >>>> with subTLVs for the pertinent information. >>>> >>>> >>>> >>> This is a misconception. You can insert multiple copies of similar >>> data (I use "similar" instead of same as I think its was meant, >>> multiples of the same data would be better represented by a single >>> value and a number) using a single TLV without using the >>> >> subTLV area. >> >>> One just has to define their TLV's value field to carry the list of >>> information instead of a single value. Packetbb allows >>> >> this list to >> >>> be defined in a variable length fashion. The advantage of this is >>> that a protocol can use the information in whatever way makes sense >>> and even lowers the TLV overhead from including multiples >>> >> of the same TLV. >> >>> >>> >>>> Let me put it another way. If a protocol would like to process >>>> information in a specific order, there's nothing stopping it from >>>> specifying, in a standard that explains how to apply >>>> >> packetbb to the >> >>>> protocol, that the TLVs must be carried in a specific >>>> >> order. There is >> >>>> no reason to restrict all protocols to a specific order simply >>>> because it happens to make some protocols more efficient. >>>> >> Standards >> >>>> should not be unnecessarily restrictive, especially when they can >>>> apply to a wide range of protocols. >>>> >>>> >>> This I think hits very close to the difference of opinion. >>> >> Packetbb >> >>> and the TLV structure was designed in such a way in that the >>> information contained within the packet (other than the >>> >> address block) does not rely on ordering. >> >>> >>> >>>> Finally, forcing the order assumes that no possible >>>> >> optimization are >> >>>> ever possible beyond the ones that have been invented to >>>> >> this point, >> >>>> and covered in this specific draft. >>>> This is an unacceptable assumption on the part of the >>>> >> draft authors. >> >>>> There's more than just what we know today to consider. >>>> >>>> I understand that you don't think any of the examples or >>>> >> problems are >> >>>> problems--it makes one or two protocols more efficient, it doesn't >>>> appear to make the others less efficient, so we should go >>>> >> forth and >> >>>> conquer. When you show me in your crystal ball that it will never >>>> impact the performance of any possible protocol, and when >>>> >> you show me >> >>>> why the protocols that do benefit from this restriction cannot >>>> include this restriction in a separate draft, then I'll agree. >>>> >>>> >>>> >>> I guess this is kind of the point. We can't predict the >>> >> future but we >> >>> do have some real examples which have gains. I have >>> >> repeatedly asked >> >>> for specific examples using packetbb on what one would like >>> >> to do but >> >>> can't because of the restrictions and am still looking forward to >>> seeing some. I haven't ever argued that there is no >>> >> tradeoff, indeed >> >>> there will be some efficiently loses for certain types of wanted >>> behaviors but as they are as of yet unspecified. Going with what is >>> best for the current specified protocols seems to me to be >>> >> the correct course of action. >> >>> >>> >>>> Since my crystal ball broke last week, and since no-one >>>> >> can seem to >> >>>> offer a reason why these protocol specific restrictions >>>> >> couldn't be >> >>>> placed in a protocol specific draft, I don't see any >>>> >> reason to move >> >>>> forward with this draft. >>>> >>>> >>>> >>> I somewhat agree with Thomas that this gives in many cases >>> >> the worst >> >>> of both worlds and reduces the gains of each. However this or some >>> other similar compromise may be the only way forward >>> >> although to me it >> >>> greatly reduces the benefits. >>> >>> >>> >>>> The packet ordering requirements in the packetbb draft >>>> >> aren't a good >> >>>> idea. >>>> >>>> >>>> >>> I will try to remain open minded to be convinced of this. I >>> >> have also >> >>> not given up trying to convince everyone otherwise. >>> >>> Justin >>> >>> >>>> Russ >>>> >>>> - -- >>>> riw@cisco.com CCIE <>< Grace Alone >>>> >>>> -----BEGIN PGP SIGNATURE----- >>>> Version: GnuPG v1.4.6 (MingW32) >>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >>>> >>>> iD8DBQFHMlDcER27sUhU9OQRAmIKAJ91M7gZbH9FLD8R6fD5tlOH4v2e1QCg8U3/ >>>> vrPpaNnL5UYmlCtTL5QHflk= >>>> =3gAX >>>> -----END PGP SIGNATURE----- >>>> >>>> >>>> >>> >>> _______________________________________________ >>> manet mailing list >>> manet@ietf.org >>> https://www1.ietf.org/mailman/listinfo/manet >>> >>> > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 08 19:55:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqIA0-0004B7-5w; Thu, 08 Nov 2007 19:55:48 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqI9y-0004AR-J4 for manet-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 19:55:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqI9y-0004A9-8y for manet@ietf.org; Thu, 08 Nov 2007 19:55:46 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqI9v-0002sM-KN for manet@ietf.org; Thu, 08 Nov 2007 19:55:46 -0500 X-IronPort-AV: E=Sophos;i="4.21,392,1188792000"; d="scan'208";a="75533767" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2007 19:55:43 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA90tg5o020820; Thu, 8 Nov 2007 19:55:42 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA90t7WZ027745; Fri, 9 Nov 2007 00:55:41 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 19:55:22 -0500 Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Nov 2007 19:55:21 -0500 Message-ID: <4733AFD1.4070503@cisco.com> Date: Thu, 08 Nov 2007 19:54:41 -0500 From: Russ White User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Justin Dean Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <200711081702.lA8H2X4Q009843@s2.itd.nrl.navy.mil> In-Reply-To: <200711081702.lA8H2X4Q009843@s2.itd.nrl.navy.mil> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2007 00:55:21.0989 (UTC) FILETIME=[34A14B50:01C8226B] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15532.002 X-TM-AS-Result: No--0.834400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1715; t=1194569742; x=1195433742; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[manet]=20draft-ietf-manet-packetbb=20-=20WGLC |Sender:=20 |To:=20Justin=20Dean=20; bh=VI9Sy3t2I6DyAMqJKHqHvr7lyabQAWyXiRhkik3go8M=; b=GKnWky13sz1edfy/YJM8PJ0P76hqH09WN6MZXFvI8BWqzWlVvPHQI6nPxTp9GGIY43O/grWo m0KGJccX4JZ0j9qxFf4rSsBF/stoTpS21UER6683bgy80FhI7W7D1lLd; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> You can't hold items in an arbitrary structure order and encode >> them in that order directly. I agree with that. I must be confused by something here.... The line of argument I'm hearing is: 1. It's important to keep the TLVs in order to make encoding more efficient for some protocols. 2. Those protocols who don't want to process their TLVs in order can simply ignore the order in the packet, and process them any way they want to. Doesn't this line of reasoning also suggest that any implementation that wants to process the TLVs in a specific order may also ignore the ordering in the packet, and simply process them in order? Doesn't the argument work in both directions? If the ordering of the TLVs in the packet is so easy to "get around," then why does the ordering of the TLVs in the packet matter at all? As I said at the beginning of this thread--IMHO, there are a lot of creative ways around this ordering problem. I listed a few of them in that original email. I don't understand why some system that allows either encoding. What I'm hearing is--I want this organized so it optimizes my protocol. Other protocols can work around what I need (because I don't think it's so hard for them to work around what I want!). IMHO, this is a bad way to build a standard specifically designed to support many competing protocols. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHM6/RER27sUhU9OQRAo8ZAJ9O70xmoFyAdT7sNxwoT0QB7xmpMACbBxfq 4+pLMkwyUxbOMFglno/1gA4= =K+3d -----END PGP SIGNATURE----- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 09 08:45:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqUAt-0008Um-HU; Fri, 09 Nov 2007 08:45:31 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqUAr-0008OG-HZ for manet-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 08:45:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqUAr-0008NJ-7g for manet@ietf.org; Fri, 09 Nov 2007 08:45:29 -0500 Received: from rv-out-0910.google.com ([209.85.198.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqUAm-0006EG-Iu for manet@ietf.org; Fri, 09 Nov 2007 08:45:29 -0500 Received: by rv-out-0910.google.com with SMTP id l15so427839rvb for ; Fri, 09 Nov 2007 05:45:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:reply-to:to:subject:message-id:organization:x-mailer:mime-version:content-type; bh=KMGa8HKMNAdeN1LYAvn5VN66l9hieTaIDkpiAROg+wE=; b=Yyxl90CJZ71u9kRfrtgr4n7FrF2LNL2yGoOdzqCihLwPsKsenPBhsPEioKYT69IS6djGiKYCzvy3TfWiLLuTvI2/QxgmHKDuUX9sUwfCAffiXsrbU8PaCVef7+6LVrg67/a9dXEmeqYjNUnqF/0H1N/hS/kAV7k9DLJmdrXIxzk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:from:reply-to:to:subject:message-id:organization:x-mailer:mime-version:content-type; b=jpl9++4l6snzrP8PumS1BUhEFF46pZmzUMOJr5bQM+/81gzQ76vZgeVq43ErFeoqRAMntj98xHOjl0qjDU5CBRQujTDnD4oToKa/qEfH99Tv5u/JZ16iMdKPGCF6Ovz5Ic7eagY5RrCL36Mn9iHy2Ag2RpCGe9jYyyQQM5Zvrpw= Received: by 10.141.50.17 with SMTP id c17mr929004rvk.1194615923748; Fri, 09 Nov 2007 05:45:23 -0800 (PST) Received: from guoqing ( [61.150.43.47]) by mx.google.com with ESMTPS id f28sm4096224rvb.2007.11.09.05.45.20 (version=SSLv3 cipher=OTHER); Fri, 09 Nov 2007 05:45:23 -0800 (PST) Date: Fri, 9 Nov 2007 21:45:17 +0800 From: "=?gb2312?B?zvexsbmk0rW089Gnv9jWxtPrzfjC59HQvr/L+SAg1cW5+sfs?=" To: "manet" Message-ID: <200711092145022182530@gmail.com> Organization: =?gb2312?B?zvexsbmk0rW089Gnv9jWxtPrzfjC59HQvr/L+Q==?= X-mailer: Foxmail 6, 10, 201, 20 [cn] Mime-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Subject: [manet] where can i get the sim codes of geocast routing protocols? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gniqoug@gmail.com List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1002140042==" Errors-To: manet-bounces@ietf.org This is a multi-part message in MIME format. --===============1002140042== Content-Type: multipart/alternative; boundary="=====003_Dragon187414017065_=====" This is a multi-part message in MIME format. --=====003_Dragon187414017065_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Hi, where can i get the sim codes of geocast routing protocols,such as LBM,Geogrid,and GAMER? thanks very much. 2007-11-09 --=====003_Dragon187414017065_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 7bit
Hi,
where can i get the sim codes of geocast routing protocols,such as LBM,Geogrid,and GAMER?
thanks very much.
 
 
2007-11-09
 --=====003_Dragon187414017065_=====-- --===============1002140042== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1002140042==-- From manet-bounces@ietf.org Fri Nov 09 10:46:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqW4K-00030D-J7; Fri, 09 Nov 2007 10:46:52 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqW4J-0002yg-2l for manet-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 10:46:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqW4I-0002yX-Os for manet@ietf.org; Fri, 09 Nov 2007 10:46:50 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqW4E-00029U-GR for manet@ietf.org; Fri, 09 Nov 2007 10:46:50 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lA9FkhQ8023656; Fri, 9 Nov 2007 10:46:44 -0500 (EST) Message-Id: <200711091546.lA9FkhQ8023656@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007110910464331079 ; Fri, 09 Nov 2007 10:46:43 -0500 From: "Justin Dean" To: "'Charles E. Perkins'" Subject: RE: [manet] draft-ietf-manet-packetbb - WGLC Date: Fri, 9 Nov 2007 10:52:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcgiWNjP9XDG9n7NSwev2EeaGRQSlQAiv+Gw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4733910B.60609@nokia.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: 06321bb70e4329e24fb56a67c5eca3a0 Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I would like to point out that the examples I have given are really only applicable if there is no difference in the information at all. This is often not the case although they may be similar and sometimes it actually is the case. An example of similar information might define a TLV "link type" in which link types may overlap. Separation the overlapping data into separate TLVs where possible (such as "link status" as symmetric, asymmetric, lost and "link attribute" mpr, dead-end) removes having to use the examples I have given below as the information now being conveyed is internally exclusive. This may not always be possible or desired in which case the examples I have given below, I feel are good alternatives which allow for a wide range of encodings. A few comments inline. > -----Original Message----- > From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > Sent: Thursday, November 08, 2007 5:43 PM > To: ext Justin Dean > Cc: 'Manet' > Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC > > > Hello Justin, > > My example was meant to associate both values, not to > over-ride the first value with the second value. > Also, my ranges were supposed to be intervals of perhaps many > addresses, so that for instance [A1,A3] might contain > thousands of addresses. > > With this understanding, I can still apply your examples. Glad you found them as such. Some working much better than others at certain intervals with added exceptions. > It seems to me that several of your variations do serve to > exemplify the additional complications which are introduced > by the constraints. Having to define such a "not really" > type is, I think, unprecedented in the IETF world of TLVs. > At least I have never heard of it, and honestly I'd be afraid > to get up to a mike and propose such a thing in public. > There are, of course, some removal TLVs, but they are > designed to be sent a lot _later_, not at the same time(!). > Having to define the "not really" or "in addition to" TLVs come directly from using "tricks" to compress the packet overhead they are not needed if one is willing to live with the larger overhead of not having them. I am actually quite happy that packetbb can encode, relatively natively, information in this compact a form. I would argue that most protocols do not allow for this rich of an encoding mechanism so more complicated behaviors are really not needed. > Since I have your attention, can you explain again why in the > heck these constraints cannot be mandated per protocol? The > last attempt by Thomas really rated quite low on my scale of > believability. To me the one TLV per address constraint is to help lead to coherent packets in which information is not ambiguous at the packet level. In all of my examples a parser could take in a packet and present the information in terms of individual address and TLV values specifically associated with those addresses; a class representation would be the same in all cases, without needed any protocol knowledge. I think my confusion on what was exactly being conveyed with the original example clearly represents what I am trying to say here. Furthermore different orderings of TLVs could change the meaning of the data being represented. To me this added "complication" in defining TLVs is worth the explicitness it forces. I also think that the example here discussed will not be the normal mode of TLV operation but the exception, but that when it does happen it can be supported. Justin > > For this case: > > 1) One could simply use single TLVs with the values to be > associated > > with the addresses. > > TLV1 A1 = [X1] > > TLV1 A2 = [X1,X2] > > TLV1 A3 = [X1,X2] > > TLV1 A4 = [X2] > > There is a TLV overhead for each address which has a value > when using > > this method but its simple and straight forward. > the nasty thing is that you are repeating the data. > As I mentioned, this may introduce unwanted kilobytes of > overhead in the representation. > > For your second example 3: > > 3) Again similar to the last example I gave further up a second TLV > > could be defined (TLV3 so as not to conflict with TLV2 above) which > > conveys the meaning "these values as well" or even "not > really these > > values" to subtract entries. For this example "these > values as well" TLV3 is used. > > mTLV1 R1 = [X1] > > mTLV3 R2 = [X2] > I am still scratching my head and puzzling over this, but > anyway the two alternatives you suggest in this example are > not at all like each other. Or it could be that this is > where my interval ranges are not compatible in interpretation > with your interpretation as ordered pairs. > > As a general comment, though, given a common understanding > that one wants to assign perhaps several values to addresses > in overlapping ranges of addresses, I think the solution that > I am requesting is dramatically simpler than the alternatives > suggested. > > Please let me know whether viewing [A1,A3] and [A2,A4] as > intervals instead of ordered pairs makes a difference in your > suggested alternatives. > > Lastly, regarding [1..googolplex].... The point was to show > that just because one can reformulate a solution in order to > conform to the packetBB constraints, does not make it a good > idea to have to make the reformulation. And, as your > alternatives below are showing, in order to reformulate, one > can be required to do various "non-IETF-ful" things. > > Regards, > Charlie P. > > > > ext Justin Dean wrote: > > Great! I think you beat me to my one reply which now makes it look > > silly well done! > > Good example by the way. First I would like to separate the issue > > into two different problems as I am not sure what > information is meant > > to be conveyed. > > Does the sender want the "second" TLV to override the first > or be part > > of a list? > > Which are correct? > > A1 = [X1], A2 = [X2], A3 = [X2], A4 = [X2] > > Or > > A1 = [X1], A2 = [X1,X2], A3 = [X1,X2], A4 = [X2] > > > > The first situation where the information (X2) is meant to override > > the first type (X2) of information could be encoded in various ways > > here are a > > few: > > > > 1) Use a multivalue TLV, mTLV1 for the entire range R > > mTLV1 R = [X1,X2,X2,X2]. > > Overhead grows with size of the set however. But for this example > > there is only one TLV overhead cost. > > > > 2) Use a combination of a single TLV, TLV1, for the first > entry and a > > single multivalue TLV, mTLV1 with one value for the range R2. > > TLV1 A1 = [X1] > > mTLV1 R2 = [X2] (note the difference between this multivalue, one > > value, and the previous, value for each entry, both are > allowed) This > > has the overhead of 2 different TLVs but does not encode > multiple X2 > > values. The growth is slower because of this as well as long as X2 > > remains the value for the addresses in that order. > > > > Both of the above examples use only one TLV type of which does not > > need to use the full type. > > > > 3) Another way which would use more than one TLV type but > would more > > closely resemble what you are doing would be to define two TLVs. > > The first TLV would be defined the same, it ascribes > characteristic X > > to an address A or range R. The second one TLV2 would be > similar but > > different in meaning, it would convey the "no X is really this" TLV > > which by definition overrides the first defined TLV One > could then use > > mTLV1 R1 = [X1] > > mTLV2 R2 = [X2] > > The drawback with this is that a TLV type for each really > in the "no > > REALLY REALLY" would have to be defined. Sub types would > work well in > > this case although if only one was needed (and I honestly don't see > > more than 2 actually being useful) then 2 separate TLVs > types could be > > assigned. This last example would work exactly the same as with no > > restrictions except that you would define two TLVs for use. And in > > fact the order within the packet does not change the > meaning of the information, being conveyed. > > > > These are just 3 examples and there are many more ways of encoding > > this type of information. > > > > The second situation is similar but very different in > meaning. Here > > are a few examples of how one could encode the information > using packetbb. > > 1) One could simply use single TLVs with the values to be > associated > > with the addresses. > > TLV1 A1 = [X1] > > TLV1 A2 = [X1,X2] > > TLV1 A3 = [X1,X2] > > TLV1 A4 = [X2] > > There is a TLV overhead for each address which has a value > when using > > this method but its simple and straight forward. > > > > 2) Use 2 single TLVs and one multivalue TLVs defined such that > > TLV1 A1 = [X1] > > mTLV1 R3 = [X1,X2] (this TLV would be defined in such a way that > > there is only a single value to be mapped to each address > in R3, R3:=[A2,A3] > > TLV A4 = [X2] > > There is less overhead in this example rather than the > first in that > > there is one less TLV and the shared information is only > included once. > > > > 3) Again similar to the last example I gave further up a second TLV > > could be defined (TLV3 so as not to conflict with TLV2 above) which > > conveys the meaning "these values as well" or even "not > really these > > values" to subtract entries. For this example "these > values as well" TLV3 is used. > > mTLV1 R1 = [X1] > > mTLV3 R2 = [X2] > > Notice how the layout is the same as in the last example > for the first > > situation and indeed Charlie's initial example as well, but the > > definition of the TLV2 and TLV3 explicitly state what the > meaning of > > the information is. There is a draw back when adding in multiple > > passes require more TLVs but again I see diminishing > returns on having more than 1 level of addition. > > > > > > I feel these are good examples of what can be done but are > by no means > > exhaustive. I hope that it helps illustrate what behaviors are > > allowed and furthermore demonstrates the explicitness of the > > information being conveyed, even without protocol > knowledge, by conforming to the restrictions allows. > > More complicated examples can lead to more complicated > solutions for > > certain. I am sure there is enough flexibility within the current > > draft, that papers can be written on how to best optimize > encoding of > > information within packetbb. I would like to thank you Charlie for > > giving me this example to work with. > > > > Justin > > > > > > > >> -----Original Message----- > >> From: Charles E. Perkins [mailto:charles.perkins@nokia.com] > >> Sent: Thursday, November 08, 2007 12:19 PM > >> To: ext Justin Dean > >> Cc: 'Manet' > >> Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC > >> > >> > >> Hello Justin, > >> > >> I have made some examples to show useful constructions that are > >> disallowed by packetBB. > >> Here is one. > >> > >> Assume there are address ranges R1:=[A1,A3] and R2 := > [A2,A4], where > >> A1 < A2 < A3 < A4. > >> Suppose that for address in range R1, we want to ascribe > >> characteristic X1 [e.g., a service, or a multicast address, or any > >> one of an un-knowable number of values of some type]. > >> And then for addresses in range R2, we want to assign from > the same > >> type, characteristic X2. > >> > >> As I understand it, this is not possible. > >> > >> The type value might even be a structure, of length > hundreds of bytes > >> (e.g., a certificate). > >> This would be wrong to duplicate just because of the unwanted > >> packetBB constraints. > >> > >> Regards, > >> Charlie P. > >> > >> > >> > >> ext Justin Dean wrote: > >> > >>> Comments inline > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Russ White [mailto:riw@cisco.com] > >>>> Sent: Wednesday, November 07, 2007 6:57 PM > >>>> To: Justin Dean > >>>> Cc: 'Manet' > >>>> Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC > >>>> > >>>> -----BEGIN PGP SIGNED MESSAGE----- > >>>> Hash: SHA1 > >>>> > >>>> > >>>> > >>>> > >>>>> I would again like to reiterate that I honestly think there > >>>>> > >>>>> > >>>> is A LOT > >>>> > >>>> > >>>>> of confusion on what the restrictions actually restrict. I > >>>>> > >>>>> > >>>> would like > >>>> > >>>> > >>>>> to ask for solid examples of protocol behaviors which > >>>>> > >>>>> > >>>> people feel are > >>>> > >>>> > >>>>> not possible using the packetbb format. I feel a few good > >>>>> > >>>>> > >>>> examples of > >>>> > >>>> > >>>>> what can be done with the current format, will go a long way in > >>>>> illustrating what the TLV restrictions are actually doing > >>>>> > >>>>> > >>>> and what they are not doing. > >>>> > >>>> > >>>>> The restriction of TLV order only restricts > >>>>> > >>>>> > >>>> encoding/decoding and not > >>>> > >>>> > >>>>> protocol processing which can happen in any order. > >>>>> > >>>>> > >>>> 1. You cannot hold items in a structure, and encode them in the > >>>> structure order. You must always maintain your internal > >>>> > >> structure in > >> > >>>> the same order as the information in the packet is allowed > >>>> > >> to appear. > >> > >>>> > >>>> > >>> Well yes and no but I think this comment comes at the > heart of what > >>> might be confusing. You can't hold items in an arbitrary > structure > >>> order and encode them in that order directly. I agree with > >>> > >> that. But > >> > >>> to say that you must maintain the internal structure order > >>> > >> in the same > >> > >>> order in which packets will be encoding seems wrong to me. > >>> > >> Its quite > >> > >>> easy to encoded in any random order regardless of the > >>> > >> structure order. > >> > >>> Transformation of the information needs to take place to > >>> > >> build the TLV > >> > >>> in any case so even it were in order a straight mapping of a data > >>> structure into a TLV would not really be practical unless > >>> > >> it were in a > >> > >>> single value field and in which case its perfectly okay to do so. > >>> > >>> Packet.AddTlv(mystruct.a); > >>> Packet.AddTlv(mystruct.b); > >>> Packet.AddTlv(mystruct.c); > >>> Is no harder than. > >>> Packet.AddTlv(mystruct.c); > >>> Packet.AddTlv(mystruct.b); > >>> Packet.AddTlv(mystruct.a); > >>> > >>> > >>> > >>> > >>>> 2. It's a bit disingenuous to say you can process things in any > >>>> order, you just have to encode them and decode them in > this order. > >>>> > >>>> > >>> This I partly agree with although the encoding part should > >>> > >> be trivial. > >> > >>> Decoding I will talk abut more. > >>> > >>> > >>> > >>>> If you must put them in the packet in a specific order, > >>>> > >> then you must > >> > >>>> process them in that order when building the packet. Since > >>>> > >> these are > >> > >>>> TLVs, and you cannot know where one TLV starts until you > reach the > >>>> end of the current TLV, you also cannot efficiently process the > >>>> information in the packet, unless you process it in the > order it's > >>>> carried in the packet. > >>>> > >>>> > >>> It really depends on the data being transmitted. With > MOST of the > >>> proposed TLV definitions the order in which they are > processed does > >>> not matter either the entire packet needs to be processed > >>> > >> or there is > >> > >>> no harm in processing the data which has so far arrived. > >>> > >> There are a > >> > >>> few which should come before others in terms of processing on the > >>> receiving end we the space was split up to accommodate this > >>> > >> type of behavior. > >> > >>> > >>> > >>>>> The single TLV type value per address does not restrict > >>>>> > >>>>> > >>>> TLVs to carry > >>>> > >>>> > >>>>> only one 'value' in the value field. TLV's can be defined > >>>>> > >>>>> > >>>> to carry an > >>>> > >>>> > >>>>> arbitrary list of values in one value field which can be > >>>>> > >>>>> > >>>> used however > >>>> > >>>> > >>>>> the protocol wishes. > >>>>> > >>>>> > >>>> This means you cannot insert multiple copies of the same > data (IE, > >>>> multiple next hops, or multiples of anything) without > >>>> > >> creating a TLV > >> > >>>> with subTLVs for the pertinent information. > >>>> > >>>> > >>>> > >>> This is a misconception. You can insert multiple copies > of similar > >>> data (I use "similar" instead of same as I think its was meant, > >>> multiples of the same data would be better represented by > a single > >>> value and a number) using a single TLV without using the > >>> > >> subTLV area. > >> > >>> One just has to define their TLV's value field to carry > the list of > >>> information instead of a single value. Packetbb allows > >>> > >> this list to > >> > >>> be defined in a variable length fashion. The advantage > of this is > >>> that a protocol can use the information in whatever way > makes sense > >>> and even lowers the TLV overhead from including multiples > >>> > >> of the same TLV. > >> > >>> > >>> > >>>> Let me put it another way. If a protocol would like to process > >>>> information in a specific order, there's nothing > stopping it from > >>>> specifying, in a standard that explains how to apply > >>>> > >> packetbb to the > >> > >>>> protocol, that the TLVs must be carried in a specific > >>>> > >> order. There is > >> > >>>> no reason to restrict all protocols to a specific order simply > >>>> because it happens to make some protocols more efficient. > >>>> > >> Standards > >> > >>>> should not be unnecessarily restrictive, especially when > they can > >>>> apply to a wide range of protocols. > >>>> > >>>> > >>> This I think hits very close to the difference of opinion. > >>> > >> Packetbb > >> > >>> and the TLV structure was designed in such a way in that the > >>> information contained within the packet (other than the > >>> > >> address block) does not rely on ordering. > >> > >>> > >>> > >>>> Finally, forcing the order assumes that no possible > >>>> > >> optimization are > >> > >>>> ever possible beyond the ones that have been invented to > >>>> > >> this point, > >> > >>>> and covered in this specific draft. > >>>> This is an unacceptable assumption on the part of the > >>>> > >> draft authors. > >> > >>>> There's more than just what we know today to consider. > >>>> > >>>> I understand that you don't think any of the examples or > >>>> > >> problems are > >> > >>>> problems--it makes one or two protocols more efficient, > it doesn't > >>>> appear to make the others less efficient, so we should go > >>>> > >> forth and > >> > >>>> conquer. When you show me in your crystal ball that it > will never > >>>> impact the performance of any possible protocol, and when > >>>> > >> you show me > >> > >>>> why the protocols that do benefit from this restriction cannot > >>>> include this restriction in a separate draft, then I'll agree. > >>>> > >>>> > >>>> > >>> I guess this is kind of the point. We can't predict the > >>> > >> future but we > >> > >>> do have some real examples which have gains. I have > >>> > >> repeatedly asked > >> > >>> for specific examples using packetbb on what one would like > >>> > >> to do but > >> > >>> can't because of the restrictions and am still looking forward to > >>> seeing some. I haven't ever argued that there is no > >>> > >> tradeoff, indeed > >> > >>> there will be some efficiently loses for certain types of wanted > >>> behaviors but as they are as of yet unspecified. Going > with what is > >>> best for the current specified protocols seems to me to be > >>> > >> the correct course of action. > >> > >>> > >>> > >>>> Since my crystal ball broke last week, and since no-one > >>>> > >> can seem to > >> > >>>> offer a reason why these protocol specific restrictions > >>>> > >> couldn't be > >> > >>>> placed in a protocol specific draft, I don't see any > >>>> > >> reason to move > >> > >>>> forward with this draft. > >>>> > >>>> > >>>> > >>> I somewhat agree with Thomas that this gives in many cases > >>> > >> the worst > >> > >>> of both worlds and reduces the gains of each. However > this or some > >>> other similar compromise may be the only way forward > >>> > >> although to me it > >> > >>> greatly reduces the benefits. > >>> > >>> > >>> > >>>> The packet ordering requirements in the packetbb draft > >>>> > >> aren't a good > >> > >>>> idea. > >>>> > >>>> > >>>> > >>> I will try to remain open minded to be convinced of this. I > >>> > >> have also > >> > >>> not given up trying to convince everyone otherwise. > >>> > >>> Justin > >>> > >>> > >>>> Russ > >>>> > >>>> - -- > >>>> riw@cisco.com CCIE <>< Grace Alone > >>>> > >>>> -----BEGIN PGP SIGNATURE----- > >>>> Version: GnuPG v1.4.6 (MingW32) > >>>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > >>>> > >>>> iD8DBQFHMlDcER27sUhU9OQRAmIKAJ91M7gZbH9FLD8R6fD5tlOH4v2e1QCg8U3/ > >>>> vrPpaNnL5UYmlCtTL5QHflk= > >>>> =3gAX > >>>> -----END PGP SIGNATURE----- > >>>> > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> manet mailing list > >>> manet@ietf.org > >>> https://www1.ietf.org/mailman/listinfo/manet > >>> > >>> > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 09 11:14:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWUj-0008NQ-HV; Fri, 09 Nov 2007 11:14:09 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqWUh-0008NA-N6 for manet-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 11:14:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWUh-0008Lj-B2 for manet@ietf.org; Fri, 09 Nov 2007 11:14:07 -0500 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqWUg-0008Rt-Bo for manet@ietf.org; Fri, 09 Nov 2007 11:14:06 -0500 Received: from hpsmtp-eml01.kpnxchange.com ([213.75.38.101]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 17:13:58 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 17:13:58 +0100 From: "Teco Boot" To: "'manet'" , "'Christopher Dearlove'" , "'Cedric Adjih'" , "'Thomas Heide Clausen \(work\)'" References: <374005f30711070949i620d3adeo116ea3d4cb64a203@mail.gmail.com> In-Reply-To: <374005f30711070949i620d3adeo116ea3d4cb64a203@mail.gmail.com> Subject: RE: [manet] draft-ietf-manet-packetbb - WGLC Date: Fri, 9 Nov 2007 17:13:45 +0100 Message-ID: <006501c822eb$81367d70$83a37850$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcghZrzr54ZDM59PSNyL7iHjjcN7owBbw58Q Content-Language: nl X-OriginalArrivalTime: 09 Nov 2007 16:13:58.0302 (UTC) FILETIME=[88833BE0:01C822EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi, Here some remarks made during reviewing. All are not that important. Page 4: typo "praocessing" Page 7: I don't like the text "may travel over a single logical hop which might consist of one or more IP hops". Text could be removed from this document. Page 11: I think is always there, so "?" should be removed. Page 13: I did not verify the compact address blocks before. I would have used bit-strings for head, mid and tail instead of octet-strings. When using octets, and could be packed into one octet. For header or for tail, two bits needed for IPv4, 4 bits for IPv6. Spending one octet would be enough. Page 16: I would use name thaslengthext for tisextended. Now we have extended type and extended length, which is confusing. For tnovalue, I would have used tnolength. Page 16: Why can't we have not included and included? I would prefer the bits tnostartindex and tnostopindex. We have 2 bits for 4 options. Page 37, 38 and 40: I think a message without and with is invalid. As such, invalid messages are depicted. Just for the record: I posted some issues before, related to native transport over IP 1) 5.1; content variable pkt-size is not clearly defined when no packet size information from transport layer and no . 2) 5.1; misses checksum field, to be used when integrity check cannot be guaranteed from lower layers. 3) On type allocation, I think range 128-255 is for experimental and not private/local. 4) Type allocation is on type, not on full type. This requires maintaining a large set of type-extension registries. Last one: I think there is no rough consensus on the restrictions issue. I don't have a strong opinion, but I think it is needed that we have a document explaining why we have those restrictions and how packetbb encoding is used most efficiently. Teco. > -----Oorspronkelijk bericht----- > Van: Ian Chakeres [mailto:ian.chakeres@gmail.com] > Verzonden: woensdag 7 november 2007 18:49 > Aan: manet > CC: Christopher Dearlove; Cedric Adjih; Thomas Heide Clausen (work) > Onderwerp: [manet] draft-ietf-manet-packetbb - WGLC > > This note announces the WG Last Call for comments on > draft-ietf-manet-packetbb-10.txt, "Generalized MANET Packet/Message > Format". > > The document can be found at: > http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-10.txt > > The document is intended to be submitted for publication as a proposed > standard document. > > Please review the document carefully and send your comments to the > MANET list and document authors. > > Given the relatively minor recent changes (added version. added packet > size. added special IANA alloc for TLV types 0 to 7.), this last call > will end Wed Nov 14th AOE. > > Thanks, > Ian Chakeres > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 09 11:36:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWqP-0004FT-UR; Fri, 09 Nov 2007 11:36:33 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqWqN-00049k-SB for manet-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 11:36:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWqN-00049a-Eo for manet@ietf.org; Fri, 09 Nov 2007 11:36:31 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IqWqM-0000wV-Af for manet@ietf.org; Fri, 09 Nov 2007 11:36:31 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA9GaGcu023284; Fri, 9 Nov 2007 18:36:25 +0200 Received: from daebh101.NOE.Nokia.com ([10.241.35.111]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 18:36:02 +0200 Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 10:36:00 -0600 Received: from [10.162.83.207] ([10.162.83.207]) by daebe101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 10:36:00 -0600 Message-ID: <47348C69.1080808@nokia.com> Date: Fri, 09 Nov 2007 08:35:53 -0800 From: "Charles E. Perkins" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: ext Justin Dean Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <200711091546.lA9FkhQ8023656@s2.itd.nrl.navy.mil> In-Reply-To: <200711091546.lA9FkhQ8023656@s2.itd.nrl.navy.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2007 16:36:00.0642 (UTC) FILETIME=[9CB04E20:01C822EE] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Justin, ext Justin Dean wrote: > An example of similar information might define a TLV "link type" in which > link types may overlap. Separation the overlapping data into separate TLVs > where possible (such as "link status" as symmetric, asymmetric, lost and > "link attribute" mpr, dead-end) removes having to use the examples I have > given below as the information now being conveyed is internally exclusive. > You are basically reiterating the single assignment model for variables, which is not always the right model. It is not helpful to reiterate that one can reformulate other designs to fit this model, as I tried to illustrate using my [1..googolplex] example. > This may not always be possible or desired in which case the examples I have > given below, I feel are good alternatives which allow for a wide range of > encodings. > No doubt they allow for a wide range. That might make them applicable for many protocols. But packetBB is, I thought, supposed to support future protocols, and I think many people are in agreement that this single-assignment model is not sufficient. And it certainly is not necessary to mandate! > Having to define the "not really" or "in addition to" TLVs come directly > from using "tricks"to compress the packet overhead They aren't really tricks. They are good techniques. They have been used before. > they are not needed if > one is willing to live with the larger overhead of not having them. The overhead is already quite considerable, and is debatably already too large. Making it worse would kill it dead in the water. > I am > actually quite happy that packetbb can encode, relatively natively, > information in this compact a form. Nobody is saying that packetBB should avoid specifying this way of compressing address ranges. So I think this line of discussion is distracting from the point. > I would argue that most protocols do > not allow for this rich of an encoding mechanism so more complicated > behaviors are really not needed. > Do you mean to say that no other protocols deal with address ranges? > >> Since I have your attention, can you explain again why in the >> heck these constraints cannot be mandated per protocol? The >> last attempt by Thomas really rated quite low on my scale of >> believability. >> > > To me the one TLV per address constraint is to help lead to coherent packets > in which information is not ambiguous at the packet level. Do you mean that the examples I presented are not coherent? > In all of my > examples a parser could take in a packet and present the information in > terms of individual address and TLV values specifically associated with > those addresses; It could do equally well this if the constraints were type dependent. > a class representation would be the same in all cases, > without needed any protocol knowledge. Why is this a good thing? Why not enforce that all classes have exactly 38 bytes of data storage? Why not have two kinds of classes? Isn't this well-known technology? > I think my confusion on what was > exactly being conveyed with the original example clearly represents what I > am trying to say here. It was not a very confusing example, and anyone reading a protocol specification would not make the mistake. If you like, we could try to get a reading from other members of the working group whether they were confused by my example. I did, after all, explicitly use the word "range" to describe the address range objects. > Furthermore different orderings of TLVs could change > the meaning of the data being represented. > Not in my example. > To me this added "complication" in defining TLVs is worth the explicitness > it forces. I also think that the example here discussed will not be the > normal mode of TLV operation but the exception, but that when it does happen > it can be supported. > I think that this explicitness can be specified per protocol. So I did not find anything in your discussion to support the mandate. And, for protocol designers who find the constraint worthwhile, it can easily be specified to have them. They are going to make normative refereneces to packetBB anyway. A lot of discussions about packetBB have gone this way. I asked "Why mandate for all protocols?" The answer is that "packetBB has good features". But this is not at issue. So, not helpful to the discussion! Sometimes the answer seems to be "our parser likes it better to avoid a test on protocol type". But I reckon the likely way for constructing such a parser should be able to do this without much problem, with several different kinds of solutions available. One time it was claimed that there would result a "quick abort" feature. Then that was characterized as a minor benefit, and I presented discussion that pointed out that it was often likely to be a performance loss. It was suggested to be a mechanism to deter DoS attacks. That suggestion did not last very long. I have provided examples on several occasions, showing the danger of exorbitant packet bloat, but the next round of discussion claims that no examples were given. At root, I think the problem is of fixation on the following characterization: > To me the one TLV per address constraint is to help lead to coherent packets > in which information is not ambiguous at the packet level. So to do anything other than single-value assignment to variables is (?) characterized as incoherent? I seem to remember also that it was deemed inelegant and perhaps even "crappy". Well, it's _NOT_ incoherent or crappy, when needed. If you find that the single assignment model is appropriate for your protocol designs, then that's great! But it does not mean that other protocol designs are unworthy of support within the packetBB metaspecification. Furthermore, I reiterate that the constraints were inserted into the specification without discussion on the mailing list, or at least without significant discussion that registered on my mind and I typically read every message not including spams. Regards, Charlie P. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 09 13:58:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZ3N-0002l1-4s; Fri, 09 Nov 2007 13:58:05 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqZ3M-0002kv-A0 for manet-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 13:58:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZ3L-0002jd-VZ for manet@ietf.org; Fri, 09 Nov 2007 13:58:03 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqZ3H-0001rI-BY for manet@ietf.org; Fri, 09 Nov 2007 13:58:03 -0500 X-IronPort-AV: E=Sophos;i="4.21,397,1188792000"; d="scan'208";a="75618841" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Nov 2007 13:57:58 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA9IvwSY018973; Fri, 9 Nov 2007 13:57:58 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA9IvnWD017353; Fri, 9 Nov 2007 18:57:57 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 13:57:50 -0500 Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 13:57:50 -0500 Message-ID: <4734AD84.8060704@cisco.com> Date: Fri, 09 Nov 2007 13:57:08 -0500 From: Russ White User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Charles E. Perkins" Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <200711091546.lA9FkhQ8023656@s2.itd.nrl.navy.mil> <47348C69.1080808@nokia.com> In-Reply-To: <47348C69.1080808@nokia.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2007 18:57:50.0641 (UTC) FILETIME=[6D0B1A10:01C82302] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15534.002 X-TM-AS-Result: No--1.144500-8.000000-4 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2623; t=1194634678; x=1195498678; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[manet]=20draft-ietf-manet-packetbb=20-=20WGLC |Sender:=20 |To:=20=22Charles=20E.=20Perkins=22=20; bh=SpHSd/vmCBrtPx1xJZs+1qlvx7JiM5/ey5kAEDJ5a6U=; b=RdkUrd2IDNViMuXuPO5XE0wPw3hV1/AJJasHnn8jSArzYBpihpo2DJQ+t4aU8KCXz6kBuky5 +6UWmkk9hU4eL/6yOlchODg+TTOgeJxaYlL/xQr9QKcqq98HJRCCh2bs; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> Having to define the "not really" or "in addition to" TLVs come directly >> from using "tricks"to compress the packet overhead > They aren't really tricks. They are good techniques. They have been used > before. > >> they are not needed if >> one is willing to live with the larger overhead of not having them. I would suggest that all sorts of situations exist in the real world--there is a sliding scale between packet efficiency on the wire, and CPU efficiency. To assume that all protocols will fall in precisely the same place on this sliding scale is a rather large assumption, IMHO. >> I would argue that most protocols do >> not allow for this rich of an encoding mechanism so more complicated >> behaviors are really not needed. I would completely disagree with this idea. Have you examined the BGP packet encoding? Or perhaps the ROAs being put on the standard track for BGP? These are rather complex packet encodings, probably more so that what's being proposed here, and yet--they don't require ordering in the sense that this proposal requires it. There is a tradeoff in this space, between ordering to imply application, and explicitly signaling the application (meaning how to apply the information in the packet). IMHO, packetbb, as it stands right now, is an extreme example on one end of the scale. All anyone is asking is that the options exist to allow packetbb to be used at various points along that scale, rather than only in one place. > It was not a very confusing example, and anyone reading > a protocol specification would not make the mistake. > If you like, we could try to get a reading from other members > of the working group whether they were confused by my > example. I did, after all, explicitly use the word "range" to > describe the address range objects. I certainly understood the example, and believed it was a good, specific example, of an encoding mechanism that would be problematic as packetbb currently stands. > And it certainly is not necessary to mandate! IMHO, this is the root of the problem. There are a lot of creative solutions which allow protocols which want to encode in this way to actually encode in this way, and allows protocols which don't not to. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFHNK2EER27sUhU9OQRAt17AKCkorMV3Xhaw36RCw66x7RCU221uQCYux4h 8G+N3tUJjSS2mE5TIXWLdQ== =z33W -----END PGP SIGNATURE----- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 09 14:31:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZZt-0000AX-Lt; Fri, 09 Nov 2007 14:31:41 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqZZr-0008VV-Tp for manet-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 14:31:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZZr-0008V1-Jn for manet@ietf.org; Fri, 09 Nov 2007 14:31:39 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqZZn-0003ec-UT for manet@ietf.org; Fri, 09 Nov 2007 14:31:39 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lA9JVUou004877; Fri, 9 Nov 2007 14:31:30 -0500 (EST) Message-Id: <200711091931.lA9JVUou004877@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007110914312932381 ; Fri, 09 Nov 2007 14:31:29 -0500 From: "Justin Dean" To: "'Russ White'" , "'Charles E. Perkins'" Subject: RE: [manet] draft-ietf-manet-packetbb - WGLC Date: Fri, 9 Nov 2007 14:36:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcgjAnYy0AAdf8R4SbCU2oMiNjFfRQAApNuw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <4734AD84.8060704@cisco.com> X-Spam-Score: 1.5 (+) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > -----Original Message----- > From: Russ White [mailto:riw@cisco.com] > Sent: Friday, November 09, 2007 1:57 PM > To: Charles E. Perkins > Cc: ext Justin Dean; 'Manet' > Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > >> Having to define the "not really" or "in addition to" TLVs come > >> directly from using "tricks"to compress the packet overhead > > > They aren't really tricks. They are good techniques. They > have been > > used before. > > > >> they are not needed if > >> one is willing to live with the larger overhead of not having them. > > I would suggest that all sorts of situations exist in the > real world--there is a sliding scale between packet > efficiency on the wire, and CPU efficiency. To assume that > all protocols will fall in precisely the same place on this > sliding scale is a rather large assumption, IMHO. No one is making this assumption and in fact packetbb allows for this range. If its worth reducing overhead of using these good techniques for the type of data to be transmitted then they can be used. If not they don't need to be was all I was saying. > > >> I would argue that most protocols do not allow for this > rich of an > >> encoding mechanism so more complicated behaviors are really not > >> needed. > > I would completely disagree with this idea. Have you examined > the BGP packet encoding? Or perhaps the ROAs being put on the > standard track for BGP? These are rather complex packet > encodings, probably more so that what's being proposed here, > and yet--they don't require ordering in the sense that this > proposal requires it. > I knew this line was going to come back to get me. I was speaking to the address block compression along with the flexible multivalue TLV structure and not the ordering. I will certainly go over those documents and retract this statement. > There is a tradeoff in this space, between ordering to imply > application, and explicitly signaling the application > (meaning how to apply the information in the packet). IMHO, > packetbb, as it stands right now, is an extreme example on > one end of the scale. > > All anyone is asking is that the options exist to allow > packetbb to be used at various points along that scale, > rather than only in one place. > > > It was not a very confusing example, and anyone reading a protocol > > specification would not make the mistake. > > If you like, we could try to get a reading from other > members of the > > working group whether they were confused by my example. I > did, after > > all, explicitly use the word "range" to describe the address range > > objects. > > I certainly understood the example, and believed it was a > good, specific example, of an encoding mechanism that would > be problematic as packetbb currently stands. > I too thought the example was good. What I thought was confusing was the meaning implied by [X1,X2]. Possible meanings could be X1 and X2 (almost default the second example I gave) X1 or X2 X2 not X1 (the first example I gave) X1 then X2 I thought I clearly demonstrated how it was not really problematic to encode almost exactly as Charlie wished. (change of TLV definition and additional TLV type) The size of encoding was the same only the value of the type field was different. > > And it certainly is not necessary to mandate! > > IMHO, this is the root of the problem. There are a lot of > creative solutions which allow protocols which want to encode > in this way to actually encode in this way, and allows > protocols which don't not to. > It does allow them to. > :-) > > Russ > Justin Ps I am glad that we are discussing merits and draw backs at this point. > - -- > riw@cisco.com CCIE <>< Grace Alone > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD4DBQFHNK2EER27sUhU9OQRAt17AKCkorMV3Xhaw36RCw66x7RCU221uQCYux4h > 8G+N3tUJjSS2mE5TIXWLdQ== > =z33W > -----END PGP SIGNATURE----- > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 09 14:36:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZef-0001ZK-2i; Fri, 09 Nov 2007 14:36:37 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IqZed-0001Yo-MG for manet-confirm+ok@megatron.ietf.org; Fri, 09 Nov 2007 14:36:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqZed-0001Yg-CX for manet@ietf.org; Fri, 09 Nov 2007 14:36:35 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqZeZ-0003wd-WB for manet@ietf.org; Fri, 09 Nov 2007 14:36:35 -0500 X-IronPort-AV: E=Sophos;i="4.21,397,1188792000"; d="scan'208";a="75623852" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Nov 2007 14:36:32 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA9JaV7w009002; Fri, 9 Nov 2007 14:36:31 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lA9JaCdk016727; Fri, 9 Nov 2007 19:36:31 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 14:36:27 -0500 Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Nov 2007 14:36:27 -0500 Message-ID: <4734B691.8030007@cisco.com> Date: Fri, 09 Nov 2007 14:35:45 -0500 From: Russ White User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Justin Dean Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <200711091931.lA9JVUou004877@s2.itd.nrl.navy.mil> In-Reply-To: <200711091931.lA9JVUou004877@s2.itd.nrl.navy.mil> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Nov 2007 19:36:27.0516 (UTC) FILETIME=[D2022BC0:01C82307] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15534.002 X-TM-AS-Result: No--4.555800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1695; t=1194636991; x=1195500991; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[manet]=20draft-ietf-manet-packetbb=20-=20WGLC |Sender:=20 |To:=20Justin=20Dean=20; bh=shP5KKHZrbAJT3tx6cBcDddjZWMLI+nor5iHF/nhY0s=; b=BV9pynC5ZQRaew/VkTQY9w64bmaMA2tQVGk3Z+JxQSiRFoLQP0fFSLbK+BfKbG/nFVdcZPFd xOrvHHL+BSi2BqQyYjsh5Q559PmJlOZAm9g630Q0VYt+39rcTA1Lca2a; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: 'Manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> I thought I clearly demonstrated how it was not really problematic to encode >> almost exactly as Charlie wished. (change of TLV definition and additional >> TLV type) The size of encoding was the same only the value of the type >> field was different. The problem is your additional TLV is counterintuitive.... And something that's not done. "Oh, this part I just said applies, it doesn't really apply to this specific piece of information, so just take that back out of your structures." >>>> And it certainly is not necessary to mandate! > IMHO, this is the root of the problem. There are a lot of > creative solutions which allow protocols which want to encode > in this way to actually encode in this way, and allows > protocols which don't not to. > >> It does allow them to. Hmmm.... Not according to what I read in the draft, and not according to what I see on list. The packet formatting is very strictly ordered, and the general response has been: "If you don't like the ordering, just hold the entire packet in memory, and process it in some other order." >> Ps I am glad that we are discussing merits and draw backs at this point. I would prefer to be discussing a mechanism which would allow protocols to use require ordering, while others don't. It would be a much more productive discussion. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHNLaQER27sUhU9OQRAsoKAJ0SKXCZnxW6rU25OcPH1Mxc50Y7oQCfei9t ZAgnBmuZlrCiIYa8NhKQ4h8= =ky3J -----END PGP SIGNATURE----- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Nov 11 14:22:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrINl-0000D4-Ak; Sun, 11 Nov 2007 14:22:09 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IrINi-0000Be-Cu for manet-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 14:22:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrINh-0000AP-Fg for manet@ietf.org; Sun, 11 Nov 2007 14:22:06 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrINg-0005qW-Uw for manet@ietf.org; Sun, 11 Nov 2007 14:22:05 -0500 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1IrINf-0003LV-R2 for manet@ietf.org; Sun, 11 Nov 2007 11:22:04 -0800 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <47326BAE.4050008@cisco.com> References: <7FB7EE0A621BA44B8B69E5F0A09DC76404E7856E@xmb-rtp-208.amer.cisco.com> <548143B0-4F31-4921-A29E-E119B868153D@thomasclausen.org> <47325447.1090307@nokia.com> <47326BAE.4050008@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4E6CE8E3-0BDB-40A8-9E88-4609B41938C5@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC Date: Sat, 10 Nov 2007 19:16:01 +1000 To: manet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: dcedbbeaec314583a5a6d4e37e27e533 X-Spam-Score: 1.6 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On Nov 8, 2007, at 11:51 AM, Russ White wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> Sufficient objections have been raised to indicate that the >> mandates should be softened. This can be done in a way >> that would not represent any significant delay to the progress >> of the document, once agreement in principle is obtained on >> the wisdom of relaxing the mandate. > > I completely agree with this, and would like to see a "mailing list > hum" > on this.... There appears to be a very small group of people > involved in > the discussion, but I'm getting some off list email supporting this > position. I'd like to see what the real concensus looks like, and not > just a small group of folks discussing it. > > :-) The problem seems to be that neither case is grounded in fact. "It will lead to more complex parser code" and "no it won't" are hypothetical arguments. The fact that not every possible packet can be encoded with ordering isn't a show-stopper; if a format can do everything, chances are it can't do anything well. Let's not get trapped in the rathole of software engineering generalization, and instead follow Butler Lampson's advice. Unless we elevate the discussion, this debate will continue to be a circular one. How about this: the pro-order folks should write the meanest, leanest parser they can and the pro-reorder folks should do the same. If it turns out that the no-order parser is 15 times as long and has numerous bugs, then we'll know what the answer is. But if it's only twice the size and is no more bug-prone, that seems like a good tradeoff for flexibility. And if one side doesn't want to write a parser, then maybe they shouldn't tell the other side how to write their code... Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Nov 11 18:04:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrLqU-0000mv-7S; Sun, 11 Nov 2007 18:04:02 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IrLqS-0000kT-Bg for manet-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 18:04:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrLqS-0000kE-1q for manet@ietf.org; Sun, 11 Nov 2007 18:04:00 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrLqP-0005Zs-L5 for manet@ietf.org; Sun, 11 Nov 2007 18:04:00 -0500 X-IronPort-AV: E=Sophos;i="4.21,402,1188792000"; d="scan'208";a="136650841" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2007 18:03:58 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lABN3vYC030286; Sun, 11 Nov 2007 18:03:57 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lABN3vdQ014461; Sun, 11 Nov 2007 23:03:57 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 18:03:57 -0500 Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 18:03:56 -0500 Message-ID: <47378A5A.3070205@cisco.com> Date: Sun, 11 Nov 2007 18:03:54 -0500 From: Russ White User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Levis Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <7FB7EE0A621BA44B8B69E5F0A09DC76404E7856E@xmb-rtp-208.amer.cisco.com> <548143B0-4F31-4921-A29E-E119B868153D@thomasclausen.org> <47325447.1090307@nokia.com> <47326BAE.4050008@cisco.com> <4E6CE8E3-0BDB-40A8-9E88-4609B41938C5@cs.stanford.edu> In-Reply-To: <4E6CE8E3-0BDB-40A8-9E88-4609B41938C5@cs.stanford.edu> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2007 23:03:56.0630 (UTC) FILETIME=[2315B760:01C824B7] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15538.002 X-TM-AS-Result: No--8.792000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2017; t=1194822237; x=1195686237; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[manet]=20draft-ietf-manet-packetbb=20-=20WGLC |Sender:=20 |To:=20Philip=20Levis=20; bh=7VxJnmowV8duXC7leyIr5f5jQEpn/X+GGgddLRaDuRs=; b=UCBBKTc5blzPF1GHEKAeQp8lQfeKSFYxRZY2Qr8crnsvdtTbHPOqNrUxcq3rj80lNcNYu6h4 h6ogQNpKDA0MOhputkscPJE8n/9I0DTdQS/U3mo1wuRUrh0wESs1rjoV; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Unless we elevate the discussion, this debate will continue to be a > circular one. How about this: the pro-order folks should write the > meanest, leanest parser they can and the pro-reorder folks should do the > same. If it turns out that the no-order parser is 15 times as long and > has numerous bugs, then we'll know what the answer is. But if it's only > twice the size and is no more bug-prone, that seems like a good tradeoff > for flexibility. And if one side doesn't want to write a parser, then > maybe they shouldn't tell the other side how to write their code... How about this--we come up with a packet format that allows either in order or out of order information transport. If a specific protocol only wants to use in order encoding, then they can do so. If another protocol only wants to use out of order encoding, then they can do so. If, in the future, someone comes up with a way to make either encoding mechanism 1 million times more efficient than the other, then the protocol can support it. It makes no sense to set something like this in stone for a packet format designed to support many protocols over a lot of years--for the foreseeable future, in fact. All a "contest" would show is that for today, these two methods either break even, or one beats the other by some small amount, using current languages, and current development strategies, for current processor technology. Since we've no idea what sort of languages, development strategies, and hardware might be used in the future, the results would be trapped in a time bubble. In other words, the results of such a "contest" would be, effectively, useless. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHN4paER27sUhU9OQRAilhAKCsDJPmN9Hmz6MXTp2Pupinnp7aAwCgwk0R h6fmCMh9B/KHCUdO7JeDDA8= =6T/i -----END PGP SIGNATURE----- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Nov 11 18:12:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrLyi-0003US-HA; Sun, 11 Nov 2007 18:12:32 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IrLyg-0003Oz-TA for manet-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 18:12:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrLyg-0003Np-HO for manet@ietf.org; Sun, 11 Nov 2007 18:12:30 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrLyd-0005nW-CO for manet@ietf.org; Sun, 11 Nov 2007 18:12:30 -0500 X-IronPort-AV: E=Sophos;i="4.21,402,1188792000"; d="scan'208";a="136651186" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 11 Nov 2007 18:12:28 -0500 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lABNCRUe010951; Sun, 11 Nov 2007 18:12:27 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lABNCQdQ016975; Sun, 11 Nov 2007 23:12:26 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 18:12:26 -0500 Received: from [127.0.0.1] ([10.82.175.126]) by xmb-rtp-203.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Nov 2007 18:12:26 -0500 Message-ID: <47378C58.7020403@cisco.com> Date: Sun, 11 Nov 2007 18:12:24 -0500 From: Russ White User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Levis Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC References: <7FB7EE0A621BA44B8B69E5F0A09DC76404E7856E@xmb-rtp-208.amer.cisco.com> <548143B0-4F31-4921-A29E-E119B868153D@thomasclausen.org> <47325447.1090307@nokia.com> <47326BAE.4050008@cisco.com> <4E6CE8E3-0BDB-40A8-9E88-4609B41938C5@cs.stanford.edu> In-Reply-To: <4E6CE8E3-0BDB-40A8-9E88-4609B41938C5@cs.stanford.edu> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Nov 2007 23:12:26.0349 (UTC) FILETIME=[52E6A9D0:01C824B8] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15538.002 X-TM-AS-Result: No--7.506700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1946; t=1194822747; x=1195686747; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[manet]=20draft-ietf-manet-packetbb=20-=20WGLC |Sender:=20 |To:=20Philip=20Levis=20; bh=Uc4jPePYA3jFgK6PmHXWg8oxq9z6KisBdSglBnVL8C0=; b=m900icgW4V0yCE6L14PxNPS4EISfhzAZUV9i5MN/DmPAqHURiwERI5QnJGwVBpIrNM80zC8v tI5fr9B36r1HevvbgiJo2nkFvVo+Fu/oQZrr1HD2owSXv6k8gDUKrwGG; Authentication-Results: rtp-dkim-2; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > The problem seems to be that neither case is grounded in fact. "It will > lead to more complex parser code" and "no it won't" are hypothetical > arguments. The fact that not every possible packet can be encoded with > ordering isn't a show-stopper; if a format can do everything, chances > are it can't do anything well. Let's not get trapped in the rathole of > software engineering generalization, and instead follow Butler Lampson's > advice. BTW, if everyone who supports in order encoding only is _so_ certain it's the only correct way to do things, then why does it hurt to offer other options? If you're correct, and in-order encoding _always_ saves so much in code and efficiency that it would be insane to do it any other way, then the parts of the standard supporting out of order encoding will be a dead letter anyway. What's the harm in allowing the option, if you think the advantages are so clear cut one way that no-one will ever use anything else? I'll go back and suggest what I suggested in the first place--it's perfectly fine to have sections of the packet which must be processed before other sections of the packet. It's perfect fine to have sections of the packet where TLVs must be in order. It's also perfectly fine to have sections of the packet where the TLVs can be in any order, or where the processing results do not depend on the order. Generally speaking, atomic operations are to be desired. They aren't always possible, but they are to be desired. The way the draft is currently written, there's no such thing as an "atomic operation." :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHN4xYER27sUhU9OQRAjxTAKDIeiV1rbnlY7ayt/GH4RE2aWkkpACeLIA6 Ywon5WPWR6RHhfHoJzeJ3pc= =sP2m -----END PGP SIGNATURE----- _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Nov 11 21:50:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrPNy-0004OQ-VS; Sun, 11 Nov 2007 21:50:50 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IrPNx-0004G0-1M for manet-confirm+ok@megatron.ietf.org; Sun, 11 Nov 2007 21:50:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrPNw-0004Fd-Kj for manet@ietf.org; Sun, 11 Nov 2007 21:50:48 -0500 Received: from cs-smtp-1.stanford.edu ([171.64.64.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrPNv-0004qu-7l for manet@ietf.org; Sun, 11 Nov 2007 21:50:48 -0500 Received: from c-71-198-71-178.hsd1.ca.comcast.net ([71.198.71.178] helo=[192.168.2.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1IrPNu-0000pX-5X; Sun, 11 Nov 2007 18:50:46 -0800 In-Reply-To: <47378A5A.3070205@cisco.com> References: <7FB7EE0A621BA44B8B69E5F0A09DC76404E7856E@xmb-rtp-208.amer.cisco.com> <548143B0-4F31-4921-A29E-E119B868153D@thomasclausen.org> <47325447.1090307@nokia.com> <47326BAE.4050008@cisco.com> <4E6CE8E3-0BDB-40A8-9E88-4609B41938C5@cs.stanford.edu> <47378A5A.3070205@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <99B56BB4-500E-429A-ADD8-1C297A557F80@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Subject: Re: [manet] draft-ietf-manet-packetbb - WGLC Date: Sun, 11 Nov 2007 19:50:56 -0800 To: Russ White X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -2.5 X-Spam-Checker-Version: SpamAssassin 3.0.4-cs-csdcf (2005-06-05) on cs-smtp-1.Stanford.EDU X-Scan-Signature: d568c20fab0e2ccae07d583947984559 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On Nov 11, 2007, at 3:03 PM, Russ White wrote: > > > It makes no sense to set something like this in stone for a packet > format designed to support many protocols over a lot of years--for the > foreseeable future, in fact. All a "contest" would show is that for > today, these two methods either break even, or one beats the other by > some small amount, using current languages, and current development > strategies, for current processor technology. Since we've no idea what > sort of languages, development strategies, and hardware might be > used in > the future, the results would be trapped in a time bubble. In other > words, the results of such a "contest" would be, effectively, useless. On one hand, I agree with you; I think flexibility is really important, and the restriction limits flexibility. On the other, the folks advocating it are those who wrote the document and have implemented parsers for it, and it's important we don't ignore the conclusions they've reached from that experience. To be fair, I don't think they've really articulated the case that well, but it's clear they strongly believe the restriction is a good thing. And so if we really think that's not true, and care about the draft, then we should run an experiment to test the hypothesis (implement a parser), which will hopefully refute or validate the claim. Phil _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 12 03:45:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrUuy-0008HE-SH; Mon, 12 Nov 2007 03:45:16 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IrUux-0008Gy-Bl for manet-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 03:45:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrUux-0008Gq-22 for manet@ietf.org; Mon, 12 Nov 2007 03:45:15 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrUuu-0000Lq-BC for manet@ietf.org; Mon, 12 Nov 2007 03:45:15 -0500 Received: (qmail 13607 invoked from network); 12 Nov 2007 09:45:10 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 12 Nov 2007 09:45:10 +0100 From: "Teco Boot" To: "'manet'" , "'Christopher Dearlove'" , "'Cedric Adjih'" , "'Thomas Heide Clausen \(work\)'" References: <374005f30711070949i620d3adeo116ea3d4cb64a203@mail.gmail.com> <006501c822eb$81367d70$83a37850$@nl> In-Reply-To: <006501c822eb$81367d70$83a37850$@nl> Subject: RE: [manet] draft-ietf-manet-packetbb - WGLC Date: Mon, 12 Nov 2007 09:44:28 +0100 Message-ID: <000601c82508$50218800$f0649800$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcghZrzr54ZDM59PSNyL7iHjjcN7owBbw58QAIqO5NA= Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Review on review;-) Apology for any misconception. Teco. > Page 13: I did not verify the compact address blocks before. I would > have > used bit-strings for head, mid and tail instead of octet-strings. > When using octets, and could be packed into > one > octet. For header or for tail, two bits needed for IPv4, 4 bits for > IPv6. > Spending one octet would be enough. Claim is false, length in octets is range 0 to 4 (v4), requiring 3 bits or 0 to 16 (v6) requiring 5 bits. Two times 5 bits does not fit in one octet. > Page 37, 38 and 40: I think a message without and with > is invalid. As such, invalid messages are depicted. Comment is correct or incorrect, depending on what forwarding rules are mandated. When text is included that MUST be decremented when forwarding, and message MUST NOT be forwarded when reaching zero, the examples are valid. I overlooked this option, as I was searching in the draft and found nothing like that. Proposed text (out of IPv6 - RFC2460): Hop Limit 8-bit unsigned integer. Decremented by 1 by each node that forwards the packet. The packet is discarded if Hop Limit is decremented to zero. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 12 05:53:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrWv3-0002Tx-Pg; Mon, 12 Nov 2007 05:53:29 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IrWv2-0002T9-2D for manet-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 05:53:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrWv1-0002SZ-No for manet@ietf.org; Mon, 12 Nov 2007 05:53:27 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrWv0-00004w-Sj for manet@ietf.org; Mon, 12 Nov 2007 05:53:27 -0500 Received: (qmail 13713 invoked from network); 12 Nov 2007 11:53:23 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 12 Nov 2007 11:53:23 +0100 From: "Teco Boot" To: "'manet'" Date: Mon, 12 Nov 2007 11:52:44 +0100 Message-ID: <001601c8251a$39a919a0$acfb4ce0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcglGgRARfyq4W9pT9OSKQfxzcnX2w== Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [manet] NHDP forwarding rules and hoplimit X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi, I checked NHDP on forwarding rules. I think the text is not in line with PacketBB. NHDP assumes forwarders understand what messages are and PacketBB defines the contrary. NHDP: o HELLO messages MUST NOT be forwarded. o HELLO messages MAY be included in multi-message packets as specified in [1]. PacketBB: o A message header format, which may allow a node to make praocessing and forwarding decisions based on the node's present state and the message header, without inspecting and parsing the message body. Message header information permits single- and multi-hop message diffusion. A solution would be mandating using NHDP messages with hoplimit set to 1. This option is used in the example in appendix B. Cheers, Teco _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 12 06:00:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrX1h-0001o6-36; Mon, 12 Nov 2007 06:00:21 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IrX1f-0001lq-8F for manet-confirm+ok@megatron.ietf.org; Mon, 12 Nov 2007 06:00:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrX1d-0000nx-On for manet@ietf.org; Mon, 12 Nov 2007 06:00:17 -0500 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrX0r-0000KS-1Y for manet@ietf.org; Mon, 12 Nov 2007 05:59:29 -0500 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lACAxOT8022874 for ; Mon, 12 Nov 2007 10:59:24 GMT 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 lACAxNRR028554 for ; Mon, 12 Nov 2007 10:59:23 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 12 Nov 2007 10:59:23 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 12 Nov 2007 10:59:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] NHDP forwarding rules and hoplimit Date: Mon, 12 Nov 2007 10:59:22 -0000 Message-ID: In-Reply-To: <001601c8251a$39a919a0$acfb4ce0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP forwarding rules and hoplimit Thread-Index: AcglGgRARfyq4W9pT9OSKQfxzcnX2wAAIIJg References: <001601c8251a$39a919a0$acfb4ce0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "manet" X-OriginalArrivalTime: 12 Nov 2007 10:59:23.0583 (UTC) FILETIME=[158AECF0:01C8251B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Yes, if an NHDP HELLO message has a header it should have a hop limit of one, as the example. There is a little tidying up needed in this area (and a few others) but revising NHDP isn't the critcal priority right this minute. We hope to do it very soon however. =20 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 12 November 2007 10:53 To: 'manet' Subject: [manet] NHDP forwarding rules and hoplimit *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Hi, I checked NHDP on forwarding rules. I think the text is not in line with PacketBB. NHDP assumes forwarders understand what messages are and PacketBB defines the contrary. NHDP: o HELLO messages MUST NOT be forwarded. o HELLO messages MAY be included in multi-message packets as specified in [1]. PacketBB: o A message header format, which may allow a node to make praocessing and forwarding decisions based on the node's present state and the message header, without inspecting and parsing the message body. Message header information permits single- and multi-hop message diffusion. A solution would be mandating using NHDP messages with hoplimit set to 1. This option is used in the example in appendix B. Cheers, Teco =20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 13 03:55:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrrYM-0006Nt-2l; Tue, 13 Nov 2007 03:55:26 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IrrYK-0006MK-7G for manet-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 03:55:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrrYJ-0006Jj-6T for manet@ietf.org; Tue, 13 Nov 2007 03:55:23 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrrYG-0001Cj-Ij for manet@ietf.org; Tue, 13 Nov 2007 03:55:23 -0500 Received: (qmail 8653 invoked from network); 13 Nov 2007 09:55:19 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 13 Nov 2007 09:55:19 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'manet'" References: <001601c8251a$39a919a0$acfb4ce0$@nl> In-Reply-To: Subject: RE: [manet] NHDP forwarding rules and hoplimit Date: Tue, 13 Nov 2007 09:54:36 +0100 Message-ID: <009401c825d2$e4f65d50$aee317f0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcglGgRARfyq4W9pT9OSKQfxzcnX2wAAIIJgAC2m4qA= Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thanks. I am still worried about the packetBB claim on split in message processing & forwarding and inspecting & parsing. For example, I don't like leakage of OLSR information towards DYMO-only routers and forwarded further. Or when an AreaID TLV is created, TC message leakage into other areas. Or forwarding messages with incorrect CRC TLV or false authentication TLV. I can imagine many other evil effects. Teco. > Yes, if an NHDP HELLO message has a header it > should have a hop limit of one, as the example. > There is a little tidying up needed in this > area (and a few others) but revising NHDP > isn't the critcal priority right this minute. > We hope to do it very soon however. > PacketBB: > o A message header format, which may allow a node to make > praocessing and forwarding decisions based on the node's present > state and the message header, without inspecting and parsing the > message body. Message header information permits single- and > multi-hop message diffusion. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 13 04:48:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrsO4-0000hY-QI; Tue, 13 Nov 2007 04:48:52 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IrsO0-0000ZV-HS for manet-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 04:48:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrsO0-0000ZI-7n for manet@ietf.org; Tue, 13 Nov 2007 04:48:48 -0500 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrsNx-00035f-Ea for manet@ietf.org; Tue, 13 Nov 2007 04:48:48 -0500 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 lAD9mdNd015139 for ; Tue, 13 Nov 2007 09:48:39 GMT 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 lAD9md8U014163 for ; Tue, 13 Nov 2007 09:48:39 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 13 Nov 2007 09:48:38 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 13 Nov 2007 09:48:38 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] NHDP forwarding rules and hoplimit Date: Tue, 13 Nov 2007 09:48:37 -0000 Message-ID: In-Reply-To: <009401c825d2$e4f65d50$aee317f0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] NHDP forwarding rules and hoplimit Thread-Index: AcglGgRARfyq4W9pT9OSKQfxzcnX2wAAIIJgAC2m4qAAAgxBUA== References: <001601c8251a$39a919a0$acfb4ce0$@nl> <009401c825d2$e4f65d50$aee317f0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "manet" X-OriginalArrivalTime: 13 Nov 2007 09:48:38.0645 (UTC) FILETIME=[5DC68A50:01C825DA] X-Spam-Score: -4.0 (----) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Any actual forwarding would be done by OLSRv2 and/or DYMO. packetbb doesn't control forwarding (how could it? - OLSRv2 uses MPR forwarding which packetbb knows nothing about, as just one example). packetbb just has the hop count/limit that should be incremented/ decremented (but not by packetbb - there is no packetbb protocol, just a parser - but by the appropriate protocol). Typically if there's an OLSRv2 node, it may or may not forward a TC message. If there's a neighbouring DYMO-only node its existence won't encourage OLSRv2 to forward the message (it won't be an MPR) but the OLSRv2 node may forward it for other reasons. The DYMO node may then receive the packet with the TC message in (it's broadcast) but then it's up to DYMO to do whatever it thinks is appropriate to an unknown message - which I understand is intended to be discard it (perfectly allowed, regardless of hop limit). No problems. -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 13 November 2007 08:55 To: Dearlove, Christopher (UK); 'manet' Subject: RE: [manet] NHDP forwarding rules and hoplimit *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Thanks. I am still worried about the packetBB claim on split in message processing & forwarding and inspecting & parsing. For example, I don't like leakage of OLSR information towards DYMO-only routers and forwarded further. Or when an AreaID TLV is created, TC message leakage into other areas. Or forwarding messages with incorrect CRC TLV or false authentication TLV. I can imagine many other evil effects. Teco. > Yes, if an NHDP HELLO message has a header it > should have a hop limit of one, as the example. > There is a little tidying up needed in this > area (and a few others) but revising NHDP > isn't the critcal priority right this minute. > We hope to do it very soon however. > PacketBB: > o A message header format, which may allow a node to make > praocessing and forwarding decisions based on the node's present > state and the message header, without inspecting and parsing the > message body. Message header information permits single- and > multi-hop message diffusion. ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 13 13:19:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0MF-0001Vt-R1; Tue, 13 Nov 2007 13:19:31 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Is0ME-0001Vn-Op for manet-confirm+ok@megatron.ietf.org; Tue, 13 Nov 2007 13:19:30 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is0ME-0001VD-Dp for manet@ietf.org; Tue, 13 Nov 2007 13:19:30 -0500 Received: from mail.unb.br ([164.41.2.1]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Is0MD-00019F-QG for manet@ietf.org; Tue, 13 Nov 2007 13:19:30 -0500 Received: from laguardia (unknown [164.41.101.117]) by mail.unb.br (Postfix) with ESMTP id 123DC2676AA for ; Tue, 13 Nov 2007 16:19:16 -0200 (BRST) From: "Janaina Laguardia Areal" To: Date: Tue, 13 Nov 2007 16:19:10 -0200 Message-ID: <003701c82621$b0be31d0$123a9570$@br> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgmIa83OY2RyegrQfe8vdpBrcGETA== Content-Language: pt-br X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Subject: [manet] IPS X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1298071781==" Errors-To: manet-bounces@ietf.org Esta é uma mensagem em várias partes no formato MIME. --===============1298071781== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01C82610.ED3561D0" Content-Language: pt-br Esta é uma mensagem em várias partes no formato MIME. ------=_NextPart_000_0038_01C82610.ED3561D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Guys, =20 I need some help, any of you have some paper ou draft about IPS in ad = hoc =BF =20 Thanks for help. =20 Janaina Laguardia Areal NSOC/CPD - UnB +55 61 3349-2557 =20 ------=_NextPart_000_0038_01C82610.ED3561D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Guys,

 

I need some help, any of you = have some paper ou draft about IPS in ad hoc =BF

 

Thanks for = help.

 

Janaina Laguardia Areal

NSOC/CPD - UnB

+55 61 3349-2557

 

------=_NextPart_000_0038_01C82610.ED3561D0-- --===============1298071781== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1298071781==-- From manet-bounces@ietf.org Wed Nov 14 02:50:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsD1G-0007UL-FK; Wed, 14 Nov 2007 02:50:42 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsD1F-0007TP-4a for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 02:50:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsD19-0007Gv-By for manet@ietf.org; Wed, 14 Nov 2007 02:50:35 -0500 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsD18-00072a-IS for manet@ietf.org; Wed, 14 Nov 2007 02:50:34 -0500 Received: from hpsmtp-eml03.kpnxchange.com ([213.75.38.103]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 08:50:33 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml03.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 08:50:33 +0100 From: "Teco Boot" To: "'manet'" Date: Wed, 14 Nov 2007 08:50:23 +0100 Message-ID: <005d01c82693$03655640$0a3002c0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgmkv9sX7wsygmoQD6LuqeCJfaYUA== Content-Language: nl x-cr-hashedpuzzle: BL9t BNbH BOWh CnAL CwnU DMdB Dmwv E40T GEhY HDJz HEjg H+ce I+Kt J+QX K4Jq LC42; 1; bQBhAG4AZQB0AEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {F905BFA5-0F3B-4237-BF1B-64F544D37F04}; dABlAGMAbwBAAGkAbgBmAC0AbgBlAHQALgBuAGwA; Wed, 14 Nov 2007 07:50:17 GMT; RgBvAHIAdwBhAHIAZABpAG4AZwAgAG8AbgAgAHAAYQBjAGsAZQB0AGIAYgAgADwAbQBzAGcALQBoAGUAYQBkAGUAcgA+ACAAbwBuAGwAeQAgACYAIAAgAE0AQQBOAEUAVABfAEkARAAgAFQATABWAA== x-cr-puzzleid: {F905BFA5-0F3B-4237-BF1B-64F544D37F04} X-OriginalArrivalTime: 14 Nov 2007 07:50:33.0246 (UTC) FILETIME=[08F633E0:01C82693] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [manet] Forwarding on packetbb only & MANET_ID TLV X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi, After private discussions and reading I-Ds over and over again, I still do not agree on PacketBB text on forwarding, based on message-header only: <...start...> o A message header format, which may allow a node to make praocessing and forwarding decisions based on the node's present state and the message header, without inspecting and parsing the message body. Message header information permits single- and multi-hop message diffusion. <...> Separation of forwarding and processing - duplicate detection and controlled scope message forwarding decisions can be made using information contained in the message header, without processing the message body. <...> Message - the fundamental entity carrying protocol information, in the form of addresses and TLVs. Messages are transmitted in packets, and may be forwarded based on their header information. <...> o Messages are designed to be carriers of protocol information and MAY, at each hop, be forwarded and/or processed according to the information in the message header by the protocol using this specification. <...end...> A MANET Router MAY NOT forward messages that contain TLV that are not understood, e.g. are defined for routing protocols that are not active on this MANET Router. Or contain TLV that are well understood but limit forwarding. Let's use MANET_ID as example (draft-chakeres-manet-manetid-00.txt). I think it is unacceptable that information form region X leaks into region Y, Z, AA, .... ZZZZZ. Maybe it is not processed and not that harmful, but it is a waste of bandwidth. I can imagine much more evil examples, I used MANET_ID as I like this idea. Bytheway, can we discuss Ian's MANET_ID I-D in Vancouver? Agenda: <...> ?. Individual Submissions <...> * MANET Region ID TLV (Ian Chakeres, 5 min) - NEW http://www.ietf.org/internet-drafts/draft-chakeres-manet-manetid-00.txt <...> Cheers, Teco _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 14 04:34:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEdm-0004j2-QS; Wed, 14 Nov 2007 04:34:34 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsEdl-0004hq-Bd for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 04:34:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsEdk-0004gr-Uy for manet@ietf.org; Wed, 14 Nov 2007 04:34:33 -0500 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsEdi-0001vf-5A for manet@ietf.org; Wed, 14 Nov 2007 04:34:30 -0500 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lAE9YOrB026095 for ; Wed, 14 Nov 2007 09:34:24 GMT 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 lAE9YOq0020302 for ; Wed, 14 Nov 2007 09:34:24 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 14 Nov 2007 09:34:23 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 14 Nov 2007 09:34:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Forwarding on packetbb only & MANET_ID TLV Date: Wed, 14 Nov 2007 09:34:22 -0000 Message-ID: In-Reply-To: <005d01c82693$03655640$0a3002c0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Forwarding on packetbb only & MANET_ID TLV Thread-Index: Acgmkv9sX7wsygmoQD6LuqeCJfaYUAADg44g References: <005d01c82693$03655640$0a3002c0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "manet" X-OriginalArrivalTime: 14 Nov 2007 09:34:23.0477 (UTC) FILETIME=[8A780250:01C826A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The paragraph that Teco quotes says that this _may_ allow a node to make such a decision. That's all. How processing and forwarding happens is up to a protocol using packetbb - look for example at OLSRv2 and DYMO that have quite different forwarding behaviour. The packetbb statement is true, but it doesn't mandate that behaviour. These comments are based on a false premiss. =20 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 14 November 2007 07:50 To: 'manet' Subject: [manet] Forwarding on packetbb only & MANET_ID TLV *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Hi, After private discussions and reading I-Ds over and over again, I still do not agree on PacketBB text on forwarding, based on message-header only: <...start...> o A message header format, which may allow a node to make praocessing and forwarding decisions based on the node's present state and the message header, without inspecting and parsing the message body. Message header information permits single- and multi-hop message diffusion. <...> Separation of forwarding and processing - duplicate detection and controlled scope message forwarding decisions can be made using information contained in the message header, without processing the message body. <...> Message - the fundamental entity carrying protocol information, in the form of addresses and TLVs. Messages are transmitted in packets, and may be forwarded based on their header information. <...> o Messages are designed to be carriers of protocol information and MAY, at each hop, be forwarded and/or processed according to the information in the message header by the protocol using this specification. <...end...> A MANET Router MAY NOT forward messages that contain TLV that are not understood, e.g. are defined for routing protocols that are not active on this MANET Router. Or contain TLV that are well understood but limit forwarding. Let's use MANET_ID as example (draft-chakeres-manet-manetid-00.txt). I think it is unacceptable that information form region X leaks into region Y, Z, AA, .... ZZZZZ. Maybe it is not processed and not that harmful, but it is a waste of bandwidth. I can imagine much more evil examples, I used MANET_ID as I like this idea. Bytheway, can we discuss Ian's MANET_ID I-D in Vancouver? Agenda: <...> ?. Individual Submissions <...> * MANET Region ID TLV (Ian Chakeres, 5 min) - NEW =20 http://www.ietf.org/internet-drafts/draft-chakeres-manet-manetid-00.txt <...> Cheers, Teco _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 14 05:26:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFRS-0002qx-Gv; Wed, 14 Nov 2007 05:25:54 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsFRQ-0002oi-Vj for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 05:25:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFRQ-0002oV-JO for manet@ietf.org; Wed, 14 Nov 2007 05:25:52 -0500 Received: from hpsmtp-eml13.kpnxchange.com ([213.75.38.113]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsFRM-0004Iv-L8 for manet@ietf.org; Wed, 14 Nov 2007 05:25:52 -0500 Received: from hpsmtp-eml02.kpnxchange.com ([213.75.38.102]) by hpsmtp-eml13.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 11:25:47 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml02.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 11:25:47 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'manet'" References: <005d01c82693$03655640$0a3002c0$@nl> In-Reply-To: Subject: RE: [manet] Forwarding on packetbb only & MANET_ID TLV Date: Wed, 14 Nov 2007 11:25:37 +0100 Message-ID: <007901c826a8$b2d95d50$188c17f0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgmkv9sX7wsygmoQD6LuqeCJfaYUAADg44gAAGDqJA= Content-Language: nl X-OriginalArrivalTime: 14 Nov 2007 10:25:47.0330 (UTC) FILETIME=[B896A220:01C826A8] X-Spam-Score: -1.0 (-) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org What about the opposite of quoted text? <...start...> o A message header format, which may not allow a node to make processing and forwarding decisions based on the node's present state and the message header, without inspecting and parsing the message body. Message header information only does not permit single- and multi-hop message diffusion. <...> Separation of forwarding and processing - duplicate detection and controlled scope message forwarding decisions cannot be made using information contained in the message header only, without processing the message body. <...> Message - the fundamental entity carrying protocol information, in the form of addresses and TLVs. Messages are transmitted in packets, and may not be forwarded based on their header information. <...> o Messages are designed to be carriers of protocol information and MAY NOT, at each hop, be forwarded and/or processed according to the information in the message header only by the protocol using this specification. <...end...> May or may not, If we don't know what is meant, it is a bad standard. If someone writes a new protocol, (s)he could check older protocols and try to reduce evil side effects. This is not possible for the opposite. I think this is a significant issue and I do not agree on current PacketBB text. Teco. > -----Oorspronkelijk bericht----- > Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Verzonden: woensdag 14 november 2007 10:34 > Aan: Teco Boot; manet > Onderwerp: RE: [manet] Forwarding on packetbb only & > MANET_ID TLV > > > The paragraph that Teco quotes says that this _may_ > allow a node to make such a decision. That's all. > How processing and forwarding happens is up to a > protocol using packetbb - look for example at OLSRv2 > and DYMO that have quite different forwarding behaviour. > The packetbb statement is true, but it doesn't mandate > that behaviour. These comments are based on a false > premiss. > > > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: 14 November 2007 07:50 > To: 'manet' > Subject: [manet] Forwarding on packetbb only & MANET_ID > TLV > > > *** 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. > > Hi, > > After private discussions and reading I-Ds over and over again, I still > do > not agree on PacketBB text on forwarding, based on message-header only: > <...start...> > o A message header format, which may allow a node to make > praocessing and forwarding decisions based on the node's present > state and the message header, without inspecting and parsing the > message body. Message header information permits single- and > multi-hop message diffusion. > <...> > Separation of forwarding and processing - duplicate detection and > controlled scope message forwarding decisions can be made using > information contained in the message header, without processing > the message body. > <...> > Message - the fundamental entity carrying protocol information, in > the form of addresses and TLVs. Messages are transmitted in > packets, and may be forwarded based on their header information. > <...> > o Messages are designed to be carriers of protocol information and > MAY, at each hop, be forwarded and/or processed according to the > information in the message header by the protocol using this > specification. > <...end...> > A MANET Router MAY NOT forward messages that contain TLV that are not > understood, e.g. are defined for routing protocols that are not active > on > this MANET Router. Or contain TLV that are well understood but limit > forwarding. > > Let's use MANET_ID as example (draft-chakeres-manet-manetid-00.txt). I > think > it is unacceptable that information form region X leaks into region Y, > Z, > AA, .... ZZZZZ. Maybe it is not processed and not that harmful, but it > is a > waste of bandwidth. I can imagine much more evil examples, I used > MANET_ID > as I like this idea. > > Bytheway, can we discuss Ian's MANET_ID I-D in Vancouver? Agenda: > <...> > ?. Individual Submissions > <...> > > * MANET Region ID TLV (Ian Chakeres, 5 min) - NEW > > http://www.ietf.org/internet-drafts/draft-chakeres-manet-manetid-00.txt > > <...> > > Cheers, Teco > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 14 05:31:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFWP-0000vm-4p; Wed, 14 Nov 2007 05:31:01 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsFWN-0000sp-CV for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 05:30:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsFWM-0000rr-Tc for manet@ietf.org; Wed, 14 Nov 2007 05:30:58 -0500 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsFWF-0004Pv-7E for manet@ietf.org; Wed, 14 Nov 2007 05:30:58 -0500 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 lAEAUmca028493 for ; Wed, 14 Nov 2007 10:30:48 GMT 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 lAEAUmns007900 for ; Wed, 14 Nov 2007 10:30:48 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 14 Nov 2007 10:30:47 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 14 Nov 2007 10:30:47 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Forwarding on packetbb only & MANET_ID TLV Date: Wed, 14 Nov 2007 10:30:46 -0000 Message-ID: In-Reply-To: <007901c826a8$b2d95d50$188c17f0$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Forwarding on packetbb only & MANET_ID TLV Thread-Index: Acgmkv9sX7wsygmoQD6LuqeCJfaYUAADg44gAAGDqJAAAHDGoA== References: <005d01c82693$03655640$0a3002c0$@nl> <007901c826a8$b2d95d50$188c17f0$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "manet" X-OriginalArrivalTime: 14 Nov 2007 10:30:47.0424 (UTC) FILETIME=[6B755800:01C826A9] X-Spam-Score: -4.0 (----) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I really don't understand what Teco is trying to say here. I am suggesting to my co-authors making it a little more explicit (although it should be clear) that processing and forwarding are done by a protocol, packetbb provides the tools which those protocols can use, with comments on how. -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 14 November 2007 10:26 To: Dearlove, Christopher (UK); 'manet' Subject: RE: [manet] Forwarding on packetbb only & MANET_ID TLV What about the opposite of quoted text? <...start...> o A message header format, which may not allow a node to make processing and forwarding decisions based on the node's present state and the message header, without inspecting and parsing the message body. Message header information only does not permit single- and multi-hop message diffusion. <...> Separation of forwarding and processing - duplicate detection and controlled scope message forwarding decisions cannot be made using information contained in the message header only, without processing the message body. <...> Message - the fundamental entity carrying protocol information, in the form of addresses and TLVs. Messages are transmitted in packets, and may not be forwarded based on their header information. <...> o Messages are designed to be carriers of protocol information and MAY NOT, at each hop, be forwarded and/or processed according to the information in the message header only by the protocol using this specification. <...end...> May or may not, If we don't know what is meant, it is a bad standard. If someone writes a new protocol, (s)he could check older protocols and try to reduce evil side effects. This is not possible for the opposite. I think this is a significant issue and I do not agree on current PacketBB text. Teco. > -----Oorspronkelijk bericht----- > Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Verzonden: woensdag 14 november 2007 10:34 > Aan: Teco Boot; manet > Onderwerp: RE: [manet] Forwarding on packetbb only & > MANET_ID TLV >=20 >=20 > The paragraph that Teco quotes says that this _may_ > allow a node to make such a decision. That's all. > How processing and forwarding happens is up to a > protocol using packetbb - look for example at OLSRv2 > and DYMO that have quite different forwarding behaviour. > The packetbb statement is true, but it doesn't mandate > that behaviour. These comments are based on a false > premiss. >=20 >=20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: 14 November 2007 07:50 > To: 'manet' > Subject: [manet] Forwarding on packetbb only & MANET_ID > TLV >=20 >=20 > *** WARNING *** >=20 > 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. >=20 > Hi, >=20 > After private discussions and reading I-Ds over and over again, I still > do > not agree on PacketBB text on forwarding, based on message-header only: > <...start...> > o A message header format, which may allow a node to make > praocessing and forwarding decisions based on the node's present > state and the message header, without inspecting and parsing the > message body. Message header information permits single- and > multi-hop message diffusion. > <...> > Separation of forwarding and processing - duplicate detection and > controlled scope message forwarding decisions can be made using > information contained in the message header, without processing > the message body. > <...> > Message - the fundamental entity carrying protocol information, in > the form of addresses and TLVs. Messages are transmitted in > packets, and may be forwarded based on their header information. > <...> > o Messages are designed to be carriers of protocol information and > MAY, at each hop, be forwarded and/or processed according to the > information in the message header by the protocol using this > specification. > <...end...> > A MANET Router MAY NOT forward messages that contain TLV that are not > understood, e.g. are defined for routing protocols that are not active > on > this MANET Router. Or contain TLV that are well understood but limit > forwarding. >=20 > Let's use MANET_ID as example (draft-chakeres-manet-manetid-00.txt). I > think > it is unacceptable that information form region X leaks into region Y, > Z, > AA, .... ZZZZZ. Maybe it is not processed and not that harmful, but it > is a > waste of bandwidth. I can imagine much more evil examples, I used > MANET_ID > as I like this idea. >=20 > Bytheway, can we discuss Ian's MANET_ID I-D in Vancouver? Agenda: > <...> > ?. Individual Submissions > <...> > > * MANET Region ID TLV (Ian Chakeres, 5 min) - NEW >=20 > http://www.ietf.org/internet-drafts/draft-chakeres-manet-manetid-00.txt > > <...> >=20 > Cheers, Teco >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 >=20 > ******************************************************************** > 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 14 06:24:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGLp-0001qH-Pj; Wed, 14 Nov 2007 06:24:09 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsGLm-0001jw-6l for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 06:24:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsGLl-0001ht-Gi for manet@ietf.org; Wed, 14 Nov 2007 06:24:05 -0500 Received: from hpsmtp-eml19.kpnxchange.com ([213.75.38.84]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsGLk-0005as-4u for manet@ietf.org; Wed, 14 Nov 2007 06:24:04 -0500 Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 12:24:02 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 12:24:01 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'manet'" References: <005d01c82693$03655640$0a3002c0$@nl> <007901c826a8$b2d95d50$188c17f0$@nl> In-Reply-To: Subject: RE: [manet] Forwarding on packetbb only & MANET_ID TLV Date: Wed, 14 Nov 2007 12:23:52 +0100 Message-ID: <007b01c826b0$d5bcd100$81367300$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgmkv9sX7wsygmoQD6LuqeCJfaYUAADg44gAAGDqJAAAHDGoAABaODQ Content-Language: nl X-OriginalArrivalTime: 14 Nov 2007 11:24:01.0995 (UTC) FILETIME=[DB9231B0:01C826B0] X-Spam-Score: 0.0 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org We agree on that processing and forwarding is done by a protocol. However, this is not specified. We agree on that packetbb provides tools for forwarding decisions. I think it is required to mandate that a protocol MAY NOT forward other protocol information or forward information that MAY NOT be forwarded, e.g. indicated by TLV within messages. That's why I suggest changing the text. And I don't agree on that message header only inspection is enough. and helps, but more inspection is needed and MUST be mandated. And rules for are not defined in packetbb at all. Nor a reference. For a single protocol MANET, there is no problem. I think in real world, problems will occur. Let's something, preventing those problems. Teco. > -----Oorspronkelijk bericht----- > Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Verzonden: woensdag 14 november 2007 11:31 > Aan: Teco Boot; manet > Onderwerp: RE: [manet] Forwarding on packetbb only & > MANET_ID TLV > > I really don't understand what Teco is trying to say > here. I am suggesting to my co-authors making it a > little more explicit (although it should be clear) > that processing and forwarding are done by a protocol, > packetbb provides the tools which those protocols > can use, with comments on how. > > > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: 14 November 2007 10:26 > To: Dearlove, Christopher (UK); 'manet' > Subject: RE: [manet] Forwarding on packetbb only & > MANET_ID > TLV > > What about the opposite of quoted text? > <...start...> > o A message header format, which may not allow a node to make > processing and forwarding decisions based on the node's present > state and the message header, without inspecting and parsing the > message body. Message header information only does not permit > single- > and > multi-hop message diffusion. > <...> > Separation of forwarding and processing - duplicate detection and > controlled scope message forwarding decisions cannot be made > using > information contained in the message header only, without > processing > the message body. > <...> > Message - the fundamental entity carrying protocol information, in > the form of addresses and TLVs. Messages are transmitted in > packets, and may not be forwarded based on their header > information. > <...> > o Messages are designed to be carriers of protocol information and > MAY NOT, at each hop, be forwarded and/or processed according to > the > information in the message header only by the protocol using this > specification. > <...end...> > May or may not, If we don't know what is meant, it is a bad standard. > If someone writes a new protocol, (s)he could check older protocols and > try > to reduce evil side effects. This is not possible for the opposite. > I think this is a significant issue and I do not agree on current > PacketBB > text. > Teco. > > > -----Oorspronkelijk bericht----- > > Van: Dearlove, Christopher (UK) > [mailto:Chris.Dearlove@baesystems.com] > > Verzonden: woensdag 14 november 2007 10:34 > > Aan: Teco Boot; manet > > Onderwerp: RE: [manet] Forwarding on packetbb only & > > MANET_ID TLV > > > > > > The paragraph that Teco quotes says that this _may_ > > allow a node to make such a decision. That's all. > > How processing and forwarding happens is up to a > > protocol using packetbb - look for example at OLSRv2 > > and DYMO that have quite different forwarding behaviour. > > The packetbb statement is true, but it doesn't mandate > > that behaviour. These comments are based on a false > > premiss. > > > > > > -----Original Message----- > > From: Teco Boot [mailto:teco@inf-net.nl] > > Sent: 14 November 2007 07:50 > > To: 'manet' > > Subject: [manet] Forwarding on packetbb only & MANET_ID > > TLV > > > > > > *** 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. > > > > Hi, > > > > After private discussions and reading I-Ds over and over again, I > still > > do > > not agree on PacketBB text on forwarding, based on message-header > only: > > <...start...> > > o A message header format, which may allow a node to make > > praocessing and forwarding decisions based on the node's > present > > state and the message header, without inspecting and parsing > the > > message body. Message header information permits single- and > > multi-hop message diffusion. > > <...> > > Separation of forwarding and processing - duplicate detection and > > controlled scope message forwarding decisions can be made using > > information contained in the message header, without processing > > the message body. > > <...> > > Message - the fundamental entity carrying protocol information, > in > > the form of addresses and TLVs. Messages are transmitted in > > packets, and may be forwarded based on their header > information. > > <...> > > o Messages are designed to be carriers of protocol information > and > > MAY, at each hop, be forwarded and/or processed according to > the > > information in the message header by the protocol using this > > specification. > > <...end...> > > A MANET Router MAY NOT forward messages that contain TLV that are not > > understood, e.g. are defined for routing protocols that are not > active > > on > > this MANET Router. Or contain TLV that are well understood but limit > > forwarding. > > > > Let's use MANET_ID as example (draft-chakeres-manet-manetid-00.txt). > I > > think > > it is unacceptable that information form region X leaks into region > Y, > > Z, > > AA, .... ZZZZZ. Maybe it is not processed and not that harmful, but > it > > is a > > waste of bandwidth. I can imagine much more evil examples, I used > > MANET_ID > > as I like this idea. > > > > Bytheway, can we discuss Ian's MANET_ID I-D in Vancouver? Agenda: > > <...> > > ?. Individual Submissions > > <...> > > > > * MANET Region ID TLV (Ian Chakeres, 5 min) - NEW > > > > > http://www.ietf.org/internet-drafts/draft-chakeres-manet-manetid-00.txt > > > > <...> > > > > Cheers, Teco > > > > > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > > ******************************************************************** > > 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 14 07:31:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsHOl-0006rE-Te; Wed, 14 Nov 2007 07:31:15 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsHOk-0006nW-32 for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 07:31:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsHOj-0006li-J8 for manet@ietf.org; Wed, 14 Nov 2007 07:31:13 -0500 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsHOf-0008HH-09 for manet@ietf.org; Wed, 14 Nov 2007 07:31:13 -0500 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 lAECV6Cm025487 for ; Wed, 14 Nov 2007 12:31:06 GMT 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 lAECV6UC005397 for ; Wed, 14 Nov 2007 12:31:06 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 14 Nov 2007 12:31:05 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 14 Nov 2007 12:31:05 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Forwarding on packetbb only & MANET_ID TLV Date: Wed, 14 Nov 2007 12:31:04 -0000 Message-ID: In-Reply-To: <007b01c826b0$d5bcd100$81367300$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Forwarding on packetbb only & MANET_ID TLV Thread-Index: Acgmkv9sX7wsygmoQD6LuqeCJfaYUAADg44gAAGDqJAAAHDGoAABaODQAAKdZzA= References: <005d01c82693$03655640$0a3002c0$@nl> <007901c826a8$b2d95d50$188c17f0$@nl> <007b01c826b0$d5bcd100$81367300$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "manet" X-OriginalArrivalTime: 14 Nov 2007 12:31:05.0213 (UTC) FILETIME=[39988AD0:01C826BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I think it is required to mandate that a protocol MAY NOT forward other > protocol information or forward information that MAY NOT be forwarded, e.g. > indicated by TLV within messages. That's up to the protocols, it's outside the scope of packetbb. What you say may make sense in some contexts, and may not in others. > And I don't agree on that message header only inspection is enough. packetbb says that only header inspection may be enough. (It's more specific in one place where it points out that header inspection allows duplicate detection and scope delimiting.) > and helps, but more inspection is needed and MUST > be mandated. In a protocol, not in packetbb. > And rules for are not defined in packetbb at > all. And rules should not be defined, only a suggestion (which we may make slightly more specific) is in packetbb. > For a single protocol MANET, there is no problem. I think in real world, > problems will occur. Let's something, preventing those problems. Mandating protocol rules, which may not be appropriate to all protocols, in a document which is about formats, not a protocol is creating, not preventing, problems. Protocols (the ones we have, not abstract ones) need hop limit and/or hop count. So packetbb supplies them. And supplying them packetbb needs to say what they are. But we want the minimum of specification of how to use them. As packetbb says in several places, just in case anyone misses it in one, it's not a protocol. Protocols specify forwarding rules. But some protocols may want an efficient way to check if a message may be forwarded or processed (or, in some cases, a first check) and that's how packetbb is designed. You're trying to turn packetbb into a protocol. It's not. ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 14 09:24:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJ9r-0000Cm-7h; Wed, 14 Nov 2007 09:23:59 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsJ9q-0000BS-7Q for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 09:23:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJ9p-0000BJ-NI for manet@ietf.org; Wed, 14 Nov 2007 09:23:57 -0500 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJ9l-0006am-Rw for manet@ietf.org; Wed, 14 Nov 2007 09:23:57 -0500 Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:23:53 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 15:23:52 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'manet'" References: <005d01c82693$03655640$0a3002c0$@nl> <007901c826a8$b2d95d50$188c17f0$@nl> <007b01c826b0$d5bcd100$81367300$@nl> In-Reply-To: Subject: RE: [manet] Forwarding on packetbb only & MANET_ID TLV Date: Wed, 14 Nov 2007 15:23:42 +0100 Message-ID: <008601c826c9$f56666b0$e0333410$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgmkv9sX7wsygmoQD6LuqeCJfaYUAADg44gAAGDqJAAAHDGoAABaODQAAKdZzAAAcO9wA== Content-Language: nl X-OriginalArrivalTime: 14 Nov 2007 14:23:52.0435 (UTC) FILETIME=[FB2CAC30:01C826C9] X-Spam-Score: -1.0 (-) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > Mandating protocol rules, which may not be appropriate to all > protocols, in a document which is about formats, not a protocol > is creating, not preventing, problems. Agreed. Maybe we both have the same target. My comment is on claims written in packetbb, which are dependent on the protocol and thus should not be included in a document about formats. And the claims are invalid as soon as new protocol extensions are introduced, e.g. MANET_ID. > You're trying to turn packetbb into a protocol. It's not. No, I am not. My comments are on the claims only. I prefer taking them out or adjusting text that some packetbb fields are just helpful for protocols, forwarding messages. I am trying to turn packetbb into a format specification and getting rid of text about forwarding as much as possible. Rules (or guidelines) on are the exception. Here I want forwarding specification. > Protocols (the ones we have, not abstract ones) need hop limit > and/or hop count. On the abstract ones: I am facing day to day problems with protocols we have. Mostly caused by inaccurate specification. Or short-term vision. Adding MANET_ID in OLSRv2 is not that abstract. I am reading the packetbb document with misbehaving protocols in mind. I want to have text be corrected. A clear protocol specification or format specification is very helpful in such circumstances. Suggestions for corrections below. Please process this with ERP (Evil Routing Protocol) in mind. Teco. ==== Page 4: , without inspecting and parsing the message body. >>> This is up to the protocol and not up to the format. >>> can be removed. Page 5: Separation of forwarding and processing - duplicate detection and controlled scope message forwarding decisions can be made using information contained in the message header, without processing the message body. >>> This is up to the protocol and not up to the format. >>> can be removed. Page 6 Message - the fundamental entity carrying protocol information, in the form of addresses and TLVs. Messages are transmitted in packets, and may be forwarded based on their header information. >>> May or may not. This is dependent on the protocol and the content of the message. >>> Suggestion for better specification: Message - the fundamental entity carrying protocol information, in the form of addresses and TLVs. Messages are transmitted in packets, and may be forwarded based on their header information and / or the content of the message. Page 12: is omitted if the mnohoplimit bit is set ('1'), otherwise is an 8 bit field, which contains the maximum number of logical hops that the message should be further transmitted. >>> Suggestion for better specification: is omitted if the mnohoplimit bit is set ('1'), otherwise is an 8 bit field, which contains the maximum number of logical hops that the message should be further transmitted. is decremented by 1 by each node that forwards the message. The message MUST NOT be forwarded if is decremented to zero. Page 25: o Messages are designed to be carriers of protocol information and MAY, at each hop, be forwarded and/or processed according to the information in the message header by the protocol using this specification >>> Suggestion for better specification: o Messages are designed to be carriers of protocol information and MAY, at each hop, be forwarded and/or processed according to the information in the message by the protocol using this specification _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 14 10:09:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJra-0000ww-An; Wed, 14 Nov 2007 10:09:10 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsJrY-0000vc-LI for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:09:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsJrY-0000v2-75 for manet@ietf.org; Wed, 14 Nov 2007 10:09:08 -0500 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsJrV-0002tA-JO for manet@ietf.org; Wed, 14 Nov 2007 10:09:08 -0500 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lAEF8jbL007882 for ; Wed, 14 Nov 2007 15:08:45 GMT 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 lAEF8jMR007684 for ; Wed, 14 Nov 2007 15:08:45 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 14 Nov 2007 15:08:43 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 14 Nov 2007 15:08:43 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Forwarding on packetbb only & MANET_ID TLV Date: Wed, 14 Nov 2007 15:08:42 -0000 Message-ID: In-Reply-To: <008601c826c9$f56666b0$e0333410$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Forwarding on packetbb only & MANET_ID TLV Thread-Index: Acgmkv9sX7wsygmoQD6LuqeCJfaYUAADg44gAAGDqJAAAHDGoAABaODQAAKdZzAAAcO9wAADufMQ References: <005d01c82693$03655640$0a3002c0$@nl><007901c826a8$b2d95d50$188c17f0$@nl><007b01c826b0$d5bcd100$81367300$@nl> <008601c826c9$f56666b0$e0333410$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "manet" X-OriginalArrivalTime: 14 Nov 2007 15:08:43.0490 (UTC) FILETIME=[3F2B1420:01C826D0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I am trying to turn packetbb into a format specification and getting rid of > text about forwarding as much as possible. But no more. And - Protocols need hop limit/count, and othe stuff is used for forwarding/processing decisions (such as duplicate detection). - packetbb needs to supply those fields. And it makes some/many protocols more efficient to have that stuff in a header, while putting other stuff in the message body. - packetbb needs to explain what those fields are and how they may be used, while not mandating that, because otherwise protocols don't know what's there for them. And that's what we have. Give or take the odd minor wording change, suggestions to strip out stuff wholesale are completely at odds with what needs to be in packetbb. Every thing in packetbb that is verging on protocol is something we, the authors, would rather not have if it isn't necessary. But it is necessary, based on the argument summarised above. Suggesting minor wording changes may be useful. Suggesting stripping out every reference to forwarding and processing isn't, they are there for a reason, and are necessary for packetbb to do its job. ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 14 10:21:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsK3d-0006ha-MR; Wed, 14 Nov 2007 10:21:37 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsK3c-0006ff-A8 for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 10:21:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsK3c-0006fI-01 for manet@ietf.org; Wed, 14 Nov 2007 10:21:36 -0500 Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsK3X-0004K2-6S for manet@ietf.org; Wed, 14 Nov 2007 10:21:35 -0500 Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.8+Sun/8.12.8) with SMTP id lAEFLGwX025568; Wed, 14 Nov 2007 10:21:21 -0500 (EST) Message-Id: <200711141521.lAEFLGwX025568@s2.itd.nrl.navy.mil> Received: (from THEBEBE [132.250.93.60]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.16.48) with SMTP id M2007111410212122362 ; Wed, 14 Nov 2007 10:21:21 -0500 From: "Justin Dean" To: "'Teco Boot'" , "'Dearlove, Christopher \(UK\)'" , "'manet'" Subject: RE: [manet] Forwarding on packetbb only & MANET_ID TLV Date: Wed, 14 Nov 2007 10:26:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: Acgmkv9sX7wsygmoQD6LuqeCJfaYUAADg44gAAGDqJAAAHDGoAABaODQAAKdZzAAAcO9wAADcfAg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <008601c826c9$f56666b0$e0333410$@nl> X-Spam-Score: 1.5 (+) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I think its important to make clear to future protocol designers that protocols can be designed in such a way where only message header information is needed from the message. I see where it seems we were cutting the protocol out of the loop and I agree we should add it back in but I also think that we should keep the message about what is possible as a helpful hit to packetbb implementers/readers. > Page 4: > , without inspecting and parsing the message body. > >>> This is up to the protocol and not up to the format. > >>> can be removed. Processing is also misspelled there... A message header format, which may allow a node to make praocessing and forwarding decisions based on the node's present state and the message header, without inspecting and parsing the message body. A message header format, which may allow a node to make processing and forwarding decisions based on the node's present protocol state and the message header, without inspecting and parsing the message body. Protocols using this specification may require use of the entire message for these decisions. > > Page 5: > Separation of forwarding and processing - duplicate detection and > controlled scope message forwarding decisions can be made using > information contained in the message header, without processing > the message body. > >>> This is up to the protocol and not up to the format. > >>> can be removed. Separation of forwarding and processing - protocols using this specification can be designed such that, duplicate detection and controlled scope message forwarding decisions can be made using information contained in the message header, without processing the message body. > > Page 6 > Message - the fundamental entity carrying protocol information, in > the form of addresses and TLVs. Messages are transmitted in > packets, and may be forwarded based on their header information. > >>> May or may not. This is dependent on the protocol and the > content of > >>> the > message. > >>> Suggestion for better specification: > Message - the fundamental entity carrying protocol information, in > the form of addresses and TLVs. Messages are transmitted in > packets, and may be forwarded based on their header information > and / or the content of the message. Yes I agree with minor change. Message - the fundamental entity carrying protocol information, in the form of addresses and TLVs. Messages are transmitted in packets, and may be forwarded based on protocol state and message header information. Some protocols may require information from the entire message. > > Page 12: > is omitted if the mnohoplimit bit is set ('1'), > otherwise is an 8 bit field, which contains the maximum > number of > logical hops that the message should be further transmitted. > >>> Suggestion for better specification: > is omitted if the mnohoplimit bit is set ('1'), > otherwise is an 8 bit field, which contains the maximum > number of > logical hops that the message should be further transmitted. > is decremented by 1 by each node that > forwards the > message. The message MUST NOT be forwarded if > is > decremented to zero. > I disagree with this as protocols can use this field in a different way, for example logical hops being more than one physical hop. Because protocols are doing all of the forwarding they really get to decide how this field is used as long as it contains the maximum number of logical hops. Leaving a hint or note as to what we think will be the normal mode of operation may be appropriate but enforcing that behavior I do not agree with. > Page 25: > o Messages are designed to be carriers of protocol information and > MAY, at each hop, be forwarded and/or processed according to the > information in the message header by the protocol using this > specification > >>> Suggestion for better specification: > o Messages are designed to be carriers of protocol information and > MAY, at each hop, be forwarded and/or processed according to the > information in the message by the protocol using this > specification > Disagree although I do see your point. We are trying to convey that most of the time protocols should have sufficient information with the message header alone. By stressing this so much we left out pointing out that some of the time it will not be possible. o Messages are designed to be carriers of protocol information and MAY, at each hop, be forwarded and/or processed according to the information in the message header by the protocol using this specification. Some protocols may require information from the message body as well as the message header for forwarding and/or processing decisions. Justin _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 14 11:21:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKzi-0007Gj-PY; Wed, 14 Nov 2007 11:21:38 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsKzg-0007GH-Sp for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 11:21:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKzg-0007G0-Hy for manet@ietf.org; Wed, 14 Nov 2007 11:21:36 -0500 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsKzf-0004ic-I0 for manet@ietf.org; Wed, 14 Nov 2007 11:21:36 -0500 Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 17:21:33 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Nov 2007 17:21:33 +0100 From: "Teco Boot" To: "'Justin Dean'" , "'Dearlove, Christopher \(UK\)'" , "'manet'" References: <008601c826c9$f56666b0$e0333410$@nl> <200711141521.lAEFLGwX025568@s2.itd.nrl.navy.mil> In-Reply-To: <200711141521.lAEFLGwX025568@s2.itd.nrl.navy.mil> Subject: RE: [manet] Forwarding on packetbb only & MANET_ID TLV Date: Wed, 14 Nov 2007 17:21:23 +0100 Message-ID: <009301c826da$65e3c0d0$31ab4270$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgmkv9sX7wsygmoQD6LuqeCJfaYUAADg44gAAGDqJAAAHDGoAABaODQAAKdZzAAAcO9wAADcfAgAAJ519A= Content-Language: nl X-OriginalArrivalTime: 14 Nov 2007 16:21:33.0776 (UTC) FILETIME=[6C0FCD00:01C826DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > I think its important to make clear to future protocol designers that > protocols can be designed in such a way where only message header > information is needed from the message. I see where it seems we were > cutting the protocol out of the loop and I agree we should add it back > in > but I also think that we should keep the message about what is possible > as a > helpful hit to packetbb implementers/readers. ACK > A message header format, which may allow a node to make > processing and forwarding decisions based on the node's present > protocol state and the message header, without inspecting and > parsing the message body. Protocols using this > specification may require use of the entire message for these > decisions. ACK However, accepting something like MANET_ID will force all protocols to use the entire message. > Separation of forwarding and processing - protocols using this > specification can be designed such that, duplicate detection and > controlled scope message forwarding decisions can be made using > information contained in the message header, without processing > the message body. NACK. I still think the claim is false. Just using the word could, and I am fine. It is a bloody minor detail, but I had nightmares for less. --> forwarding decisions could be made > Message - the fundamental entity carrying protocol information, in > the form of addresses and TLVs. Messages are transmitted in > packets, and may be forwarded based on protocol state and > message header information. Some protocols may require information > from the entire message. ACK > > is omitted if the mnohoplimit bit is set ('1'), > > otherwise is an 8 bit field, which contains the maximum > > number of > > logical hops that the message should be further transmitted. > > is decremented by 1 by each node that > > forwards the > > message. The message MUST NOT be forwarded if > > is > > decremented to zero. > > > I disagree with this as protocols can use this field in a different > way, for > example logical hops being more than one physical hop. Because > protocols > are doing all of the forwarding they really get to decide how this > field is > used as long as it contains the maximum number of logical hops. > Leaving a > hint or note as to what we think will be the normal mode of operation > may be > appropriate but enforcing that behavior I do not agree with. Personally I don't like these logical hops at all. I requested to remove this in my review mail. Can we agree in decrement (without "by 1") and discard when zero? Maybe change MUST NOT into SHOULD NOT (although I see not why)? is omitted if the mnohoplimit bit is set ('1'), otherwise is an 8 bit field, which contains the maximum number of logical hops that the message should be further transmitted. is decremented by each node that forwards the message. The message MUST NOT be forwarded if is decremented to zero. If not, please provide a reference to a protocol that needs something else. I am very interested, also because my nightmares! > o Messages are designed to be carriers of protocol information and > MAY, at each hop, be forwarded and/or processed according to the > information in the message header by the protocol using this > specification. Some protocols may require information from the > message body as well as the message header for forwarding and/or > processing decisions. ACK I hope we can close this one and go forward with more important issues. Teco _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 14 11:26:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsL4Q-0003nV-1R; Wed, 14 Nov 2007 11:26:30 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsL4O-0003l6-Hv for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 11:26:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsL4O-0003ky-8F for manet@ietf.org; Wed, 14 Nov 2007 11:26:28 -0500 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsL4K-0003zx-RB for manet@ietf.org; Wed, 14 Nov 2007 11:26:28 -0500 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lAEGQNTE028695 for ; Wed, 14 Nov 2007 16:26:23 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id lAEGQNU6005416 for ; Wed, 14 Nov 2007 16:26:23 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 14 Nov 2007 16:26:23 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Wed, 14 Nov 2007 16:26:23 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Forwarding on packetbb only & MANET_ID TLV Date: Wed, 14 Nov 2007 16:26:22 -0000 Message-ID: In-Reply-To: <009301c826da$65e3c0d0$31ab4270$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Forwarding on packetbb only & MANET_ID TLV Thread-Index: Acgmkv9sX7wsygmoQD6LuqeCJfaYUAADg44gAAGDqJAAAHDGoAABaODQAAKdZzAAAcO9wAADcfAgAAJ519AAALVs4A== References: <008601c826c9$f56666b0$e0333410$@nl> <200711141521.lAEFLGwX025568@s2.itd.nrl.navy.mil> <009301c826da$65e3c0d0$31ab4270$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Justin Dean" , "manet" X-OriginalArrivalTime: 14 Nov 2007 16:26:23.0359 (UTC) FILETIME=[18AAA8F0:01C826DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The next version of packetbb will have some revised text in these areas (and some others). At the moment the current draft still needs one of the authors to sign off on it, so I don't have it to present here. I suggest waiting for that version (which will be out as soon as possible, I hope submitted today, but can't promise). -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 14 November 2007 16:21 To: 'Justin Dean'; Dearlove, Christopher (UK); 'manet' Subject: RE: [manet] Forwarding on packetbb only & MANET_ID TLV *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 > I think its important to make clear to future protocol designers that > protocols can be designed in such a way where only message header > information is needed from the message. I see where it seems we were > cutting the protocol out of the loop and I agree we should add it back > in > but I also think that we should keep the message about what is possible > as a > helpful hit to packetbb implementers/readers. ACK > A message header format, which may allow a node to make > processing and forwarding decisions based on the node's present > protocol state and the message header, without inspecting and > parsing the message body. Protocols using this > specification may require use of the entire message for these > decisions. ACK However, accepting something like MANET_ID will force all protocols to use the entire message. > Separation of forwarding and processing - protocols using this > specification can be designed such that, duplicate detection and > controlled scope message forwarding decisions can be made using > information contained in the message header, without processing > the message body. NACK. I still think the claim is false. Just using the word could, and I am fine. It is a bloody minor detail, but I had nightmares for less. --> forwarding decisions could be made > Message - the fundamental entity carrying protocol information, in > the form of addresses and TLVs. Messages are transmitted in > packets, and may be forwarded based on protocol state and > message header information. Some protocols may require information > from the entire message. ACK > > is omitted if the mnohoplimit bit is set ('1'), > > otherwise is an 8 bit field, which contains the maximum > > number of > > logical hops that the message should be further transmitted. > > is decremented by 1 by each node that > > forwards the > > message. The message MUST NOT be forwarded if > > is > > decremented to zero. > > > I disagree with this as protocols can use this field in a different > way, for > example logical hops being more than one physical hop. Because > protocols > are doing all of the forwarding they really get to decide how this > field is > used as long as it contains the maximum number of logical hops. > Leaving a > hint or note as to what we think will be the normal mode of operation > may be > appropriate but enforcing that behavior I do not agree with. Personally I don't like these logical hops at all. I requested to remove this in my review mail. Can we agree in decrement (without "by 1") and discard when zero? Maybe change MUST NOT into SHOULD NOT (although I see not why)? is omitted if the mnohoplimit bit is set ('1'), otherwise is an 8 bit field, which contains the maximum number of logical hops that the message should be further transmitted. is decremented by each node that forwards the message. The message MUST NOT be forwarded if is=20 decremented to zero. If not, please provide a reference to a protocol that needs something else. I am very interested, also because my nightmares! > o Messages are designed to be carriers of protocol information and > MAY, at each hop, be forwarded and/or processed according to the > information in the message header by the protocol using this > specification. Some protocols may require information from the > message body as well as the message header for forwarding and/or > processing decisions. ACK I hope we can close this one and go forward with more important issues. Teco ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 14 16:46:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQ3U-0003o4-Hv; Wed, 14 Nov 2007 16:45:52 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsQ3S-0003lT-UU for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 16:45:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQ3S-0003kw-K5 for manet@ietf.org; Wed, 14 Nov 2007 16:45:50 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsQ3S-0004Fd-Df for manet@ietf.org; Wed, 14 Nov 2007 16:45:50 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id 366692AC75; Wed, 14 Nov 2007 21:45:20 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IsQ2x-0005Xo-Vy; Wed, 14 Nov 2007 16:45:19 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: T.Clausen@computer.org From: IETF I-D Submission Tool Message-Id: Date: Wed, 14 Nov 2007 16:45:19 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: chris.dearlove@baesystems.com, manet@ietf.org, Cedric.Adjih@inria.fr Subject: [manet] New Version Notification for draft-ietf-manet-packetbb-11 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org A new version of I-D, draft-ietf-manet-packetbb-11.txt has been successfuly submitted by Thomas Clausen and posted to the IETF repository. Filename: draft-ietf-manet-packetbb Revision: 11 Title: Generalized MANET Packet/Message Format Creation_date: 2007-11-14 WG ID: manet Number_of_pages: 61 Abstract: This document specifies a multi-message packet format that may be used by mobile ad hoc network routing and other protocols. The IETF Secretariat. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 14 16:50:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQ81-0001EB-SK; Wed, 14 Nov 2007 16:50:33 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsQ80-0001Cn-NM for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 16:50:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQ80-0001Ca-CQ; Wed, 14 Nov 2007 16:50:32 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsQ80-0004Qh-1W; Wed, 14 Nov 2007 16:50:32 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id F0E8C2AC75; Wed, 14 Nov 2007 21:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IsQ7V-00009n-OL; Wed, 14 Nov 2007 16:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 14 Nov 2007 16:50:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-packetbb-11.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Generalized MANET Packet/Message Format Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-packetbb-11.txt Pages : 61 Date : 2007-11-14 This document specifies a multi-message packet format that may be used by mobile ad hoc network routing and other protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-packetbb-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-packetbb-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-14164517.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-packetbb-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-packetbb-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-14164517.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Wed Nov 14 16:59:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQGw-0003rQ-9U; Wed, 14 Nov 2007 16:59:46 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsQGu-0003nx-EI for manet-confirm+ok@megatron.ietf.org; Wed, 14 Nov 2007 16:59:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsQGu-0003nB-2a for manet@ietf.org; Wed, 14 Nov 2007 16:59:44 -0500 Received: from mho-01-bos.mailhop.org ([63.208.196.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsQGr-00026u-QA for manet@ietf.org; Wed, 14 Nov 2007 16:59:44 -0500 Received: from aste-genev-bois-153-1-81-13.w86-203.abo.wanadoo.fr ([86.203.227.13] helo=[192.168.147.106]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1IsQGq-0002qI-39; Wed, 14 Nov 2007 21:59:40 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.203.227.13 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+5i8hvRPxIq+YFD7EvoBu+ Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Thomas Clausen Date: Wed, 14 Nov 2007 22:59:26 +0100 To: manet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [manet] draft-ietf-manet-packetbb-11 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org All, While we are disappointed that the points we have been making regarding the constraints obviously have been misunderstood, the authors have over the past days conferred to produce an updated version of draft-ietf-manet-packetbb -- which has been submitted. The authors have been listening to the objections raised, and tried hard to come up with a solution that everyone can live with -- and we hope that this will allow the working group to move the I-D forward. Thomas -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 15 05:35:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isc49-0003a3-5m; Thu, 15 Nov 2007 05:35:21 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Isc47-0003Yw-Ti for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 05:35:19 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isc47-0003Yg-Iq for manet@ietf.org; Thu, 15 Nov 2007 05:35:19 -0500 Received: from server9.hosting2go.nl ([83.137.192.232]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Isc46-0004yi-Mm for manet@ietf.org; Thu, 15 Nov 2007 05:35:19 -0500 Received: (qmail 19840 invoked from network); 15 Nov 2007 11:35:16 +0100 Received: from unknown (HELO M90Teco) (217.169.232.211) by server9.hosting2go.nl with SMTP; 15 Nov 2007 11:35:16 +0100 From: "Teco Boot" To: "'Thomas Clausen'" , , "'Dearlove, Christopher \(UK\)'" , References: In-Reply-To: Subject: RE: [manet] draft-ietf-manet-packetbb-11 Date: Thu, 15 Nov 2007 11:34:34 +0100 Message-ID: <000c01c82773$2f7e5570$8e7b0050$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgnCdHpKbhsAgCvTvyEr9jdrdSMHwAZFR0g Content-Language: nl X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Dear authors, Thanks for updating the document. I checked corrections and additions, I think the document is OK now. I agree on moving the I-D forward, as I think this is more important than discussing minor issues. Just for the record: I listed some minor issues below. To be discussed when there is a need for a new version. Cheers, Teco Minor issues, not to be discussed right now: 1) I suggest using term Prefix instead of Network Address (see autoconf-manetarch) 2) I suggest reserving semantics bit 7 as xhassemext (x=p,m,a), and prepare for fields 3) I suggest using bitstrings for address / prefix encoding instead of octets > -----Oorspronkelijk bericht----- > Van: Thomas Clausen [mailto:thomas@thomasclausen.org] > Verzonden: woensdag 14 november 2007 22:59 > Aan: manet > Onderwerp: [manet] draft-ietf-manet-packetbb-11 > > All, > > While we are disappointed that the points we have been making > regarding the constraints obviously have been misunderstood, the > authors have over the past days conferred to produce an updated > version of draft-ietf-manet-packetbb -- which has been submitted. > > The authors have been listening to the objections raised, and tried > hard to come up with a solution that everyone can live with -- and we > hope that this will allow the working group to move the I-D forward. > > Thomas > > -- > Thomas Clausen > Thomas@thomasclausen.org > http://www.thomasclausen.org/ > http://hipercom.thomasclausen.org/ > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 15 05:43:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IscC1-0008Nn-6d; Thu, 15 Nov 2007 05:43:29 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IscBz-0008KA-Kx for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 05:43:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IscBz-0008Jy-8r for manet@ietf.org; Thu, 15 Nov 2007 05:43:27 -0500 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IscBy-0005C4-DO for manet@ietf.org; Thu, 15 Nov 2007 05:43:27 -0500 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lAFAhPIu026393 for ; Thu, 15 Nov 2007 10:43:25 GMT 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 lAFAhPOC020029 for ; Thu, 15 Nov 2007 10:43:25 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 15 Nov 2007 10:43:24 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Thu, 15 Nov 2007 10:43:24 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] draft-ietf-manet-packetbb-11 Date: Thu, 15 Nov 2007 10:43:23 -0000 Message-ID: In-Reply-To: <000c01c82773$2f7e5570$8e7b0050$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] draft-ietf-manet-packetbb-11 Thread-Index: AcgnCdHpKbhsAgCvTvyEr9jdrdSMHwAZFR0gAAFP+uA= References: <000c01c82773$2f7e5570$8e7b0050$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Thomas Clausen" , , X-OriginalArrivalTime: 15 Nov 2007 10:43:24.0492 (UTC) FILETIME=[591E80C0:01C82774] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: manet X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I note your not discuss right now, but note that IPv6 prefix lengths need 7 or 8 bits (depending on the need to encode 0 and 128) and hence there is no real saving. (And irregular bit fields are very messy.) As for semantics bit 7, there's no point in reserving it with a function. If it has a function, we do it. If not it's simply reserved for whatever we do want. I'm also very wary about using up the last semantics bit, as it makes future extensions less compatible. (If you want multiple new semantics bit - and they keep growing - you can do it by making bit 7 an "extended semantics octet bit" giving you a backwardly compatible extension. It's an option worth keeping open.) Incidentally did you check the acknowledgements section? -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 15 November 2007 10:35 To: 'Thomas Clausen'; jdean@itd.nrl.navy.mil; Dearlove, Christopher (UK); Cedric.Adjih@inria.fr Cc: 'manet' Subject: RE: [manet] draft-ietf-manet-packetbb-11 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Dear authors, Thanks for updating the document. I checked corrections and additions, I think the document is OK now. I agree on moving the I-D forward, as I think this is more important than discussing minor issues. Just for the record: I listed some minor issues below. To be discussed when there is a need for a new version. Cheers, Teco Minor issues, not to be discussed right now: 1) I suggest using term Prefix instead of Network Address (see autoconf-manetarch) 2) I suggest reserving semantics bit 7 as xhassemext (x=3Dp,m,a), and prepare for fields 3) I suggest using bitstrings for address / prefix encoding instead of octets > -----Oorspronkelijk bericht----- > Van: Thomas Clausen [mailto:thomas@thomasclausen.org] > Verzonden: woensdag 14 november 2007 22:59 > Aan: manet > Onderwerp: [manet] draft-ietf-manet-packetbb-11 >=20 > All, >=20 > While we are disappointed that the points we have been making > regarding the constraints obviously have been misunderstood, the > authors have over the past days conferred to produce an updated > version of draft-ietf-manet-packetbb -- which has been submitted. >=20 > The authors have been listening to the objections raised, and tried > hard to come up with a solution that everyone can live with -- and we > hope that this will allow the working group to move the I-D forward. >=20 > Thomas >=20 > -- > Thomas Clausen > Thomas@thomasclausen.org > http://www.thomasclausen.org/ > http://hipercom.thomasclausen.org/ >=20 >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 15 06:19:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsclF-0005Br-3E; Thu, 15 Nov 2007 06:19:53 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsclC-00059n-LM for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 06:19:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsclC-000572-5r for manet@ietf.org; Thu, 15 Nov 2007 06:19:50 -0500 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsclA-0007Jx-Ln for manet@ietf.org; Thu, 15 Nov 2007 06:19:50 -0500 Received: by nf-out-0910.google.com with SMTP id d21so399990nfb for ; Thu, 15 Nov 2007 03:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=WbmaqezdW6/zMPqbN2aWtT9Pvca74ycMoX8qic54ITQ=; b=aC/sQJug+WzBVnI0VmoBEXrfU4B4gifu33le/mLNvCShIpT2M7vLx/77DrbBQpYMllcha48K9DBkuj3PgdQN1OMUTnUUY3OYpltyIKwN2nTaCG/YzpnLwiF1ftkw5yvD3l6i0Di1iDZ8C5TCnwe3m2MgLybKALcMLh1N/hFAzLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=HqojSJ6tS7/ZKiE1I7U6Hu4Gesih52LsZOXZ9242LTR7pFwPQQUeKZnJMZf/oMEsuc11PgOzAjn980E+/YuE0zV+WtQ88UKm+UjSJaHZ7ZX2jyucdWPDiuGT4vWvgITzayp320L8gSfv27bHR2/5HKzWEspAky5CPN0HkzDv8EY= Received: by 10.78.173.20 with SMTP id v20mr476781hue.1195125584199; Thu, 15 Nov 2007 03:19:44 -0800 (PST) Received: by 10.78.19.9 with HTTP; Thu, 15 Nov 2007 03:19:44 -0800 (PST) Message-ID: <374005f30711150319n519eb5a6l2046a12c9c43e03@mail.gmail.com> Date: Thu, 15 Nov 2007 16:49:44 +0530 From: "Ian Chakeres" To: manet , "Thomas Clausen" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Ross Callon , Christopher Dearlove Subject: [manet] Re: draft-ietf-manet-packetbb-11 - Updated WGLC - WGLC Nov 18AOE X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Thomas, Chris, & Justin, thank you very much for your maintained efforts to educate everyone about the advantages of having the constraints in place. I'd also like to thank you for developing the new revision that contains functionality that all involved should be able to accept. Everyone, given the relatively few changes in the draft and the fact that it now contains the functionality previously disputed, I would like to extend the WGLC by a few days to capture any last-minute comments. The WGLC for PacketBB will now end on Nov 18th AOE. Please send your feedback on this revision of the draft before Monday, so that we can move this document, and our other documents, forward. http://tools.ietf.org/wg/manet/draft-ietf-manet-packetbb Great job everyone, Ian Chakeres On Nov 15, 2007 3:29 AM, Thomas Clausen wrote: > All, > > While we are disappointed that the points we have been making > regarding the constraints obviously have been misunderstood, the > authors have over the past days conferred to produce an updated > version of draft-ietf-manet-packetbb -- which has been submitted. > > The authors have been listening to the objections raised, and tried > hard to come up with a solution that everyone can live with -- and we > hope that this will allow the working group to move the I-D forward. > > Thomas > > -- > Thomas Clausen > Thomas@thomasclausen.org > http://www.thomasclausen.org/ > http://hipercom.thomasclausen.org/ > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 15 11:18:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshQT-00017p-Ay; Thu, 15 Nov 2007 11:18:45 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IshQS-00017S-BI for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:18:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshQR-00016Y-IW for manet@ietf.org; Thu, 15 Nov 2007 11:18:43 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IshQL-0002pO-TM for manet@ietf.org; Thu, 15 Nov 2007 11:18:43 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id CB2A426E8C; Thu, 15 Nov 2007 16:18:37 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IshQL-0002f6-Nn; Thu, 15 Nov 2007 11:18:37 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: T.Clausen@computer.org From: IETF I-D Submission Tool Message-Id: Date: Thu, 15 Nov 2007 11:18:37 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: chris.dearlove@baesystems.com, manet@ietf.org Subject: [manet] New Version Notification for draft-ietf-manet-timetlv-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org A new version of I-D, draft-ietf-manet-timetlv-03.txt has been successfuly submitted by Thomas Clausen and posted to the IETF repository. Filename: draft-ietf-manet-timetlv Revision: 03 Title: Representing multi-value time in MANETs Creation_date: 2007-11-15 WG ID: manet Number_of_pages: 18 Abstract: This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. The IETF Secretariat. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 15 11:18:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshQV-00018l-6y; Thu, 15 Nov 2007 11:18:47 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IshQT-00018F-Kd for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:18:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshQT-00017o-6g for manet@ietf.org; Thu, 15 Nov 2007 11:18:45 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IshQN-0002pX-0D for manet@ietf.org; Thu, 15 Nov 2007 11:18:45 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id C3E0226E92; Thu, 15 Nov 2007 16:18:38 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IshQM-0002fD-Mu; Thu, 15 Nov 2007 11:18:38 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: T.Clausen@computer.org From: IETF I-D Submission Tool Message-Id: Date: Thu, 15 Nov 2007 11:18:38 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: chris.dearlove@baesystems.com, manet@ietf.org Subject: [manet] New Version Notification for draft-ietf-manet-timetlv-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org A new version of I-D, draft-ietf-manet-timetlv-03.txt has been successfuly submitted by Thomas Clausen and posted to the IETF repository. Filename: draft-ietf-manet-timetlv Revision: 03 Title: Representing multi-value time in MANETs Creation_date: 2007-11-15 WG ID: manet Number_of_pages: 18 Abstract: This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. The IETF Secretariat. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 15 11:18:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshQT-00017p-Ay; Thu, 15 Nov 2007 11:18:45 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IshQS-00017S-BI for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:18:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshQR-00016Y-IW for manet@ietf.org; Thu, 15 Nov 2007 11:18:43 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IshQL-0002pO-TM for manet@ietf.org; Thu, 15 Nov 2007 11:18:43 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id CB2A426E8C; Thu, 15 Nov 2007 16:18:37 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IshQL-0002f6-Nn; Thu, 15 Nov 2007 11:18:37 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: T.Clausen@computer.org From: IETF I-D Submission Tool Message-Id: Date: Thu, 15 Nov 2007 11:18:37 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: chris.dearlove@baesystems.com, manet@ietf.org Subject: [manet] New Version Notification for draft-ietf-manet-timetlv-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org A new version of I-D, draft-ietf-manet-timetlv-03.txt has been successfuly submitted by Thomas Clausen and posted to the IETF repository. Filename: draft-ietf-manet-timetlv Revision: 03 Title: Representing multi-value time in MANETs Creation_date: 2007-11-15 WG ID: manet Number_of_pages: 18 Abstract: This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. The IETF Secretariat. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 15 11:18:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshQV-00018l-6y; Thu, 15 Nov 2007 11:18:47 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IshQT-00018F-Kd for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:18:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshQT-00017o-6g for manet@ietf.org; Thu, 15 Nov 2007 11:18:45 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IshQN-0002pX-0D for manet@ietf.org; Thu, 15 Nov 2007 11:18:45 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id C3E0226E92; Thu, 15 Nov 2007 16:18:38 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IshQM-0002fD-Mu; Thu, 15 Nov 2007 11:18:38 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: T.Clausen@computer.org From: IETF I-D Submission Tool Message-Id: Date: Thu, 15 Nov 2007 11:18:38 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: chris.dearlove@baesystems.com, manet@ietf.org Subject: [manet] New Version Notification for draft-ietf-manet-timetlv-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org A new version of I-D, draft-ietf-manet-timetlv-03.txt has been successfuly submitted by Thomas Clausen and posted to the IETF repository. Filename: draft-ietf-manet-timetlv Revision: 03 Title: Representing multi-value time in MANETs Creation_date: 2007-11-15 WG ID: manet Number_of_pages: 18 Abstract: This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. The IETF Secretariat. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 15 11:20:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshRm-0001pA-5P; Thu, 15 Nov 2007 11:20:06 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IshRk-0001nE-5D for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:20:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshRj-0001mF-EY; Thu, 15 Nov 2007 11:20:03 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IshRj-0003mz-2E; Thu, 15 Nov 2007 11:20:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id ECE902AC6F; Thu, 15 Nov 2007 16:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IshRi-00058a-5s; Thu, 15 Nov 2007 11:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 15 Nov 2007 11:20:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-timetlv-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Representing multi-value time in MANETs Author(s) : T. Clausen, C. Dearlove Filename : draft-ietf-manet-timetlv-03.txt Pages : 18 Date : 2007-11-15 This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-timetlv-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-timetlv-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-timetlv-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-15111837.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-timetlv-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-timetlv-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-15111837.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Thu Nov 15 11:20:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshRu-00026f-CL; Thu, 15 Nov 2007 11:20:14 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IshRk-0001nI-6t for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:20:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshRj-0001mA-Bw; Thu, 15 Nov 2007 11:20:03 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IshRi-0003mx-VC; Thu, 15 Nov 2007 11:20:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 9ADF7175C9; Thu, 15 Nov 2007 16:20:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IshRi-00058Y-5G; Thu, 15 Nov 2007 11:20:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 15 Nov 2007 11:20:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-timetlv-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Representing multi-value time in MANETs Author(s) : T. Clausen, C. Dearlove Filename : draft-ietf-manet-timetlv-03.txt Pages : 18 Date : 2007-11-15 This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-timetlv-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-timetlv-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-timetlv-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-15111835.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-timetlv-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-timetlv-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-15111835.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Thu Nov 15 11:20:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshRx-0002FC-PA; Thu, 15 Nov 2007 11:20:17 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IshRr-00021p-MD for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:20:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshRr-00021P-8h for manet@ietf.org; Thu, 15 Nov 2007 11:20:11 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IshRr-0003nN-1X for manet@ietf.org; Thu, 15 Nov 2007 11:20:11 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns4.neustar.com (Postfix) with ESMTP id E631F2AC6F; Thu, 15 Nov 2007 16:20:10 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IshRq-0002g3-Ew; Thu, 15 Nov 2007 11:20:10 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: T.Clausen@computer.org From: IETF I-D Submission Tool Message-Id: Date: Thu, 15 Nov 2007 11:20:10 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: chris.dearlove@baesystems.com, manet@ietf.org Subject: [manet] New Version Notification for draft-ietf-manet-timetlv-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org A new version of I-D, draft-ietf-manet-timetlv-03.txt has been successfuly submitted by Thomas Clausen and posted to the IETF repository. Filename: draft-ietf-manet-timetlv Revision: 03 Title: Representing multi-value time in MANETs Creation_date: 2007-11-15 WG ID: manet Number_of_pages: 18 Abstract: This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. The IETF Secretariat. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 15 11:20:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshSR-0003G7-IQ; Thu, 15 Nov 2007 11:20:47 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IshSQ-0003FS-AT for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:20:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshSQ-0003FD-0K for manet@ietf.org; Thu, 15 Nov 2007 11:20:46 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IshSL-00031T-Ks for manet@ietf.org; Thu, 15 Nov 2007 11:20:45 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 994FC328E7; Thu, 15 Nov 2007 16:20:11 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1IshRr-0002gA-HP; Thu, 15 Nov 2007 11:20:11 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: T.Clausen@computer.org From: IETF I-D Submission Tool Message-Id: Date: Thu, 15 Nov 2007 11:20:11 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: chris.dearlove@baesystems.com, manet@ietf.org Subject: [manet] New Version Notification for draft-ietf-manet-timetlv-03 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org A new version of I-D, draft-ietf-manet-timetlv-03.txt has been successfuly submitted by Thomas Clausen and posted to the IETF repository. Filename: draft-ietf-manet-timetlv Revision: 03 Title: Representing multi-value time in MANETs Creation_date: 2007-11-15 WG ID: manet Number_of_pages: 18 Abstract: This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. The IETF Secretariat. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 15 11:30:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishc0-0008Sd-7t; Thu, 15 Nov 2007 11:30:40 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ishbt-0008QA-Le for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:30:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishbt-0008Pj-AM; Thu, 15 Nov 2007 11:30:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ishbs-0004aR-UA; Thu, 15 Nov 2007 11:30:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 90213175C9; Thu, 15 Nov 2007 16:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IshbO-0005Eo-3o; Thu, 15 Nov 2007 11:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 15 Nov 2007 11:30:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-timetlv-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Representing multi-value time in MANETs Author(s) : T. Clausen, C. Dearlove Filename : draft-ietf-manet-timetlv-03.txt Pages : 18 Date : 2007-11-15 This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-timetlv-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-timetlv-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-timetlv-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-15112008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-timetlv-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-timetlv-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-15112008.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Thu Nov 15 11:30:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishc5-0000CO-NE; Thu, 15 Nov 2007 11:30:45 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ishbt-0008QD-NN for manet-confirm+ok@megatron.ietf.org; Thu, 15 Nov 2007 11:30:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ishbt-0008Pl-Bl; Thu, 15 Nov 2007 11:30:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ishbs-0004aS-Ve; Thu, 15 Nov 2007 11:30:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 952CE175D5; Thu, 15 Nov 2007 16:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IshbO-0005Eq-4U; Thu, 15 Nov 2007 11:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 15 Nov 2007 11:30:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-timetlv-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Representing multi-value time in MANETs Author(s) : T. Clausen, C. Dearlove Filename : draft-ietf-manet-timetlv-03.txt Pages : 18 Date : 2007-11-15 This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-timetlv-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-timetlv-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-timetlv-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-15112010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-timetlv-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-timetlv-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-15112010.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Fri Nov 16 02:54:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isw2J-0000zI-Ra; Fri, 16 Nov 2007 02:54:47 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Isw2H-0000vm-RL for manet-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 02:54:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isw2H-0000ve-Hl for manet@ietf.org; Fri, 16 Nov 2007 02:54:45 -0500 Received: from mu-out-0910.google.com ([209.85.134.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isw2E-0000ev-5H for manet@ietf.org; Fri, 16 Nov 2007 02:54:45 -0500 Received: by mu-out-0910.google.com with SMTP id i10so852277mue for ; Thu, 15 Nov 2007 23:54:41 -0800 (PST) Received: by 10.82.140.20 with SMTP id n20mr116244bud.1195199680644; Thu, 15 Nov 2007 23:54:40 -0800 (PST) Received: from ?192.168.1.11? ( [83.202.132.64]) by mx.google.com with ESMTPS id e9sm4804823muf.2007.11.15.23.54.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 15 Nov 2007 23:54:38 -0800 (PST) Message-ID: <473D4CB8.8020708@polytechnique.edu> Date: Fri, 16 Nov 2007 08:54:32 +0100 From: Ulrich Herberg Organization: Ecole Polytechnique User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: manet@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [manet] field(s) X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi, In the newest version of the draft (draft-ietf-manet-packetbb-11.txt) one or more fields have been introduced. I wondered whether the following scenario might happen: One has for example 99 addresses in the with all having the same prefix length (e.g. 128 bits) and one address at the end with another prefix length (e.g. /64 to aggregate all the preceding addresses using CIDR). In the current draft, there would be 100 fields. My idea would be to modify the field in the following way: if the value is greater than 128 (which cannot be the case for a prefix) one could erase the first bit of the field and use this number x for saying: "the next x addresses have the same prefix length". In the example: | 11100011 | 10000000 | 01000000 | where: (in decimal) prefix-length_1 = 227, this cannot be a prefix, so erase first bit = 99 prefix-length_2 = 128, this has to be a prefix. So the next 99 addresses will have the prefix 128 prefix-length_3 = 64, this has to be a prefix. This is the prefix of the last address. This is only an idea of mine, but instead of using 100 fields (and thus bytes) this would only need 3 bytes assuming that the addresses are sorted by their prefix. Even if the addresses are not sorted, one could compact the message from at least three messages with the same prefix on. Maybe one could combine several of these special prefix-length fields consecutively to indicate even more than the 127 possible repetitions of the following prefix. (e.g. by multiplying: 128 * 128 * + 128 * + repetitions of the prefix ). What do you think? Regards Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 16 03:35:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iswfh-0002bx-R3; Fri, 16 Nov 2007 03:35:29 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iswfg-0002bl-EV for manet-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 03:35:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iswfg-0002bb-3n for manet@ietf.org; Fri, 16 Nov 2007 03:35:28 -0500 Received: from hpsmtp-eml17.kpnxchange.com ([213.75.38.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iswff-0006jn-AW for manet@ietf.org; Fri, 16 Nov 2007 03:35:27 -0500 Received: from hpsmtp-eml06.kpnxchange.com ([213.75.38.106]) by hpsmtp-eml17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 09:35:24 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 09:35:24 +0100 From: "Teco Boot" To: , References: In-Reply-To: Subject: RE: [manet] New Version Notification for draft-ietf-manet-timetlv-03 Date: Fri, 16 Nov 2007 09:35:12 +0100 Message-ID: <007601c8282b$9a91f2a0$cfb5d7e0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgno5abka8A+Jb3ThSH0Xg4RGUNEAAfvD9w Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 08:35:24.0492 (UTC) FILETIME=[A1E540C0:01C8282B] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi, here some comment. Typos: =3D=3D=3D=3D=3D=3D Page 7:=20 4. if 0 <=3D a <=3D 7, and 0 lt;=3D b <=3D 31, then the required = time-value ^^^ Page 12: typo: 9.1. Message TLV tyepes ^ =20 Page 13: typo: 9.2. Address Block TLV tyepes ^ =20 Terminology used: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Page 8:=20 If t_n is 255, t_default is not used. So this algorithm saves one octet. = OK for me. But t_default doesn't look default at all. Pick another name?=20 t_other t_larger t_dis255 <=3D this is meant That's all;-) Teco. > -----Oorspronkelijk bericht----- > Van: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Verzonden: donderdag 15 november 2007 17:20 > Aan: T.Clausen@computer.org > CC: chris.dearlove@baesystems.com; manet@ietf.org > Onderwerp: [manet] New Version Notification for draft-ietf-manet- > timetlv-03 >=20 >=20 > A new version of I-D, draft-ietf-manet-timetlv-03.txt has been > successfuly submitted by Thomas Clausen and posted to the IETF > repository. >=20 > Filename: draft-ietf-manet-timetlv > Revision: 03 > Title: Representing multi-value time in MANETs > Creation_date: 2007-11-15 > WG ID: manet > Number_of_pages: 18 >=20 > Abstract: > This document describes a general and flexible TLV (type-length-value > structure) for representing time using the generalized MANET packet/ > message format. It defines two message and two address block TLVs > for representing validity and interval times for MANET routing > protocols. >=20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 16 04:28:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsxUs-0002yc-8E; Fri, 16 Nov 2007 04:28:22 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsxUq-0002t0-7e for manet-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 04:28:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsxUp-0002rJ-T5 for manet@ietf.org; Fri, 16 Nov 2007 04:28:19 -0500 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsxUn-0005dO-51 for manet@ietf.org; Fri, 16 Nov 2007 04:28:19 -0500 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lAG9SA7V023463 for ; Fri, 16 Nov 2007 09:28:10 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id lAG9SA1D028213 for ; Fri, 16 Nov 2007 09:28:10 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 16 Nov 2007 09:28:09 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 16 Nov 2007 09:28:09 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] field(s) Date: Fri, 16 Nov 2007 09:28:08 -0000 Message-ID: In-Reply-To: <473D4CB8.8020708@polytechnique.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] field(s) Thread-Index: AcgoJgtyBkqMF0JVSGaoCfzcoIXNpgADEzTA References: <473D4CB8.8020708@polytechnique.edu> From: "Dearlove, Christopher (UK)" To: "Ulrich Herberg" , X-OriginalArrivalTime: 16 Nov 2007 09:28:09.0490 (UTC) FILETIME=[00619F20:01C82833] X-Spam-Score: -4.0 (----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org It's possible to come up with cases that the new format is less efficient than the old. But in this case the easiest approach is splitting into two address blocks. I think the approach you are suggesting is really going to get very messy in explanation and implementation. Over more usual cases, which I think will be almost all the cases really met, there's actually a small saving (two octets). =20 -----Original Message----- From: Ulrich Herberg [mailto:ulrich.herberg@polytechnique.edu]=20 Sent: 16 November 2007 07:55 To: manet@ietf.org Subject: [manet] field(s) *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Hi, In the newest version of the draft (draft-ietf-manet-packetbb-11.txt) one or more fields have been introduced. I wondered=20 whether the following scenario might happen: One has for example 99 addresses in the with all having the same prefix length (e.g. 128 bits) and one address at the end with another prefix length (e.g. /64 to aggregate all the preceding addresses using CIDR). In the current draft, there would be 100 fields. My idea would be to modify the field in the following way: if the value is greater than 128 (which cannot be the case for a prefix) one could erase the first bit of the field and use this number x for saying: "the next x addresses have the same prefix length". In the example: | 11100011 | 10000000 | 01000000 | where: (in decimal) prefix-length_1 =3D 227, this cannot be a prefix, so erase first bit =3D 99 prefix-length_2 =3D 128, this has to be a prefix. So the next 99 addresses will have the prefix 128 prefix-length_3 =3D 64, this has to be a prefix. This is the prefix of the last address. This is only an idea of mine, but instead of using 100 fields (and thus bytes) this would only need 3 bytes assuming that the addresses are sorted by their prefix. Even if the addresses are not=20 sorted, one could compact the message from at least three messages with the same prefix on.=20 Maybe one could combine several of these special prefix-length fields consecutively to indicate even more than the 127 possible repetitions of the following prefix. (e.g. by multiplying: 128 * 128 * + 128 * + repetitions of the prefix ). What do you think? Regards Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 16 05:16:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsyFo-00075Z-7f; Fri, 16 Nov 2007 05:16:52 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IsyFn-00071p-88 for manet-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 05:16:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsyFm-00070O-T1 for manet@ietf.org; Fri, 16 Nov 2007 05:16:50 -0500 Received: from fk-out-0910.google.com ([209.85.128.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsyFj-0008SE-IA for manet@ietf.org; Fri, 16 Nov 2007 05:16:50 -0500 Received: by fk-out-0910.google.com with SMTP id z23so837369fkz for ; Fri, 16 Nov 2007 02:16:46 -0800 (PST) Received: by 10.82.114.3 with SMTP id m3mr4829807buc.1195208206156; Fri, 16 Nov 2007 02:16:46 -0800 (PST) Received: from ?192.168.1.11? ( [83.202.132.64]) by mx.google.com with ESMTPS id j9sm5047799mue.2007.11.16.02.16.44 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Nov 2007 02:16:45 -0800 (PST) Message-ID: <473D6E0B.7040904@polytechnique.edu> Date: Fri, 16 Nov 2007 11:16:43 +0100 From: Ulrich Herberg Organization: Ecole Polytechnique User-Agent: Thunderbird 2.0.0.6 (X11/20070801) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" Subject: Re: [manet] field(s) References: <473D4CB8.8020708@polytechnique.edu> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Christopher, you are certainly right that this would be more complicated in the specification and in implementations, and could be easily avoided by splitting into several address blocks (e.g. one for each distinct prefix length). But then this would be up to the user (or protocol) that uses packetbb to make the split. The user might not be aware that splitting up addresses might reduce the message size significantly (depending on the addresses used in the address block). In addition, that would also complicate every implementation of a protocol, rather than only one implementation of the message format. Best regards, Ulrich Dearlove, Christopher (UK) wrote: > It's possible to come up with cases that the new format > is less efficient than the old. But in this case the > easiest approach is splitting into two address blocks. > I think the approach you are suggesting is really going > to get very messy in explanation and implementation. > Over more usual cases, which I think will be almost all > the cases really met, there's actually a small saving > (two octets). > > > -----Original Message----- > From: Ulrich Herberg [mailto:ulrich.herberg@polytechnique.edu] > Sent: 16 November 2007 07:55 > To: manet@ietf.org > Subject: [manet] field(s) > > > *** 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. > > Hi, > > In the newest version of the draft (draft-ietf-manet-packetbb-11.txt) > one or more fields have been introduced. I wondered > whether the following scenario might happen: > > One has for example 99 addresses in the with all having > the same prefix length (e.g. 128 bits) and one address at the end with > another prefix length (e.g. /64 to aggregate all the preceding addresses > using CIDR). In the current draft, there would be 100 > fields. My idea would be to modify the field in the > following way: if the value is greater than 128 (which cannot be the > case for a prefix) one could erase the first bit of the field > and use this number x for saying: "the next x addresses > have the same prefix length". In the example: > > > | 11100011 | 10000000 | 01000000 | > > where: (in decimal) > prefix-length_1 = 227, this cannot be a prefix, so erase first bit = 99 > prefix-length_2 = 128, this has to be a prefix. So the next 99 addresses > will have the prefix 128 > prefix-length_3 = 64, this has to be a prefix. This is the prefix of the > last address. > > This is only an idea of mine, but instead of using 100 > fields (and thus bytes) this would only need 3 bytes assuming that the > addresses are sorted by their prefix. Even if the addresses are not > sorted, one could compact the message from at least three messages with > the same prefix on. > > Maybe one could combine several of > these special prefix-length fields consecutively to indicate even more > than the 127 possible repetitions of the following prefix. (e.g. by > multiplying: 128 * 128 * + 128 * + > repetitions of the prefix ). What do > you think? > > Regards > Ulrich > > > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 16 05:43:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isyf5-0002ga-Md; Fri, 16 Nov 2007 05:42:59 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Isyf3-0002ft-SP for manet-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 05:42:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isyf3-0002fl-Ik for manet@ietf.org; Fri, 16 Nov 2007 05:42:57 -0500 Received: from mho-02-bos.mailhop.org ([63.208.196.179]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isyf1-0001UT-3n for manet@ietf.org; Fri, 16 Nov 2007 05:42:57 -0500 Received: from aste-genev-bois-153-1-81-13.w86-203.abo.wanadoo.fr ([86.203.227.13] helo=[192.168.147.106]) by mho-02-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1Isyf0-000Fc6-At; Fri, 16 Nov 2007 10:42:54 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 86.203.227.13 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+5SQg1P1dAjRyZeVjsRClz In-Reply-To: <007601c8282b$9a91f2a0$cfb5d7e0$@nl> References: <007601c8282b$9a91f2a0$cfb5d7e0$@nl> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <011BBB25-B16F-45E2-A48A-BFAE564EE7AC@computer.org> Content-Transfer-Encoding: 7bit From: Thomas Heide Clausen Subject: Re: [manet] New Version Notification for draft-ietf-manet-timetlv-03 Date: Fri, 16 Nov 2007 11:42:38 +0100 To: Teco Boot X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: chris.dearlove@baesystems.com, 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Teco, Thanks for your review. For the typo's, I agree and will update according to those. For t_default, I note that we are OK with the mechanism, but that you prefer a name other than t_default, yes? I am of the opinion that this is a minor point, but I note that the term was chosen in line with the usual dictionary definition of default: "a selection made usually automatically or without active consideration due to lack of a viable alternative" -- which in a sense corresponds to the last bullet point on page 9: o otherwise, i.e. if n == 0 or distance > . Cheers, Thomas On 16Nov , 2007, at 9:35 AM, Teco Boot wrote: > Hi, here some comment. > > Typos: > ====== > Page 7: > 4. if 0 <= a <= 7, and 0 lt;= b <= 31, then the required time-value > ^^^ > > Page 12: typo: 9.1. Message TLV tyepes > ^ > Page 13: typo: 9.2. Address Block TLV tyepes > ^ > > Terminology used: > ================= > Page 8: > If t_n is 255, t_default is not used. So this algorithm saves one > octet. OK for me. > But t_default doesn't look default at all. Pick another name? > t_other > t_larger > t_dis255 <= this is meant > > That's all;-) > > Teco. > > >> -----Oorspronkelijk bericht----- >> Van: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> Verzonden: donderdag 15 november 2007 17:20 >> Aan: T.Clausen@computer.org >> CC: chris.dearlove@baesystems.com; manet@ietf.org >> Onderwerp: [manet] New Version Notification for draft-ietf-manet- >> timetlv-03 >> >> >> A new version of I-D, draft-ietf-manet-timetlv-03.txt has been >> successfuly submitted by Thomas Clausen and posted to the IETF >> repository. >> >> Filename: draft-ietf-manet-timetlv >> Revision: 03 >> Title: Representing multi-value time in MANETs >> Creation_date: 2007-11-15 >> WG ID: manet >> Number_of_pages: 18 >> >> Abstract: >> This document describes a general and flexible TLV (type-length-value >> structure) for representing time using the generalized MANET packet/ >> message format. It defines two message and two address block TLVs >> for representing validity and interval times for MANET routing >> protocols. >> >> >> >> The IETF Secretariat. >> >> >> >> >> _______________________________________________ >> manet mailing list >> manet@ietf.org >> https://www1.ietf.org/mailman/listinfo/manet > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > -- Thomas Clausen Thomas@thomasclausen.org http://www.thomasclausen.org/ http://hipercom.thomasclausen.org/ _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 16 06:28:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IszNH-0002Uo-ES; Fri, 16 Nov 2007 06:28:39 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IszNG-0002Pe-4T for manet-confirm+ok@megatron.ietf.org; Fri, 16 Nov 2007 06:28:38 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IszNF-0002NP-PO for manet@ietf.org; Fri, 16 Nov 2007 06:28:37 -0500 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IszNF-0000lk-0K for manet@ietf.org; Fri, 16 Nov 2007 06:28:37 -0500 Received: from hpsmtp-eml01.kpnxchange.com ([213.75.38.101]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 12:28:35 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml01.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Nov 2007 12:28:35 +0100 From: "Teco Boot" To: "'Thomas Heide Clausen'" References: <007601c8282b$9a91f2a0$cfb5d7e0$@nl> <011BBB25-B16F-45E2-A48A-BFAE564EE7AC@computer.org> In-Reply-To: <011BBB25-B16F-45E2-A48A-BFAE564EE7AC@computer.org> Subject: RE: [manet] New Version Notification for draft-ietf-manet-timetlv-03 Date: Fri, 16 Nov 2007 12:28:22 +0100 Message-ID: <00a601c82843$cbdae7a0$6390b6e0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgoPXTv1OeJDgvrROK+TokwT5dONQAAxbOg Content-Language: nl X-OriginalArrivalTime: 16 Nov 2007 11:28:35.0498 (UTC) FILETIME=[D36AF0A0:01C82843] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: chris.dearlove@baesystems.com, 'manet' X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > For t_default, I note that we are OK with the mechanism, but that you > prefer a name other than t_default, yes? YES > I am of the opinion that this is a minor point, Me too;-) > but I note that the > term was chosen in line with the usual dictionary definition of > default: "a selection made usually automatically or without active > consideration due to lack of a viable alternative" -- which in a > sense corresponds to the last bullet point on page 9: > > o otherwise, i.e. if n == 0 or distance > . I would say when the node distance is larger than , that only in that case is to be used. I do not see a difference with other distances not explicitly listed in the list. There are three cases: 1: distance is smaller than or equal to 2: distance is between and , including only 3: distance is larger than Would you say case 3 is default? It is bloody minor. But I certainly would not use _default_ for it. I would use _default_ for values not listed, used in some other mechanism. E.g. default prefix length is /128, except the prefix length of a specific entry (the 100th), for that one the prefix length is /64. The /128 (or /32 for IPv4) could be hard coded, it does not require any signaling. _default_ may have signaling, e.g. default value in message tlv, and specific values in address tlv. Teco. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Nov 18 04:30:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItgTc-0006rA-Nx; Sun, 18 Nov 2007 04:30:04 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ItgTb-0006r1-0E for manet-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 04:30:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItgTa-0006qt-Mt; Sun, 18 Nov 2007 04:30:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItgTa-0004Zg-BT; Sun, 18 Nov 2007 04:30:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 30C08327BF; Sun, 18 Nov 2007 09:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItgTa-0005fC-2t; Sun, 18 Nov 2007 04:30:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 04:30:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-iana-07.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : IANA Allocations for MANET Protocols Author(s) : I. Chakeres Filename : draft-ietf-manet-iana-07.txt Pages : 7 Date : 2007-11-18 This document enumerates several common IANA allocations for use by MANET protocols. The following well-known numbers are required: a UDP port number, an IP protocol number, and a link-local multicast group address. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-iana-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-iana-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-18042019.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-iana-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-iana-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18042019.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Sun Nov 18 04:50:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itgmz-0003d0-9W; Sun, 18 Nov 2007 04:50:05 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Itgmw-0003cd-MR for manet-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 04:50:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itgmw-0003cT-9F; Sun, 18 Nov 2007 04:50:02 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Itgmv-0000na-Rm; Sun, 18 Nov 2007 04:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id B382B2AC79; Sun, 18 Nov 2007 09:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Itgmv-0005ro-DK; Sun, 18 Nov 2007 04:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 18 Nov 2007 04:50:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-dymo-11.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Dynamic MANET On-demand (DYMO) Routing Author(s) : I. Chakeres, C. Perkins Filename : draft-ietf-manet-dymo-11.txt Pages : 36 Date : 2007-11-18 The Dynamic MANET On-demand (DYMO) routing protocol is intended for use by mobile modes in wireless, multihop networks. It offers adaptation to changing network topology and determines unicast routes between DYMO routers within the network in an on-demand fashion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-dymo-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-dymo-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-18044450.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-dymo-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-dymo-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18044450.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Sun Nov 18 04:55:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItgsR-0003JV-T5; Sun, 18 Nov 2007 04:55:43 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1ItgsP-0003Ip-TH for manet-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 04:55:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItgsO-0003If-Fp for manet@ietf.org; Sun, 18 Nov 2007 04:55:41 -0500 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItgsM-0005fk-44 for manet@ietf.org; Sun, 18 Nov 2007 04:55:40 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1023900nfb for ; Sun, 18 Nov 2007 01:55:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=UwPQcA6x8ckqSR4uC9eVscm4gMsSc/f1ln0vqZ2vELQ=; b=R7+Ve/N5iuY5BC2SltjQJDeNcU89TI7ppjQczEOWcYK56LDDPE+kYR8eWHlSIS7a6gdfzj2ttKn4NWWc/POPkQfS5q5MxPxFszkzMbIo/uCCuKP6Z5tdXOAdPc2W3EzYXi4fvHQSNQ5Q8intR4onwciP+RRTBL54dtdKBGVJpjk= 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=n+L3eNvGR/nI6E4tl+IoxrlUmXUXIEXfGrKpRDG1mIiJrdCeFuuPVlyX2jf89MIc2HV+TSahiXETzxGAxYAZRuA4fk797cKENolSv1R4nsStD3OiZVF+4pNV/srEVPBBSK9V/FLIcw1nv+bDAPYSV2Ts8WOtnlf4fY4ovquOeVw= Received: by 10.78.134.2 with SMTP id h2mr3725279hud.1195379737120; Sun, 18 Nov 2007 01:55:37 -0800 (PST) Received: by 10.78.19.9 with HTTP; Sun, 18 Nov 2007 01:55:37 -0800 (PST) Message-ID: <374005f30711180155h60d58de3mfc2a8feba0479c2d@mail.gmail.com> Date: Sun, 18 Nov 2007 15:25:37 +0530 From: "Ian Chakeres" To: manet@ietf.org Subject: Re: [manet] New Version Notification for draft-ietf-manet-timetlv-03 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: chris.dearlove@baesystems.com, T.Clausen@computer.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I think it would be useful for TimeTLV to specify a method for carrying 'C'. I understand that normally nodes (or implementations) might be configured with 'C' for each TimeTLV type. For cases where C is either unknown or required, I think we should specify a format for carrying it. I see carrying C as most important when C misunderstandings could cause routing to fail. I believe there are several different options for encoding this information. What do you think would be the best way? Ian On Nov 15, 2007 9:48 PM, IETF I-D Submission Tool wrote: > > A new version of I-D, draft-ietf-manet-timetlv-03.txt has been successfuly submitted by Thomas Clausen and posted to the IETF repository. > > Filename: draft-ietf-manet-timetlv > Revision: 03 > Title: Representing multi-value time in MANETs > Creation_date: 2007-11-15 > WG ID: manet > Number_of_pages: 18 > > Abstract: > This document describes a general and flexible TLV (type-length-value > structure) for representing time using the generalized MANET packet/ > message format. It defines two message and two address block TLVs > for representing validity and interval times for MANET routing > protocols. > > > > The IETF Secretariat. > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Nov 18 05:29:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IthOU-0002Wq-Tn; Sun, 18 Nov 2007 05:28:50 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IthOT-0002Wl-5o for manet-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 05:28:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IthOS-0002WE-QO for manet@ietf.org; Sun, 18 Nov 2007 05:28:48 -0500 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IthOR-00023R-Uy for manet@ietf.org; Sun, 18 Nov 2007 05:28:48 -0500 Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Nov 2007 11:28:46 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 18 Nov 2007 11:28:46 +0100 From: "Teco Boot" To: "'Ian Chakeres'" , References: <374005f30711180155h60d58de3mfc2a8feba0479c2d@mail.gmail.com> In-Reply-To: <374005f30711180155h60d58de3mfc2a8feba0479c2d@mail.gmail.com> Subject: RE: [manet] New Version Notification for draft-ietf-manet-timetlv-03 Date: Sun, 18 Nov 2007 11:28:33 +0100 Message-ID: <01c001c829cd$c53be350$4fb3a9f0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgpyYjH26HML9JBSou3x7LnADL9BAAAt9Vw Content-Language: nl X-OriginalArrivalTime: 18 Nov 2007 10:28:46.0571 (UTC) FILETIME=[CD13A3B0:01C829CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: chris.dearlove@baesystems.com, T.Clausen@computer.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I read the NHDP and OLSv2 documents and found out the intention of not specifying C in timetlv. C is really a constant and a protocol defines it for a particular usage. Multiple protocols or different timetlv usages are free to define their own constant. But this constant shall be fixed and there is no need for signaling. Nor configuration. It shall be hard coded. Maybe adding some text to circumvent any misunderstanding, explaining there is no need for signaling? Maybe a protocol has a need for a variable V, replacing the constant C. Then, that protocol shall implement signaling for V. Teco. > -----Oorspronkelijk bericht----- > Van: Ian Chakeres [mailto:ian.chakeres@gmail.com] > Verzonden: zondag 18 november 2007 10:56 > Aan: manet@ietf.org > CC: chris.dearlove@baesystems.com; T.Clausen@computer.org > Onderwerp: Re: [manet] New Version Notification for draft-ietf-manet- > timetlv-03 > > I think it would be useful for TimeTLV to specify a method for > carrying 'C'. I understand that normally nodes (or implementations) > might be configured with 'C' for each TimeTLV type. For cases where C > is either unknown or required, I think we should specify a format for > carrying it. I see carrying C as most important when C > misunderstandings could cause routing to fail. > > I believe there are several different options for encoding this > information. What do you think would be the best way? > > Ian > > On Nov 15, 2007 9:48 PM, IETF I-D Submission Tool > wrote: > > > > A new version of I-D, draft-ietf-manet-timetlv-03.txt has been > successfuly submitted by Thomas Clausen and posted to the IETF > repository. > > > > Filename: draft-ietf-manet-timetlv > > Revision: 03 > > Title: Representing multi-value time in MANETs > > Creation_date: 2007-11-15 > > WG ID: manet > > Number_of_pages: 18 > > > > Abstract: > > This document describes a general and flexible TLV (type-length-value > > structure) for representing time using the generalized MANET packet/ > > message format. It defines two message and two address block TLVs > > for representing validity and interval times for MANET routing > > protocols. > > > > > > > > The IETF Secretariat. > > > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sun Nov 18 14:40:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itq04-0002we-98; Sun, 18 Nov 2007 14:40:12 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Itpzy-0002jd-EP for manet-confirm+ok@megatron.ietf.org; Sun, 18 Nov 2007 14:40:06 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itpzy-0002hM-3V for manet@ietf.org; Sun, 18 Nov 2007 14:40:06 -0500 Received: from web61214.mail.yahoo.com ([209.73.179.63]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Itpzx-0001YY-NW for manet@ietf.org; Sun, 18 Nov 2007 14:40:06 -0500 Received: (qmail 71967 invoked by uid 60001); 18 Nov 2007 19:40:05 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=CFnimxpzPmk65+jZWP3pSTUSnh6xMifXI3MQtzRA9qI5VWLpoqk1EXvAaZJ7F5lHAqX4IYhEzJUPd+MnfB9GOIWxEAQPvm6V1cObwDoRfXbYZ0rDZhx7cuA8GDfM95ay4pQurqX30Ww8Bgar8kUziRUP8FTX5ZAMngdK8eQuBIg=; X-YMail-OSG: mN5ilaEVM1n4LXz73gg4UmbCceLlkeQIn6BjM.fHBlDcu2Jd0TWlcKol3UcMb.EUKkL2SyaOsBoqoEYEQAqVnV9_9mShPORwqwEZC_lY4GRw5Y447JzvkiQJnfpCI4I- Received: from [72.223.2.67] by web61214.mail.yahoo.com via HTTP; Sun, 18 Nov 2007 11:40:04 PST X-Mailer: YahooMailRC/818.27 YahooMailWebService/0.7.157 Date: Sun, 18 Nov 2007 11:40:04 -0800 (PST) From: spicemaster To: manet@ietf.org MIME-Version: 1.0 Message-ID: <922033.71234.qm@web61214.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [manet] OLSR X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1569312589==" Errors-To: manet-bounces@ietf.org --===============1569312589== Content-Type: multipart/alternative; boundary="0-1837761680-1195414804=:71234" --0-1837761680-1195414804=:71234 Content-Type: text/plain; charset=us-ascii Hi I have a question regarding OLSR protocol in MANET. I am trying to compare OLSR protocol with some other protocol routing protocols like MAODV,DSR,etc. to compare performances between adhoc routing protocols. So when I run the source code in ns-2, with AODV it runs fine and it gives the graph from tracegraph even if the node count is increased to 50. But with OLSR as the node count is increased the simulation runs fine but I am not able to open the tracefile in tracegraph. It is giving error message like " converting IP's to nodes" "saving IP's to a text file" "saving it *.ip file". so what I have to do to get the graph from .tr file in this case ? I appreciate your help. Thanks, ben. ____________________________________________________________________________________ Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now. http://mobile.yahoo.com/sports;_ylt=At9_qDKvtAbMuh1G1SQtBI7ntAcJ --0-1837761680-1195414804=:71234 Content-Type: text/html; charset=us-ascii
Hi
 
       I have a question regarding OLSR protocol in MANET. I am trying to
compare OLSR protocol with some other protocol routing protocols like
MAODV,DSR,etc. to compare performances between adhoc routing protocols. So
when  I run the source code in ns-2, with AODV it runs fine and it gives the
graph from tracegraph even if the node count is increased to 50. But with OLSR
as the node count is increased the simulation runs fine but I am not able to
open the tracefile in tracegraph. It is giving error message like " converting
IP's to nodes" "saving IP's to a text file" "saving it *.ip file". so what I
have to do to get the graph from .tr file in this case ?
I appreciate your help.

Thanks,
ben.


Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. --0-1837761680-1195414804=:71234-- --===============1569312589== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1569312589==-- From manet-bounces@ietf.org Mon Nov 19 05:50:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4Ck-0004oh-5w; Mon, 19 Nov 2007 05:50:14 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iu4CZ-0004KR-En for manet-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 05:50:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4CY-0004GX-UV; Mon, 19 Nov 2007 05:50:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu4CY-0000pJ-A5; Mon, 19 Nov 2007 05:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 379F5327BC; Mon, 19 Nov 2007 10:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu4CY-0004dp-4A; Mon, 19 Nov 2007 05:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 05:50:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-jitter-03.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Jitter considerations in Mobile Ad Hoc Networks (MANETs) Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-jitter-03.txt Pages : 18 Date : 2007-11-19 This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of transmission collisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-jitter-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-jitter-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-jitter-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19054147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-jitter-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-jitter-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19054147.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Mon Nov 19 05:50:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4Ck-0004oq-TD; Mon, 19 Nov 2007 05:50:14 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iu4Ca-0004Og-FX for manet-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 05:50:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4CZ-0004Hh-2w; Mon, 19 Nov 2007 05:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu4CY-0000pK-Ee; Mon, 19 Nov 2007 05:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 48DFD327C0; Mon, 19 Nov 2007 10:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu4CY-0004du-5M; Mon, 19 Nov 2007 05:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 05:50:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-timetlv-04.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Representing multi-value time in MANETs Author(s) : T. Clausen, C. Dearlove Filename : draft-ietf-manet-timetlv-04.txt Pages : 18 Date : 2007-11-19 This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-timetlv-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-timetlv-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-timetlv-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19054202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-timetlv-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-timetlv-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19054202.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Mon Nov 19 08:42:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6sn-0004YM-FQ; Mon, 19 Nov 2007 08:41:49 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iu6sl-0004X7-Fx for manet-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 08:41:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6sk-0004W7-R3 for manet@ietf.org; Mon, 19 Nov 2007 08:41:46 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu6sk-00010R-A3 for manet@ietf.org; Mon, 19 Nov 2007 08:41:46 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns1.neustar.com (Postfix) with ESMTP id 39F48327BC; Mon, 19 Nov 2007 13:41:46 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Iu6sk-0004pr-4m; Mon, 19 Nov 2007 08:41:46 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: macker@itd.nrl.navy.mil From: IETF I-D Submission Tool Message-Id: Date: Mon, 19 Nov 2007 08:41:46 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: manet@ietf.org Subject: [manet] New Version Notification for draft-ietf-manet-smf-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org A new version of I-D, draft-ietf-manet-smf-06.txt has been successfuly submitted by Joseph Macker and posted to the IETF repository. Filename: draft-ietf-manet-smf Revision: 06 Title: Simplified Multicast Forwarding for MANET Creation_date: 2007-11-17 WG ID: manet Number_of_pages: 47 Abstract: This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF specifies techniques for multicast duplicate packet detection (DPD) to assist the forwarding process. SMF also specifies DPD maintenance and checking operations consistent with both IPv4 and IPv6. SMF takes advantage of reduced relay sets for efficient MANET multicast forwarding within a mesh topology and the document describes protocol interaction with a number of approaches. Candidate algorithms for selecting reduced relay sets and related discussion is provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. The IETF Secretariat. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 19 08:48:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6yn-0007Sa-AO; Mon, 19 Nov 2007 08:48:01 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iu6yk-0007Qg-Uc for manet-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 08:47:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu6yk-0007QX-Kv for manet@ietf.org; Mon, 19 Nov 2007 08:47:58 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu6yh-0001VR-E6 for manet@ietf.org; Mon, 19 Nov 2007 08:47:58 -0500 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by ns0.neustar.com (Postfix) with ESMTP id 65E84328A2; Mon, 19 Nov 2007 13:47:25 +0000 (GMT) Received: from mirror by ietf.org with local (Exim 4.43) id 1Iu6yD-00057w-Ab; Mon, 19 Nov 2007 08:47:25 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: macker@itd.nrl.navy.mil From: IETF I-D Submission Tool Message-Id: Date: Mon, 19 Nov 2007 08:47:25 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: manet@ietf.org Subject: [manet] New Version Notification for draft-ietf-manet-smf-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org A new version of I-D, draft-ietf-manet-smf-06.txt has been successfuly submitted by Joseph Macker and posted to the IETF repository. Filename: draft-ietf-manet-smf Revision: 06 Title: Simplified Multicast Forwarding for MANET Creation_date: 2007-11-17 WG ID: manet Number_of_pages: 47 Abstract: This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF specifies techniques for multicast duplicate packet detection (DPD) to assist the forwarding process. SMF also specifies DPD maintenance and checking operations consistent with both IPv4 and IPv6. SMF takes advantage of reduced relay sets for efficient MANET multicast forwarding within a mesh topology and the document describes protocol interaction with a number of approaches. Candidate algorithms for selecting reduced relay sets and related discussion is provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. The IETF Secretariat. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 19 08:50:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu71R-00040v-TX; Mon, 19 Nov 2007 08:50:45 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iu71G-0003bf-Qv for manet-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 08:50:34 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu71F-0003Xr-J8; Mon, 19 Nov 2007 08:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu71E-00005s-5H; Mon, 19 Nov 2007 08:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 091A82AC61; Mon, 19 Nov 2007 13:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu70j-0004of-Pe; Mon, 19 Nov 2007 08:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 08:50:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-smf-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Simplified Multicast Forwarding for MANET Author(s) : J. Macker, S. Team Filename : draft-ietf-manet-smf-06.txt Pages : 47 Date : 2007-11-17 This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF specifies techniques for multicast duplicate packet detection (DPD) to assist the forwarding process. SMF also specifies DPD maintenance and checking operations consistent with both IPv4 and IPv6. SMF takes advantage of reduced relay sets for efficient MANET multicast forwarding within a mesh topology and the document describes protocol interaction with a number of approaches. Candidate algorithms for selecting reduced relay sets and related discussion is provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-smf-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-smf-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19084723.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-smf-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-smf-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19084723.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Mon Nov 19 08:51:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu71g-0004eB-Sd; Mon, 19 Nov 2007 08:51:00 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iu71H-0003c0-13 for manet-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 08:50:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu71G-0003ak-Ex; Mon, 19 Nov 2007 08:50:34 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu71D-0001jD-Qa; Mon, 19 Nov 2007 08:50:34 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id C4A2B328B9; Mon, 19 Nov 2007 13:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu70j-0004oT-M4; Mon, 19 Nov 2007 08:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 08:50:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-smf-06.txt X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Simplified Multicast Forwarding for MANET Author(s) : J. Macker, S. Team Filename : draft-ietf-manet-smf-06.txt Pages : 47 Date : 2007-11-17 This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF specifies techniques for multicast duplicate packet detection (DPD) to assist the forwarding process. SMF also specifies DPD maintenance and checking operations consistent with both IPv4 and IPv6. SMF takes advantage of reduced relay sets for efficient MANET multicast forwarding within a mesh topology and the document describes protocol interaction with a number of approaches. Candidate algorithms for selecting reduced relay sets and related discussion is provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-smf-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-smf-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19084143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-smf-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-smf-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19084143.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Mon Nov 19 10:58:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu914-00052d-5d; Mon, 19 Nov 2007 10:58:30 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iu912-00052G-VV for manet-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 10:58:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu912-00051l-Kz for manet@ietf.org; Mon, 19 Nov 2007 10:58:28 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu912-0002OP-D2 for manet@ietf.org; Mon, 19 Nov 2007 10:58:28 -0500 Received: by nz-out-0506.google.com with SMTP id n1so1287923nzf for ; Mon, 19 Nov 2007 07:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; bh=sIZi4Gs7aF7z29M2SjxTCU7ZkZ2odbjGj6L9SNMvOFQ=; b=TIa0Ay+uP1JaR38kKMwUe+/oYnj9NVV8z9iVwAAs0VPGVT0H4h7jOJdz3yH2/fEHxqOn683/XuwMApH0cYlCVPGZCb3xxoLJf8NWveswdNO2rHKkcvncNAJvmi7ovLFhlEliV5b78FUjWfGxMGBQxXMIAvCDnPWsT+Hy7GcsGgs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer; b=M3Sbb9PK79vHotlcOU+IvowoDUij5Wn8LOiExkCXI3zHqSJAxGV6Zi97AovtExs5HuQhBE5qhlrKqI+FYO3aaTh4Ww9Kw2RnR/53WX4E2XQUuc7Tvarp7jIRJx4bIlVg4CwR+gH6qeabp329vMcY7lIPqxjb0oMFIZOvQgdkRFs= Received: by 10.140.125.4 with SMTP id x4mr1754751rvc.1195487907212; Mon, 19 Nov 2007 07:58:27 -0800 (PST) Received: from ?192.168.17.149? ( [122.167.182.23]) by mx.google.com with ESMTPS id c36sm12151984rvf.2007.11.19.07.58.19 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Nov 2007 07:58:26 -0800 (PST) In-Reply-To: <200711091546.lA9FkhQ8023656@s2.itd.nrl.navy.mil> References: <200711091546.lA9FkhQ8023656@s2.itd.nrl.navy.mil> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ian Chakeres Date: Mon, 19 Nov 2007 21:28:31 +0530 To: manet X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Christopher Dearlove , Thomas Heide Clausen Subject: [manet] draft-ietf-manet-timetlv - WGLC X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org This note announces the WG Last Call for comments on draft-ietf-manet-timetlv, "Representing multi-value time in MANETs". The document can be found at: http://www.ietf.org/internet-drafts/draft-ietf-manet-timetlv-04.txt The document is intended to be submitted for publication as a proposed standard document. Please review the document carefully and send your comments to the MANET list and document authors. This last call will end Wed Nov 30th AOE. Thanks, Ian Chakeres _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 20 04:53:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuPnM-0007uk-0A; Tue, 20 Nov 2007 04:53:28 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IuPnK-0007ue-Q7 for manet-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 04:53:27 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuPnK-0007uW-FB for manet@ietf.org; Tue, 20 Nov 2007 04:53:26 -0500 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuPnJ-0004u5-Nu for manet@ietf.org; Tue, 20 Nov 2007 04:53:26 -0500 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lAK9rH7v029495 for ; Tue, 20 Nov 2007 09:53:17 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id lAK9rGlR025721 for ; Tue, 20 Nov 2007 09:53:16 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 20 Nov 2007 09:53:15 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 20 Nov 2007 09:53:15 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] New Version Notification for draft-ietf-manet-timetlv-03 Date: Tue, 20 Nov 2007 09:53:14 -0000 Message-ID: In-Reply-To: <374005f30711180155h60d58de3mfc2a8feba0479c2d@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New Version Notification for draft-ietf-manet-timetlv-03 Thread-Index: AcgpyS1QQt/CY1w9RruZtuLu1Luc5wBkHL1Q References: <374005f30711180155h60d58de3mfc2a8feba0479c2d@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Ian Chakeres" , X-OriginalArrivalTime: 20 Nov 2007 09:53:15.0703 (UTC) FILETIME=[2BCE7C70:01C82B5B] X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: T.Clausen@computer.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I'm in agreement that this is neither intended nor desirable. Actually I don't think it's ever desirable, but especially not in timetlv. Why never desirable? First it isn't usually necessary. If C =3D 1 ms you can have times up to 1.5 months at millisecond resolution. If C =3D 1 second you can have times up to over a century, at second resolution. (Other figures are of course possible.) Second the point of timetlv is passing an unambiguous time, often in circumstances where communications has not yet been established. If you had to negotiate C for routing (which is after all why we are here) you'd have to do that before any other form of topology formation etc. that used C. This would be really bad. So for our main use cases, negotiating C really doesn't work. Yes, I can conceive of a protocol that want to negotiate C (that doesn't however mean I think it's likely - I think it's very unlikely given my first point). If so that protocol can define such a process. It's way outside what timetlv should include, especially given that it's an obscure case. (And as we have no prior art, defining a good mechanism would be tricky.) Realised there's one more point. If you want to define C in the same message as one of the timetlv TLVs, that suggests you may not be using the right format in the first place. -----Original Message----- From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 Sent: 18 November 2007 09:56 To: manet@ietf.org Cc: T.Clausen@computer.org; Dearlove, Christopher (UK) Subject: Re: [manet] New Version Notification for draft-ietf-manet-timetlv-03 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 I think it would be useful for TimeTLV to specify a method for carrying 'C'. I understand that normally nodes (or implementations) might be configured with 'C' for each TimeTLV type. For cases where C is either unknown or required, I think we should specify a format for carrying it. I see carrying C as most important when C misunderstandings could cause routing to fail. I believe there are several different options for encoding this information. What do you think would be the best way? Ian On Nov 15, 2007 9:48 PM, IETF I-D Submission Tool wrote: > > A new version of I-D, draft-ietf-manet-timetlv-03.txt has been successfuly submitted by Thomas Clausen and posted to the IETF repository. > > Filename: draft-ietf-manet-timetlv > Revision: 03 > Title: Representing multi-value time in MANETs > Creation_date: 2007-11-15 > WG ID: manet > Number_of_pages: 18 > > Abstract: > This document describes a general and flexible TLV (type-length-value > structure) for representing time using the generalized MANET packet/ > message format. It defines two message and two address block TLVs > for representing validity and interval times for MANET routing > protocols. > > > > The IETF Secretariat. > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 20 05:58:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuQnz-000601-NP; Tue, 20 Nov 2007 05:58:11 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IuQny-0005zl-JX for manet-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 05:58:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuQny-0005zb-9y for manet@ietf.org; Tue, 20 Nov 2007 05:58:10 -0500 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuQnv-0006Ez-Vb for manet@ietf.org; Tue, 20 Nov 2007 05:58:10 -0500 Received: by ug-out-1314.google.com with SMTP id u2so3605791uge for ; Tue, 20 Nov 2007 02:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; 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; bh=1UttslCM4F1PCrxrPSLUYzQv8cTf87iEVxxpuOaw0fA=; b=jyYfOGBV2Qw6wlSPjtNDfL0QYUeJi0Fmgqy2ql+PpPzWyIgkt1tnuf20v/n6tlbkENrJpnE9f+1j4F27pcqlixwpkureo0hTiyF8rXtHOnYue1cw41gnGMNdXx+5Zu5YScaJZsZCnehckXlCxJM6iwzgtqkp7w+Z3ZMUtVCqrE8= 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=FHLREMu48/uh/+afB0iVEb7rGL6YuhJx1wdl/PqpLZOqUcUbS8w6p8pdHJbBAjVVKIjBi3lza7dMYf7mtjL1hNNc+nrSMupXkYPcijiLzMfbkEKzcUytAXzT7svZsS65IBefPvBVUprUB0JrgRALR1FW6Uc+i1nV8wPsb9my6mI= Received: by 10.78.180.18 with SMTP id c18mr544793huf.1195556285186; Tue, 20 Nov 2007 02:58:05 -0800 (PST) Received: by 10.78.19.9 with HTTP; Tue, 20 Nov 2007 02:58:05 -0800 (PST) Message-ID: <374005f30711200258j5fdfbedcpfde72f3f5c5bd3be@mail.gmail.com> Date: Tue, 20 Nov 2007 16:28:05 +0530 From: "Ian Chakeres" To: "Dearlove, Christopher (UK)" Subject: Re: [manet] New Version Notification for draft-ietf-manet-timetlv-03 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30711180155h60d58de3mfc2a8feba0479c2d@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: manet@ietf.org, T.Clausen@computer.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. On Nov 20, 2007 3:23 PM, Dearlove, Christopher (UK) wrote: > > I'm in agreement that this is neither intended nor > desirable. Actually I don't think it's ever desirable, > but especially not in timetlv. I am not concerned about the timetlv format. I am concerned about the two TLVs specified/allocated in the TimeTLV document. That is VALIDITY and INTERVAL. > Why never desirable? First it isn't usually necessary. > If C = 1 ms you can have times up to 1.5 months at > millisecond resolution. If C = 1 second you can have > times up to over a century, at second resolution. > (Other figures are of course possible.) > > Second the point of timetlv is passing an unambiguous > time, often in circumstances where communications has > not yet been established. If you had to negotiate C for > routing (which is after all why we are here) you'd have > to do that before any other form of topology formation > etc. that used C. This would be really bad. So for our > main use cases, negotiating C really doesn't work. This fact seems to motivate that C been defined/specified somewhere for any timetlv instance. Otherwise, misunderstandings could cause major problems. I believe this may be one of the reasons that OSPF carries timing information in its messages. Ian > Yes, I can conceive of a protocol that want to negotiate > C (that doesn't however mean I think it's likely - I > think it's very unlikely given my first point). If so > that protocol can define such a process. It's way outside > what timetlv should include, especially given that it's > an obscure case. (And as we have no prior art, defining a > good mechanism would be tricky.) > > Realised there's one more point. If you want to define C > in the same message as one of the timetlv TLVs, that > suggests you may not be using the right format in the > first place. > > > -----Original Message----- > From: Ian Chakeres [mailto:ian.chakeres@gmail.com] > Sent: 18 November 2007 09:56 > To: manet@ietf.org > Cc: T.Clausen@computer.org; Dearlove, Christopher (UK) > Subject: Re: [manet] New Version Notification for > draft-ietf-manet-timetlv-03 > > > *** 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 it would be useful for TimeTLV to specify a method for > carrying 'C'. I understand that normally nodes (or implementations) > might be configured with 'C' for each TimeTLV type. For cases where C > is either unknown or required, I think we should specify a format for > carrying it. I see carrying C as most important when C > misunderstandings could cause routing to fail. > > I believe there are several different options for encoding this > information. What do you think would be the best way? > > Ian > > On Nov 15, 2007 9:48 PM, IETF I-D Submission Tool > wrote: > > > > A new version of I-D, draft-ietf-manet-timetlv-03.txt has been > successfuly submitted by Thomas Clausen and posted to the IETF > repository. > > > > Filename: draft-ietf-manet-timetlv > > Revision: 03 > > Title: Representing multi-value time in MANETs > > Creation_date: 2007-11-15 > > WG ID: manet > > Number_of_pages: 18 > > > > Abstract: > > This document describes a general and flexible TLV (type-length-value > > structure) for representing time using the generalized MANET packet/ > > message format. It defines two message and two address block TLVs > > for representing validity and interval times for MANET routing > > protocols. > > > > > > > > The IETF Secretariat. > > > > > > > > > > _______________________________________________ > > manet mailing list > > manet@ietf.org > > https://www1.ietf.org/mailman/listinfo/manet > > > > > ******************************************************************** > 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 20 06:05:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuQv7-0007fs-LP; Tue, 20 Nov 2007 06:05:33 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IuQv5-0007fF-EY for manet-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 06:05:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuQv2-0007ek-2u for manet@ietf.org; Tue, 20 Nov 2007 06:05:28 -0500 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuQuz-0006Ud-Hn for manet@ietf.org; Tue, 20 Nov 2007 06:05:28 -0500 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lAKB5JgV018234 for ; Tue, 20 Nov 2007 11:05:19 GMT 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 lAKB5JX4012956 for ; Tue, 20 Nov 2007 11:05:19 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 20 Nov 2007 11:05:18 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 20 Nov 2007 11:05:18 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] New Version Notification for draft-ietf-manet-timetlv-03 Date: Tue, 20 Nov 2007 11:05:17 -0000 Message-ID: In-Reply-To: <374005f30711200258j5fdfbedcpfde72f3f5c5bd3be@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New Version Notification for draft-ietf-manet-timetlv-03 Thread-Index: AcgrZD8db5uKh+GqTo2WO+9Wlp0blAAADotA References: <374005f30711180155h60d58de3mfc2a8feba0479c2d@mail.gmail.com> <374005f30711200258j5fdfbedcpfde72f3f5c5bd3be@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Ian Chakeres" X-OriginalArrivalTime: 20 Nov 2007 11:05:18.0989 (UTC) FILETIME=[3CAF93D0:01C82B65] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: manet@ietf.org, T.Clausen@computer.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > This fact seems to motivate that C been defined/specified somewhere > for any timetlv instance. Otherwise, misunderstandings could cause > major problems. Quoting timtlv: "All nodes in the network MUST use the same value of the constant C". "A protocol using this time representation MUST define the value of C." That's pretty clear. The whole purpose of timetlv is to allow sending accurate enough times in one octet. To do this nodes need to agree on something, and what they agree on is C. Agreeing on C is easy with the massive range we now have. Then making you have to transfer C defeats the whole efficiency point, and making C variable defeats the whole point entirely. ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 20 06:50:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRcK-0002pn-IN; Tue, 20 Nov 2007 06:50:12 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IuRcJ-0002pi-8K for manet-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 06:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRcI-0002pa-V7 for manet@ietf.org; Tue, 20 Nov 2007 06:50:10 -0500 Received: from hpsmtp-eml18.kpnxchange.com ([213.75.38.118]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuRcF-0007fF-H5 for manet@ietf.org; Tue, 20 Nov 2007 06:50:10 -0500 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 12:50:06 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 12:50:06 +0100 From: "Teco Boot" To: "'Ian Chakeres'" , "'Dearlove, Christopher \(UK\)'" References: <374005f30711180155h60d58de3mfc2a8feba0479c2d@mail.gmail.com> <374005f30711200258j5fdfbedcpfde72f3f5c5bd3be@mail.gmail.com> In-Reply-To: <374005f30711200258j5fdfbedcpfde72f3f5c5bd3be@mail.gmail.com> Subject: RE: [manet] New Version Notification for draft-ietf-manet-timetlv-03 Date: Tue, 20 Nov 2007 12:50:01 +0100 Message-ID: <008701c82b6b$7bfb4920$73f1db60$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgrZLX8ZH3oFLQST4CDo7RmdE4fLgABo2Tw Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 11:50:06.0171 (UTC) FILETIME=[7E5F02B0:01C82B6B] X-Spam-Score: -1.0 (-) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: manet@ietf.org, T.Clausen@computer.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > > Why never desirable? First it isn't usually necessary. > > If C = 1 ms you can have times up to 1.5 months at > > millisecond resolution. If C = 1 second you can have > > times up to over a century, at second resolution. > > (Other figures are of course possible.) The claim on precision is marketing stuf. On the low end it is correct, on the high end the resolution is far from seconds or milliseconds. Seconds: last increment is more than 8,5 years Milliseconds: last increment is more than 3,5 days Teco. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 20 07:04:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRpm-0003bk-63; Tue, 20 Nov 2007 07:04:06 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IuRpk-0003ba-WA for manet-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 07:04:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuRpk-0003bS-La for manet@ietf.org; Tue, 20 Nov 2007 07:04:04 -0500 Received: from hpsmtp-eml15.kpnxchange.com ([213.75.38.115]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuRpj-0008Pt-T3 for manet@ietf.org; Tue, 20 Nov 2007 07:04:04 -0500 Received: from hpsmtp-eml04.kpnxchange.com ([213.75.38.104]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 13:04:02 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml04.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 13:04:01 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Ian Chakeres'" References: <374005f30711180155h60d58de3mfc2a8feba0479c2d@mail.gmail.com> <374005f30711200258j5fdfbedcpfde72f3f5c5bd3be@mail.gmail.com> In-Reply-To: Subject: RE: [manet] New Version Notification for draft-ietf-manet-timetlv-03 Date: Tue, 20 Nov 2007 13:03:58 +0100 Message-ID: <008801c82b6d$6e4dc800$4ae95800$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgrZD8db5uKh+GqTo2WO+9Wlp0blAAADotAAAD2UfA= Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 12:04:02.0022 (UTC) FILETIME=[7093C060:01C82B6D] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: manet@ietf.org, T.Clausen@computer.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > > This fact seems to motivate that C been defined/specified somewhere > > for any timetlv instance. Otherwise, misunderstandings could cause > > major problems. > > Quoting timtlv: > > "All nodes in the network MUST use the same value of the constant C". This is not exactly true. The TimeTLV can be used for multiple purposes, and by multiple protocols. In that case, there are multiple constants C and they may be different. But for a particular usage, the constant is really constant. > > "A protocol using this time representation MUST define the value of C." > > That's pretty clear. Yes;-) > > The whole purpose of timetlv is to allow sending accurate > enough times in one octet. To do this nodes need to agree > on something, and what they agree on is C. Agreeing on C > is easy with the massive range we now have. Then making > you have to transfer C defeats the whole efficiency point, > and making C variable defeats the whole point entirely. I agree with Ian that it is not clearly defined what the constant C is, when using VALIDITY_TIME TLV or INTERVAL_TIME TLV. Text in sections 7 and 8 could repeat the requirement that the protocol using this MUST specify the constant C for it. Thought on defining a default? We could add the text: Unless otherwise specified, the constant C defaults to 0.0625 second (1/16 second). Teco. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 20 07:27:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuSCD-000631-68; Tue, 20 Nov 2007 07:27:17 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IuSCA-00062n-Nt for manet-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 07:27:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuSCA-00062Y-DF for manet@ietf.org; Tue, 20 Nov 2007 07:27:14 -0500 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuSC5-0000Vi-Mk for manet@ietf.org; Tue, 20 Nov 2007 07:27:10 -0500 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lAKCQtrC021719 for ; Tue, 20 Nov 2007 12:26:55 GMT 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 lAKCQrVD010897 for ; Tue, 20 Nov 2007 12:26:53 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 20 Nov 2007 12:26:53 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 20 Nov 2007 12:26:53 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] New Version Notification for draft-ietf-manet-timetlv-03 Date: Tue, 20 Nov 2007 12:26:52 -0000 Message-ID: In-Reply-To: <008701c82b6b$7bfb4920$73f1db60$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New Version Notification for draft-ietf-manet-timetlv-03 Thread-Index: AcgrZLX8ZH3oFLQST4CDo7RmdE4fLgABo2TwAAFJaIA= References: <374005f30711180155h60d58de3mfc2a8feba0479c2d@mail.gmail.com> <374005f30711200258j5fdfbedcpfde72f3f5c5bd3be@mail.gmail.com> <008701c82b6b$7bfb4920$73f1db60$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ian Chakeres" X-OriginalArrivalTime: 20 Nov 2007 12:26:53.0220 (UTC) FILETIME=[A1DFF640:01C82B70] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: manet@ietf.org, T.Clausen@computer.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org You are correct, I should have made a more precise statement. But it's not marketing. =20 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 20 November 2007 11:50 To: 'Ian Chakeres'; Dearlove, Christopher (UK) Cc: manet@ietf.org; T.Clausen@computer.org Subject: RE: [manet] New Version Notification for draft-ietf-manet-timetlv-03 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 > > Why never desirable? First it isn't usually necessary. > > If C =3D 1 ms you can have times up to 1.5 months at > > millisecond resolution. If C =3D 1 second you can have > > times up to over a century, at second resolution. > > (Other figures are of course possible.) The claim on precision is marketing stuf. On the low end it is correct, on the high end the resolution is far from seconds or milliseconds. Seconds: last increment is more than 8,5 years Milliseconds: last increment is more than 3,5 days Teco. ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 20 07:32:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuSHT-0001pm-27; Tue, 20 Nov 2007 07:32:43 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IuSHQ-0001pX-Ni for manet-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 07:32:40 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuSHQ-0001pP-Cs for manet@ietf.org; Tue, 20 Nov 2007 07:32:40 -0500 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuSHP-0000du-Hr for manet@ietf.org; Tue, 20 Nov 2007 07:32:40 -0500 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lAKCWbfU011869 for ; Tue, 20 Nov 2007 12:32:37 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id lAKCWbrd005503 for ; Tue, 20 Nov 2007 12:32:37 GMT Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 20 Nov 2007 12:32:36 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Tue, 20 Nov 2007 12:32:36 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] New Version Notification for draft-ietf-manet-timetlv-03 Date: Tue, 20 Nov 2007 12:32:35 -0000 Message-ID: In-Reply-To: <008801c82b6d$6e4dc800$4ae95800$@nl> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] New Version Notification for draft-ietf-manet-timetlv-03 Thread-Index: AcgrZD8db5uKh+GqTo2WO+9Wlp0blAAADotAAAD2UfAAAheeIA== References: <374005f30711180155h60d58de3mfc2a8feba0479c2d@mail.gmail.com> <374005f30711200258j5fdfbedcpfde72f3f5c5bd3be@mail.gmail.com> <008801c82b6d$6e4dc800$4ae95800$@nl> From: "Dearlove, Christopher (UK)" To: "Teco Boot" , "Ian Chakeres" X-OriginalArrivalTime: 20 Nov 2007 12:32:36.0580 (UTC) FILETIME=[6E888A40:01C82B71] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: manet@ietf.org, T.Clausen@computer.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org We did think about a default. However I can see at least three sensible values for a default (1 ms, 1/16 s, 1 s) and I'm not sure mandating one would be productive. I fail to understand in the least how it's not clear when using those TLVs. They are defined as being time TLVs, using the specified representation of tiem, in which C is mandated as being defined as a constant. I see absolutely no value in using different values of C for the two TLVs. They clearly must be of the same order of magnitude or thereabouts, and a factor of 10 is small in the about 4 million factor range offered. =20 -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl]=20 Sent: 20 November 2007 12:04 To: Dearlove, Christopher (UK); 'Ian Chakeres' Cc: manet@ietf.org; T.Clausen@computer.org Subject: RE: [manet] New Version Notification for draft-ietf-manet-timetlv-03 *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 > > This fact seems to motivate that C been defined/specified somewhere > > for any timetlv instance. Otherwise, misunderstandings could cause > > major problems. >=20 > Quoting timtlv: >=20 > "All nodes in the network MUST use the same value of the constant C". This is not exactly true. The TimeTLV can be used for multiple purposes, and by multiple protocols. In that case, there are multiple constants C and they may be different. But for a particular usage, the constant is really constant. >=20 > "A protocol using this time representation MUST define the value of C." >=20 > That's pretty clear. Yes;-) >=20 > The whole purpose of timetlv is to allow sending accurate > enough times in one octet. To do this nodes need to agree > on something, and what they agree on is C. Agreeing on C > is easy with the massive range we now have. Then making > you have to transfer C defeats the whole efficiency point, > and making C variable defeats the whole point entirely. I agree with Ian that it is not clearly defined what the constant C is, when using VALIDITY_TIME TLV or INTERVAL_TIME TLV. Text in sections 7 and 8 could repeat the requirement that the protocol using this MUST specify the constant C for it. Thought on defining a default? We could add the text:=20 =20 Unless otherwise specified, the constant C defaults to 0.0625 second (1/16 second). Teco. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 20 08:41:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTLh-0006yH-Dx; Tue, 20 Nov 2007 08:41:09 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IuTLf-0006y6-RY for manet-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 08:41:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuTLf-0006wz-Hc for manet@ietf.org; Tue, 20 Nov 2007 08:41:07 -0500 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuTLZ-0002E5-JR for manet@ietf.org; Tue, 20 Nov 2007 08:41:07 -0500 Received: from hpsmtp-eml06.kpnxchange.com ([213.75.38.106]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 14:41:00 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 14:41:00 +0100 From: "Teco Boot" To: "'Dearlove, Christopher \(UK\)'" , "'Ian Chakeres'" References: <374005f30711180155h60d58de3mfc2a8feba0479c2d@mail.gmail.com> <374005f30711200258j5fdfbedcpfde72f3f5c5bd3be@mail.gmail.com> <008801c82b6d$6e4dc800$4ae95800$@nl> In-Reply-To: Subject: RE: [manet] New Version Notification for draft-ietf-manet-timetlv-03 Date: Tue, 20 Nov 2007 14:40:56 +0100 Message-ID: <009201c82b7a$fa1a2100$ee4e6300$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcgrZD8db5uKh+GqTo2WO+9Wlp0blAAADotAAAD2UfAAAheeIAACMOKQ Content-Language: nl X-OriginalArrivalTime: 20 Nov 2007 13:41:00.0478 (UTC) FILETIME=[FCA5ADE0:01C82B7A] X-Spam-Score: -1.0 (-) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: manet@ietf.org, T.Clausen@computer.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On using different C values in the same MANET: This is for different purposes, e.g. ISO 3166 country names and country IDs have long expiration dates (5 years). My personal mobile phone number could change, expiration time would be weeks. A fixed line number expires in minutes, as I could move from here to there. So there are different values for C (I agree on this concept) but for different purposes there may be different constants, even in the same MANET. Teco. > -----Oorspronkelijk bericht----- > Van: Dearlove, Christopher (UK) [mailto:Chris.Dearlove@baesystems.com] > Verzonden: dinsdag 20 november 2007 13:33 > Aan: Teco Boot; Ian Chakeres > CC: manet@ietf.org; T.Clausen@computer.org > Onderwerp: RE: [manet] New Version Notification for draft-ietf-manet- > timetlv-03 > > > We did think about a default. However I can see at least > three sensible values for a default (1 ms, 1/16 s, 1 s) > and I'm not sure mandating one would be productive. > > I fail to understand in the least how it's not clear when > using those TLVs. They are defined as being time TLVs, using > the specified representation of tiem, in which C is mandated > as being defined as a constant. > > I see absolutely no value in using different values of C for > the two TLVs. They clearly must be of the same order of > magnitude or thereabouts, and a factor of 10 is small in the > about 4 million factor range offered. > > > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: 20 November 2007 12:04 > To: Dearlove, Christopher (UK); 'Ian Chakeres' > Cc: manet@ietf.org; T.Clausen@computer.org > Subject: RE: [manet] New Version Notification for > draft-ietf-manet-timetlv-03 > > > *** 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. > > > > This fact seems to motivate that C been defined/specified somewhere > > > for any timetlv instance. Otherwise, misunderstandings could cause > > > major problems. > > > > Quoting timtlv: > > > > "All nodes in the network MUST use the same value of the constant C". > > This is not exactly true. > The TimeTLV can be used for multiple purposes, and by multiple > protocols. In > that case, there are multiple constants C and they may be different. > But > for > a particular usage, the constant is really constant. > > > > > "A protocol using this time representation MUST define the value of > C." > > > > That's pretty clear. > Yes;-) > > > > > The whole purpose of timetlv is to allow sending accurate > > enough times in one octet. To do this nodes need to agree > > on something, and what they agree on is C. Agreeing on C > > is easy with the massive range we now have. Then making > > you have to transfer C defeats the whole efficiency point, > > and making C variable defeats the whole point entirely. > > I agree with Ian that it is not clearly defined what the constant C is, > when > using VALIDITY_TIME TLV or INTERVAL_TIME TLV. > Text in sections 7 and 8 could repeat the requirement that the protocol > using this MUST specify the constant C for it. > > Thought on defining a default? > We could add the text: > > Unless otherwise specified, the constant C defaults to 0.0625 > second > (1/16 second). > > Teco. > > > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > > > ******************************************************************** > 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 20 09:59:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUZd-0002f9-RO; Tue, 20 Nov 2007 09:59:37 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IuUZd-0002f4-58 for manet-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 09:59:37 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IuUZc-0002ew-SD for manet@ietf.org; Tue, 20 Nov 2007 09:59:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuUAg-0007Rq-MO for manet@ietf.org; Tue, 20 Nov 2007 09:33:50 -0500 Received: from web7602.mail.in.yahoo.com ([202.86.4.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IuUAc-0003mh-OQ for manet@ietf.org; Tue, 20 Nov 2007 09:33:50 -0500 Received: (qmail 53757 invoked by uid 60001); 20 Nov 2007 14:33:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=aqWvquP1BzEqwagNyf5Yeh3wagfsloZf5HpjTUmFKZahCRBV1PTqCJghrAwbx49kGwCv6RMeq7Jn43DNs7DHKeSATwUHJg4nBgCgQaqs5UP6JZ3W7u2adQ0bjw0bPkRqIZRt3I8+/K0gd8iEIfGom1gQlS39iv/nJAgY7gGW9QM=; X-YMail-OSG: vjZObOQVM1l5BVt4zxQNQJMpNVcP0QloLePL9vJp Received: from [210.212.49.25] by web7602.mail.in.yahoo.com via HTTP; Tue, 20 Nov 2007 14:33:44 GMT Date: Tue, 20 Nov 2007 14:33:44 +0000 (GMT) From: tanvi goel To: manet@ietf.org MIME-Version: 1.0 Message-ID: <712121.53537.qm@web7602.mail.in.yahoo.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-TMDA-Confirmed: Tue, 20 Nov 2007 09:59:36 -0500 Subject: [manet] maodv code X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1931280400==" Errors-To: manet-bounces@ietf.org --===============1931280400== Content-Type: multipart/alternative; boundary="0-147515520-1195569224=:53537" Content-Transfer-Encoding: 8bit --0-147515520-1195569224=:53537 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit i need the simulation code for maodv on ns2. it is urgent.. thanks --------------------------------- Forgot the famous last words? Access your message archive online. Click here. --0-147515520-1195569224=:53537 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit i need the simulation code for maodv on ns2. it is urgent..
thanks

Forgot the famous last words? Access your message archive online. Click here. --0-147515520-1195569224=:53537-- --===============1931280400== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============1931280400==-- From manet-bounces@ietf.org Tue Nov 20 10:59:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVV2-0005Dm-Hg; Tue, 20 Nov 2007 10:58:56 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IuVV0-0005Ab-GD for manet-confirm+ok@megatron.ietf.org; Tue, 20 Nov 2007 10:58:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVV0-0005AK-6P; Tue, 20 Nov 2007 10:58:54 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuVUz-0006J8-UI; Tue, 20 Nov 2007 10:58:54 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id B9FCB26E60; Tue, 20 Nov 2007 15:58:53 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuVUz-0001AV-Le; Tue, 20 Nov 2007 10:58:53 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 20 Nov 2007 10:58:53 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: manet chair , manet mailing list , Internet Architecture Board , RFC Editor Subject: [manet] Protocol Action: 'IANA Allocations for MANET Protocols' to Proposed Standard X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The IESG has approved the following document: - 'IANA Allocations for MANET Protocols ' as a Proposed Standard This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-07.txt Technical Summary This document requests IANA allocate a UDP port and link-local multicast addresses (IPv4 & IPv6) for communication between MANET routers. Working Group Summary Strong WG agreement is reported (see PROTO writeup). Several other WG documents contain normative references to this draft. Protocol Quality Ross Callon has reviewed this for the IESG (Bill Fenner has also reviewed the draft). Because this draft only requests IANA assignments, this draft per se doesn't get implemented (although the associated code points, when assigned, will be used by other drafts). _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 21 00:04:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuhku-0007rP-KE; Wed, 21 Nov 2007 00:04:08 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iuhks-0007rK-QS for manet-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 00:04:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iuhks-0007rC-FY for manet@ietf.org; Wed, 21 Nov 2007 00:04:06 -0500 Received: from nf-out-0910.google.com ([64.233.182.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iuhko-0000DS-43 for manet@ietf.org; Wed, 21 Nov 2007 00:04:05 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1816629nfb for ; Tue, 20 Nov 2007 21:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=/yvm41BvykjfGgYKwuBspBNexqF83LKK/geYulRMyGw=; b=MSiR/qAgLPHeNCepOPtQAuZmPwz05gUF8l8wr3zPVy8FZcfrL1AOCUHTBiVy8JtjAuHJE/NI0dEwCTItAO+dani3tlCAhIQHq45b9CLz7wUKDZrBzMGU3vPtUyqovcke5RmqUzvLANmb1x71waH7XmD0NS/cb7MwZkfTDnxPJ5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=KBqHQuDGMpvLPpMES5wSqvH14R4nkbRu2ZN6Lsk64bGpoix24+bupgFtY3e1q/FBUtPEglPpLtqGx37WpoE1R4IVvSk3udywlbVN9zLqQDAcSDQnpD9FTEpfopBO7cKTM3ASUXHF95pr+vpm0BlpNORcLbQJKMwPsosSgpLhjm8= Received: by 10.78.180.18 with SMTP id c18mr1804345huf.1195621441101; Tue, 20 Nov 2007 21:04:01 -0800 (PST) Received: by 10.78.19.9 with HTTP; Tue, 20 Nov 2007 21:04:01 -0800 (PST) Message-ID: <374005f30711202104r3bf2c00cm75a089302147b5d8@mail.gmail.com> Date: Wed, 21 Nov 2007 10:34:01 +0530 From: "Ian Chakeres" To: "Ross Callon" , "David Ward" , iesg-secretary@ietf.org, manet MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: Christopher Dearlove , Thomas Clausen , Cedric Adjih Subject: [manet] Request to publish draft-ietf-manet-packetbb-11.txt - writeup included X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I would like to request that draft-ietf-manet-packetbb-11.txt be published. I am the shepherding WG chair. ===WRITE-UP=== 1. Have the chairs personally reviewed this version of the Internet Draft (I-D), and in particular, do they believe this I-D is ready to forward to the IESG for publication? YES. 2. Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? YES the ID has been adequately reviewed. 3. Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? The document has been reviewed by the security directorate, and the suggestions were included in the recent revisions. 4. Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. During the WGLC period a few issues were brought up. Efficiency - The I-D represents a trade-off between expressiveness/flexibility on one side and encoding-efficiency on the other side. Certain members of the WG feel that a trade-off favoring more encoding-efficiency against less expressiveness or flexibility would be desirable. The I-D has developed since its inception to be accommodating in this area and, despite some remaining criticism, there is consensus to progress with the current specification. Ordering and uniqueness of TLVs - Previous versions of this I-D mandated strict ordering and uniqueness constraints on TLVs, recognizing that (i) such allows for efficiency in parsing and (ii) that such does not limit expressiveness and processing by a protocol using this specification. Certain members of the WG felt that this was unacceptable for potential future uses. This was accommodated by the latest I-D, which allows relaxing these constraints if explicitly signaled. The WGLC was extended to allow for comments on this compromise and no negative comments were received. There is therefore consensus to progress with the current specification. 5. How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? All the other significant WG documents contain a reference to this ID. Though there has been recent disagreement on a few small details (described above), the document overall has significant support. 6. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email to the Responsible Area Director. The current version of this I-D has addressed the issues causing discontent, and during the extended WGLC no objections were raised. 7. Have the chairs verified that the document adheres to all of the ID Checklist items ? YES. 8. Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) YES the references are split into normative and informative references. 9. What is the intended status of the document? (e.g., Proposed Standard, Informational?) Proposed Standard. 10. For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: * Technical Summary This document specifies the syntax of a general purpose multi- message packet format for information exchange between MANET routers. The format has been designed with extensibility, efficiency, and a clear separation of forwarding and processing. * Working Group Summary This document contains information that was originally in OLSRv2. It was pulled out and generalized, since it is applicable to many MANET WG protocols - specifically NHDP, OLSRv2, and DYMO. Though there was some recent disagreement about some details (see above), the overall support for this document is large. It is an integral component of other WG specifications, namely NHDP, OLSRv2, and DYMO. * Protocol Quality From an efficiency standpoint this specification is a large improvement from previous protocol instances. For example, in OLSRv1 with IPv6 - OLSRv2 (using the document being put forward for publication) can reduce the number of packets transmitted by half (by aggregating multiple messages) and it can reduce the overhead by half (by compressing addresses). There are many implementations. Interoperability (of this specification) in conjunction with others that cite (namely OLSRv2) have been performed. =========== _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Sat Nov 24 06:37:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtJB-000865-42; Sat, 24 Nov 2007 06:36:25 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IvtJ8-00084g-5q for manet-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 06:36:22 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtJ7-00083u-Pt; Sat, 24 Nov 2007 06:36:21 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvtJ6-0001FD-P3; Sat, 24 Nov 2007 06:36:21 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2cc47481460; Sat, 24 Nov 2007 19:49:17 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm534741b1d7; Mon, 19 Nov 2007 22:13:01 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 22:13:01 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu71Z-00043W-SZ; Mon, 19 Nov 2007 08:50:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu71F-0003Xr-J8; Mon, 19 Nov 2007 08:50:33 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu71E-00005s-5H; Mon, 19 Nov 2007 08:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 091A82AC61; Mon, 19 Nov 2007 13:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu70j-0004of-Pe; Mon, 19 Nov 2007 08:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 08:50:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-smf-06.txt X-BeenThere: manet@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Simplified Multicast Forwarding for MANET Author(s) : J. Macker, S. Team Filename : draft-ietf-manet-smf-06.txt Pages : 47 Date : 2007-11-17 This document describes a Simplified Multicast Forwarding (SMF) mechanism that provides basic IP multicast forwarding suitable for wireless mesh and mobile ad hoc network (MANET) use. SMF specifies techniques for multicast duplicate packet detection (DPD) to assist the forwarding process. SMF also specifies DPD maintenance and checking operations consistent with both IPv4 and IPv6. SMF takes advantage of reduced relay sets for efficient MANET multicast forwarding within a mesh topology and the document describes protocol interaction with a number of approaches. Candidate algorithms for selecting reduced relay sets and related discussion is provided in the Appendices. Basic issues relating to the operation of multicast MANET border routers are discussed but ongoing work remains in this area beyond the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-06.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-smf-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-smf-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19084723.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-smf-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-smf-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19084723.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Sat Nov 24 06:38:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtLZ-0001qy-An; Sat, 24 Nov 2007 06:38:53 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IvtLX-0001ql-Vd for manet-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 06:38:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtLX-0001qc-Lr; Sat, 24 Nov 2007 06:38:51 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvtLT-00075y-Jb; Sat, 24 Nov 2007 06:38:51 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm2f4748184c; Sat, 24 Nov 2007 19:51:45 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm764741908b; Mon, 19 Nov 2007 19:53:27 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 19:53:26 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4Cj-0004ny-Kq; Mon, 19 Nov 2007 05:50:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4CY-0004GX-UV; Mon, 19 Nov 2007 05:50:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu4CY-0000pJ-A5; Mon, 19 Nov 2007 05:50:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 379F5327BC; Mon, 19 Nov 2007 10:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu4CY-0004dp-4A; Mon, 19 Nov 2007 05:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 05:50:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-jitter-03.txt X-BeenThere: manet@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Jitter considerations in Mobile Ad Hoc Networks (MANETs) Author(s) : T. Clausen, et al. Filename : draft-ietf-manet-jitter-03.txt Pages : 18 Date : 2007-11-19 This document provides recommendations for jittering (randomly modifying timing) of control traffic transmissions in Mobile Ad hoc NETwork (MANET) routing protocols to reduce the probability of transmission collisions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-jitter-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-jitter-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-jitter-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19054147.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-jitter-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-jitter-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19054147.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Sat Nov 24 06:53:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtZk-0002yM-VO; Sat, 24 Nov 2007 06:53:32 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IvtZh-0002xs-PC for manet-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 06:53:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtZh-0002xc-Ac; Sat, 24 Nov 2007 06:53:29 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IvtZc-0007Ym-Kk; Sat, 24 Nov 2007 06:53:29 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jme047481e64; Sat, 24 Nov 2007 20:06:21 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm3a47418ff0; Mon, 19 Nov 2007 20:08:17 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Mon, 19 Nov 2007 20:08:17 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4Cn-0004qH-84; Mon, 19 Nov 2007 05:50:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu4CZ-0004Hh-2w; Mon, 19 Nov 2007 05:50:03 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu4CY-0000pK-Ee; Mon, 19 Nov 2007 05:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 48DFD327C0; Mon, 19 Nov 2007 10:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Iu4CY-0004du-5M; Mon, 19 Nov 2007 05:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 05:50:02 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Archive: X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: manet@ietf.org Subject: [manet] I-D Action:draft-ietf-manet-timetlv-04.txt X-BeenThere: manet@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF. Title : Representing multi-value time in MANETs Author(s) : T. Clausen, C. Dearlove Filename : draft-ietf-manet-timetlv-04.txt Pages : 18 Date : 2007-11-19 This document describes a general and flexible TLV (type-length-value structure) for representing time using the generalized MANET packet/ message format. It defines two message and two address block TLVs for representing validity and interval times for MANET routing protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-timetlv-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-manet-timetlv-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-manet-timetlv-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-19054202.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-manet-timetlv-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-manet-timetlv-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19054202.I-D\@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --NextPart-- From manet-bounces@ietf.org Sat Nov 24 06:55:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtbG-0003wk-Qi; Sat, 24 Nov 2007 06:55:06 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IvtbE-0003wU-UK for manet-confirm+ok@megatron.ietf.org; Sat, 24 Nov 2007 06:55:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IvtbE-0003wH-Jg; Sat, 24 Nov 2007 06:55:04 -0500 Received: from [202.99.23.227] (helo=people.com.cn) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IvtbD-0001x3-PH; Sat, 24 Nov 2007 06:55:04 -0500 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmba47483a33; Sat, 24 Nov 2007 20:07:40 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm94743105e; Wed, 21 Nov 2007 00:14:30 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Wed, 21 Nov 2007 00:14:30 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVV4-0005GA-Hb; Tue, 20 Nov 2007 10:58:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuVV0-0005AK-6P; Tue, 20 Nov 2007 10:58:54 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuVUz-0006J8-UI; Tue, 20 Nov 2007 10:58:54 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id B9FCB26E60; Tue, 20 Nov 2007 15:58:53 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IuVUz-0001AV-Le; Tue, 20 Nov 2007 10:58:53 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 20 Nov 2007 10:58:53 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: ietf-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: iesg-secretary@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.8 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: manet chair , manet mailing list , Internet Architecture Board , RFC Editor Subject: [manet] Protocol Action: 'IANA Allocations for MANET Protocols' to Proposed Standard X-BeenThere: manet@ietf.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The IESG has approved the following document: - 'IANA Allocations for MANET Protocols ' as a Proposed Standard This document is the product of the Mobile Ad-hoc Networks Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-manet-iana-07.txt Technical Summary This document requests IANA allocate a UDP port and link-local multicast addresses (IPv4 & IPv6) for communication between MANET routers. Working Group Summary Strong WG agreement is reported (see PROTO writeup). Several other WG documents contain normative references to this draft. Protocol Quality Ross Callon has reviewed this for the IESG (Bill Fenner has also reviewed the draft). Because this draft only requests IANA assignments, this draft per se doesn't get implemented (although the associated code points, when assigned, will be used by other drafts). _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 26 03:41:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZWm-0003IJ-6U; Mon, 26 Nov 2007 03:41:16 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IwZWl-0003ID-0m for manet-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 03:41:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwZWk-0003HZ-M4 for manet@ietf.org; Mon, 26 Nov 2007 03:41:14 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwZWd-0007DD-UW for manet@ietf.org; Mon, 26 Nov 2007 03:41:14 -0500 Received: by nz-out-0506.google.com with SMTP id n1so259535nzf for ; Mon, 26 Nov 2007 00:41:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=NiG8zwIEvOt/v6UWD+jZ8PK4U5WYGSvqjp4N+2N1q0Q=; b=dkehR7b01c7EGVbJL6YIzEElJp/oUQ7IYsdbYNehK4HvM/3Q3HEfHfBPDStkhPixJK5JbUNhWwJGD1ON33guVwCy0Ge5SXeX1NzaEqivL3DuGq3piFgExbp1+Y+Iw0B1aG1WbRso9hCY4Am/u2IHSfLWXjjm2AEI4gO5TTuSG1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=E3sKzFs807ibYBbIlrxR7vO1Xbpu4Ex6XHA37NHHuI5a5zL14JUgK3/HjC2bCg1T8RqgICORtXeximhT10RoSr+AedLyU3gyk11ha5UkaYd83reydElg7M2e3ZTUC5whNieWta+YDN11qNwIGgcmgrWqcm8r35+79XEeKN5G2ro= Received: by 10.114.52.1 with SMTP id z1mr890801waz.1196066466812; Mon, 26 Nov 2007 00:41:06 -0800 (PST) Received: by 10.114.112.5 with HTTP; Mon, 26 Nov 2007 00:41:01 -0800 (PST) Message-ID: <1716228e0711260041n142c1ddbxf6c8ba90f6b4c3c2@mail.gmail.com> Date: Mon, 26 Nov 2007 17:41:01 +0900 From: "Yasunori Owada" To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 62505faa06ebe045 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [manet] Packet looping issue in MANET routing protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello all, We have implemented OLSRv2 routing protocol that can run on Linux platform as daemon prosess and also run on QualNet simulator, and have been checking the protocol operation and performance. Through the real world experiments and simulation, we've found that MANET routing protocol cannot solve the looping path issue completely. The looping issue is acceralated when the Link Layer Notification is enabled, and much Looping occured with the proactive routing protocol such as OLSR and OLSRv2 compare to the reactive routing protocol such as AODV. This issue is caused form the node's network topology information inconsistency (usually more than 2 hop information inconsistency) for the proactive routing protocols. Once the looping occures, the traffic load jump up localy, and total network load incleases up to 20% in our simulation (50 nodes, random way-point movement, 1500m squared area). Unicast packet looping causes much traffic overhead because usually the unicast frame is retransmitted by the MAC layer when the ack frame doesn't come. This also leads large packet-delivery delay. In addition, we found that most looping is formed between two nodes (ping-poing looping). Very few triangle loops are fouded, but more larger loops are not found in our simulation. Loop privention or avoidance is difficult issue considering unstable wireless environment with multi-path fading and shadowing, but loop detection is possible. It is expanding DPD technique to the unicast packet. In this background we have submitted the initial I-D. The draft can be found at: http://www.ietf.org/internet-drafts/draft-mase-manet-loopdetect-00.txt I think this looping issue should be widely discussed in the MANET WG. Thanks, -- Assistant Professor of Natural Hazard and Disaster Recovery, Niigata University, Japan. Yasunori Owada TEL: +81-25-262-7429 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 26 04:32:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaKa-0002Rv-Pu; Mon, 26 Nov 2007 04:32:44 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IwaKY-0002RZ-RP for manet-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 04:32:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwaKY-0002RP-Gk for manet@ietf.org; Mon, 26 Nov 2007 04:32:42 -0500 Received: from smtp2.bae.co.uk ([20.133.0.12]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwaKT-0003Qf-UR for manet@ietf.org; Mon, 26 Nov 2007 04:32:38 -0500 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 lAQ9WaJU007442 for ; Mon, 26 Nov 2007 09:32:36 GMT 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 lAQ9WZbd004876 for ; Mon, 26 Nov 2007 09:32:35 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 26 Nov 2007 09:32:35 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 26 Nov 2007 09:32:34 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Packet looping issue in MANET routing protocol Date: Mon, 26 Nov 2007 09:32:33 -0000 Message-ID: In-Reply-To: <1716228e0711260041n142c1ddbxf6c8ba90f6b4c3c2@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Packet looping issue in MANET routing protocol Thread-Index: AcgwCDB0tA79SIkdRWeTS5zWz8c+6AABjs9A References: <1716228e0711260041n142c1ddbxf6c8ba90f6b4c3c2@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Yasunori Owada" , X-OriginalArrivalTime: 26 Nov 2007 09:32:34.0884 (UTC) FILETIME=[46B30840:01C8300F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org That Internet Draft says, in part The routing protocol may then act on the given LLN trigger, usually simply by removing a record of link from its Information Bases that store necessary information for routing and neighbor discovery to be able to calculate and update routing table. That is not what either OLSR or OLSRv2 say to do. You do not simply remove the entry from the information bases, you mark the entry in the information bases, change its state, and report that state in your HELLO messages, thus ensuring consistency. Furthermore they both indicate that such a change may (actually, should, subject to minimum message intervals in OLSRv2 - and some implementations of OLSR) cause you to sent such a HELLO message early. If implemented as described, you will have problems. But that would be down to a poor implementation, not a fundamental problem with the protocol. ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 26 06:03:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwbkD-00081U-76; Mon, 26 Nov 2007 06:03:17 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IwbkB-0007vo-9U for manet-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 06:03:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwbkA-0007tE-UN for manet@ietf.org; Mon, 26 Nov 2007 06:03:14 -0500 Received: from rv-out-0910.google.com ([209.85.198.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwbk3-0002Vb-Au for manet@ietf.org; Mon, 26 Nov 2007 06:03:14 -0500 Received: by rv-out-0910.google.com with SMTP id l15so472936rvb for ; Mon, 26 Nov 2007 03:03:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=ilTOvo+auxLzpgE1yPI48Tqxywaw9GUb16Nfy6i/UKA=; b=uyuE/29NlYrTqo33VNry6fsu6bqIEQGN61RrkS36xN2SZQC6Zea7ifd9uA3VnpILWcdnYDrCq8ArsjvcXS2G53DaIrwJjFMtwT4BzkxkzIjVLdVNnblkxE0SU8eVNKoBqk2vb9NrWyKUE6Kmr/ZsURnu7WzTDRtMp2Z8sks5Cf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pqjgey6cwsXzvSDL2iCp34sUAhmM7rBsk3p9n5YOXXf2vV0IKG1r2Ghs69r0M5bNaSn9hU/tIwKPaJPexTbm0CwZla/aTEbjx5p/WN9ulaMVxaMuHxepUvng3iPyEObJykXR3kUPmTRRGJu6pw5FdiUgebzRzaMVeSNXNSXbKhQ= Received: by 10.114.151.13 with SMTP id y13mr1749374wad.1196074986478; Mon, 26 Nov 2007 03:03:06 -0800 (PST) Received: by 10.114.112.5 with HTTP; Mon, 26 Nov 2007 03:03:06 -0800 (PST) Message-ID: <1716228e0711260303w233a590by4062c4ed1fbf2667@mail.gmail.com> Date: Mon, 26 Nov 2007 20:03:06 +0900 From: "Yasunori Owada" To: "Dearlove, Christopher (UK)" Subject: Re: [manet] Packet looping issue in MANET routing protocol In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1716228e0711260041n142c1ddbxf6c8ba90f6b4c3c2@mail.gmail.com> X-Google-Sender-Auth: 73248deac98ada87 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Chris, Thank you for comment. We thought the same thing and we'd implemented instant HELLO generation mechanisms as you mentioned into our OLSRv2 implementation. But that could prevent only few ping-pong loops, and most loops had remained. This is because these loops are formed as a result of the Topology Set information inconsistency, and the largest number of loops are caused from this inconsistency. TC message generation interval is longer than HELL's one, and TC message is usually only forwarded by the MPR. Considering the situation that link state changes frequently, MPR selector will be changed frequently and some TC message may not be forwarded to entire MANET node correctly. In addition, TC information inconsistency may be caused by Topology Set timer expiration. Instant TC message generation is one possibility to prevent this looping issue, but it incleases control message overhead considerably. So current solution is just discarding the looping packet. -- Assistant Professor of Natural Hazard and Disaster Recovery, Niigata University, Japan. Yasunori Owada TEL: +81-25-262-7429 2007/11/26, Dearlove, Christopher (UK) : > > That Internet Draft says, in part > > The routing protocol may then act on the given LLN trigger, usually > simply by removing a record of link from its Information Bases that > store necessary information for routing and neighbor discovery to be > able to calculate and update routing table. > > That is not what either OLSR or OLSRv2 say to do. You do not simply > remove the entry from the information bases, you mark the entry in > the information bases, change its state, and report that state in > your HELLO messages, thus ensuring consistency. Furthermore they > both indicate that such a change may (actually, should, subject to > minimum message intervals in OLSRv2 - and some implementations of > OLSR) cause you to sent such a HELLO message early. > > If implemented as described, you will have problems. But that would > be down to a poor implementation, not a fundamental problem with the > protocol. > > > ******************************************************************** > 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 26 07:21:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwcyA-0008Th-HK; Mon, 26 Nov 2007 07:21:46 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iwcy8-0008Tb-GA for manet-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 07:21:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwcy8-0008TT-6W for manet@ietf.org; Mon, 26 Nov 2007 07:21:44 -0500 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwcy2-0004Gb-FW for manet@ietf.org; Mon, 26 Nov 2007 07:21:44 -0500 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lAQCKMiV006438 for ; Mon, 26 Nov 2007 12:20:22 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id lAQCKMai027950 for ; Mon, 26 Nov 2007 12:20:22 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 26 Nov 2007 12:20:21 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Mon, 26 Nov 2007 12:20:21 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] Packet looping issue in MANET routing protocol Date: Mon, 26 Nov 2007 12:20:20 -0000 Message-ID: In-Reply-To: <1716228e0711260303w233a590by4062c4ed1fbf2667@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] Packet looping issue in MANET routing protocol Thread-Index: AcgwG/N90zPUHFu0Qky9xr04DvSrfQACX0+w References: <1716228e0711260041n142c1ddbxf6c8ba90f6b4c3c2@mail.gmail.com> <1716228e0711260303w233a590by4062c4ed1fbf2667@mail.gmail.com> From: "Dearlove, Christopher (UK)" To: "Yasunori Owada" X-OriginalArrivalTime: 26 Nov 2007 12:20:21.0399 (UTC) FILETIME=[B6CF5270:01C83026] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org If you implement LLNs correctly, I do not see why LLNs make a significant difference to the issue as you suggest. Local changes occur on a short timescale whether due to LLNs or other mechanisms. You do of course have to have timescales appropriate to your mobility. As for sending TCs when things change, that also is a SHOULD. Yes, it increases load, but the minimum intervals in OLSRv2 (which we first implemented in OLSRv1, see my paper at the first OLSR Interop) manage that quite successfully in our experience. For these and other reasons I therefore find these results surprising, and not in keeping with results we have seen in simulations (and reality, albeit in smaller networks). -----Original Message----- From: yowada@gmail.com [mailto:yowada@gmail.com] On Behalf Of Yasunori Owada Sent: 26 November 2007 11:03 To: Dearlove, Christopher (UK) Cc: manet@ietf.org Subject: Re: [manet] Packet looping issue in MANET routing protocol *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message.=20 Hello Chris, Thank you for comment. We thought the same thing and we'd implemented instant HELLO generation mechanisms as you mentioned into our OLSRv2 implementation. But that could prevent only few ping-pong loops, and most loops had remained. This is because these loops are formed as a result of the Topology Set information inconsistency, and the largest number of loops are caused from this inconsistency. TC message generation interval is longer than HELL's one, and TC message is usually only forwarded by the MPR. Considering the situation that link state changes frequently, MPR selector will be changed frequently and some TC message may not be forwarded to entire MANET node correctly. In addition, TC information inconsistency may be caused by Topology Set timer expiration. Instant TC message generation is one possibility to prevent this looping issue, but it incleases control message overhead considerably. So current solution is just discarding the looping packet. --=20 Assistant Professor of Natural Hazard and Disaster Recovery, Niigata University, Japan. Yasunori Owada TEL: +81-25-262-7429 2007/11/26, Dearlove, Christopher (UK) : > > That Internet Draft says, in part > > The routing protocol may then act on the given LLN trigger, usually > simply by removing a record of link from its Information Bases that > store necessary information for routing and neighbor discovery to be > able to calculate and update routing table. > > That is not what either OLSR or OLSRv2 say to do. You do not simply > remove the entry from the information bases, you mark the entry in > the information bases, change its state, and report that state in > your HELLO messages, thus ensuring consistency. Furthermore they > both indicate that such a change may (actually, should, subject to > minimum message intervals in OLSRv2 - and some implementations of > OLSR) cause you to sent such a HELLO message early. > > If implemented as described, you will have problems. But that would > be down to a poor implementation, not a fundamental problem with the > protocol. > > > ******************************************************************** > 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 26 08:03:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwdcj-0000KN-Lz; Mon, 26 Nov 2007 08:03:41 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IwWA4-0002zs-Oy for manet-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 00:05:36 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IwWA4-0002zj-Fl for manet@ietf.org; Mon, 26 Nov 2007 00:05:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwW8x-0002OT-Pr for manet@ietf.org; Mon, 26 Nov 2007 00:04:27 -0500 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwW8u-00025Z-Ao for manet@ietf.org; Mon, 26 Nov 2007 00:04:27 -0500 Received: by wr-out-0506.google.com with SMTP id 68so298861wra for ; Sun, 25 Nov 2007 21:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; bh=NiG8zwIEvOt/v6UWD+jZ8PK4U5WYGSvqjp4N+2N1q0Q=; b=v4F3ciwLGpOusf+IvIAhSNJwsqtFHUFYMavdvNq495FmFagqMEGuZZj7mVXc+lCqO0SxIweUUmUZoiYGwy0YZ0MTvqNTO6Dc3sguSyh4YAMd1/fSPggnxfh0CHEk5RGrvx3Omaem9frd1GglB2olIoQ9z4Os9rcc55S1lIT/8vk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=q3kwunnVFPsqWu5+Tmbaca5s9IdeAsvlwl8F3ngB7Wu4XdSvzcKOQtU30gD81Io+F9RJNx/yLPww9ihs9HyBqvmuMTnNZCNvqGHzYoVUPFA7+nSwsrxytYthZbs2ETdbF5D1svkV0g5d9pmWq49uZLffjdUGPVCdzjVTPSkfbvM= Received: by 10.115.59.4 with SMTP id m4mr266312wak.1196053462524; Sun, 25 Nov 2007 21:04:22 -0800 (PST) Received: by 10.114.112.5 with HTTP; Sun, 25 Nov 2007 21:04:22 -0800 (PST) Message-ID: <1716228e0711252104g717975abhbc012016e733c8e6@mail.gmail.com> Date: Mon, 26 Nov 2007 14:04:22 +0900 From: "Yasunori Owada" To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: e61195e7dddd7164 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-TMDA-Confirmed: Mon, 26 Nov 2007 00:05:36 -0500 X-Mailman-Approved-At: Mon, 26 Nov 2007 08:03:39 -0500 Subject: [manet] Packet looping issue in MANET routing protocol X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello all, We have implemented OLSRv2 routing protocol that can run on Linux platform as daemon prosess and also run on QualNet simulator, and have been checking the protocol operation and performance. Through the real world experiments and simulation, we've found that MANET routing protocol cannot solve the looping path issue completely. The looping issue is acceralated when the Link Layer Notification is enabled, and much Looping occured with the proactive routing protocol such as OLSR and OLSRv2 compare to the reactive routing protocol such as AODV. This issue is caused form the node's network topology information inconsistency (usually more than 2 hop information inconsistency) for the proactive routing protocols. Once the looping occures, the traffic load jump up localy, and total network load incleases up to 20% in our simulation (50 nodes, random way-point movement, 1500m squared area). Unicast packet looping causes much traffic overhead because usually the unicast frame is retransmitted by the MAC layer when the ack frame doesn't come. This also leads large packet-delivery delay. In addition, we found that most looping is formed between two nodes (ping-poing looping). Very few triangle loops are fouded, but more larger loops are not found in our simulation. Loop privention or avoidance is difficult issue considering unstable wireless environment with multi-path fading and shadowing, but loop detection is possible. It is expanding DPD technique to the unicast packet. In this background we have submitted the initial I-D. The draft can be found at: http://www.ietf.org/internet-drafts/draft-mase-manet-loopdetect-00.txt I think this looping issue should be widely discussed in the MANET WG. Thanks, -- Assistant Professor of Natural Hazard and Disaster Recovery, Niigata University, Japan. Yasunori Owada TEL: +81-25-262-7429 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 26 12:24:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwhgh-00024x-II; Mon, 26 Nov 2007 12:24:03 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iwhgg-00024k-G8 for manet-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 12:24:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwhgg-00024c-6V for manet@ietf.org; Mon, 26 Nov 2007 12:24:02 -0500 Received: from wa-out-1112.google.com ([209.85.146.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwhga-00053M-UE for manet@ietf.org; Mon, 26 Nov 2007 12:24:02 -0500 Received: by wa-out-1112.google.com with SMTP id k40so1239742wah for ; Mon, 26 Nov 2007 09:23:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=QqDRrPQL1E3xksigWxE29/aocx9byjw2fxLk84d9wUA=; b=oHNvSdjt8KqoEJKBAEb508xGgFcNVunRwOiet1RzTtzrPa8+Y+d9Ab28HbSsx2K22zOVwNxn5BkMNqhqjUx2+nHbpYyXCUy1Ly3s0+fxg04eI6JZ59uCNnHDpi8qDIpW3cQGu6oGU4m3ujMFKShCHaNfPlz1cgCOkILSNvvOSH8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YShw9RC4QmtSGtoieAAUyMXwguagkkZty2+yjm8acN3CqEOqkOSfjiXAbn9PuHXwciskWz1FRwCVWh9aD7yZztt5JVtX3Mo2/tt/iM+i9lysQ3DO/cVDUHhsaXktDGize7P0a7aQd+I2nyKWxKg+3KstbYDm8FzU1trji9bp/LI= Received: by 10.114.80.4 with SMTP id d4mr3100237wab.1196097836023; Mon, 26 Nov 2007 09:23:56 -0800 (PST) Received: by 10.114.167.18 with HTTP; Mon, 26 Nov 2007 09:23:55 -0800 (PST) Message-ID: <939ad9a80711260923o2bb7e9b3ua584f85d76a74315@mail.gmail.com> Date: Mon, 26 Nov 2007 17:23:55 +0000 From: "Yangcheng Huang" To: "Yasunori Owada" , manet@ietf.org Subject: Re: [manet] Packet looping issue in MANET routing protocol In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1716228e0711260041n142c1ddbxf6c8ba90f6b4c3c2@mail.gmail.com> <1716228e0711260303w233a590by4062c4ed1fbf2667@mail.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: "Dearlove, Christopher \(UK\)" X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yangchenghuang@ieee.org List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org The results are surprising to me. Just had a quick look at the source code. From the following functions of LLN, ARP entries are used to determine whether the link is valid or not. ks2k_proc_lln proc_link_layer_notification /////// if(ifp->now[i].diff > LLN_THRESHOLD){ proc_link_layer_notification(olsr, ifp, ip); check =3D 1; } The OLSR main program polls the system's ARP cache periodically to get an up-to-date ARP table. olsr_scheduler(void *ptr) ... while(tmp_if) { get_arp_entry(); //dump_arp_entry(); ks2k_proc_lln(olsr, tmp_if);=20 ... So the problems might be caused by the ARP timeout value. By a simple googling, the default ARP time out value for redhat seems to be 60s, which will bring inconsistency when the node is in mobility. Please feel free to correct me. On Nov 26, 2007 12:20 PM, Dearlove, Christopher (UK) wrote: > If you implement LLNs correctly, I do not see why > LLNs make a significant difference to the issue as > you suggest. Local changes occur on a short timescale > whether due to LLNs or other mechanisms. You do of > course have to have timescales appropriate to your > mobility. > > As for sending TCs when things change, that also is > a SHOULD. Yes, it increases load, but the minimum > intervals in OLSRv2 (which we first implemented in > OLSRv1, see my paper at the first OLSR Interop) manage > that quite successfully in our experience. > > For these and other reasons I therefore find these > results surprising, and not in keeping with results > we have seen in simulations (and reality, albeit in > smaller networks). > > > -----Original Message----- > From: yowada@gmail.com [mailto:yowada@gmail.com] On Behalf Of Yasunori > Owada > Sent: 26 November 2007 11:03 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org > Subject: Re: [manet] Packet looping issue in MANET routing protocol > > > *** 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. > > > Hello Chris, > > Thank you for comment. > We thought the same thing and we'd implemented instant HELLO > generation mechanisms as you mentioned into our OLSRv2 implementation. > But that could prevent only few ping-pong loops, and most loops had > remained. > This is because these loops are formed as a result of the Topology Set > information inconsistency, and the largest number of loops are caused > from this inconsistency. > TC message generation interval is longer than HELL's one, and TC > message is usually only forwarded by the MPR. Considering the > situation that link state changes frequently, MPR selector will be > changed frequently and some TC message may not be forwarded to entire > MANET node correctly. In addition, TC information inconsistency may be > caused by Topology Set timer expiration. > Instant TC message generation is one possibility to prevent this > looping issue, but it incleases control message overhead considerably. > So current solution is just discarding the looping packet. > > -- > Assistant Professor of Natural Hazard and Disaster Recovery, Niigata > University, Japan. > Yasunori Owada > TEL: +81-25-262-7429 > > > 2007/11/26, Dearlove, Christopher (UK) : > > > > That Internet Draft says, in part > > > > The routing protocol may then act on the given LLN trigger, usually > > simply by removing a record of link from its Information Bases that > > store necessary information for routing and neighbor discovery to > be > > able to calculate and update routing table. > > > > That is not what either OLSR or OLSRv2 say to do. You do not simply > > remove the entry from the information bases, you mark the entry in > > the information bases, change its state, and report that state in > > your HELLO messages, thus ensuring consistency. Furthermore they > > both indicate that such a change may (actually, should, subject to > > minimum message intervals in OLSRv2 - and some implementations of > > OLSR) cause you to sent such a HELLO message early. > > > > If implemented as described, you will have problems. But that would > > be down to a poor implementation, not a fundamental problem with the > > protocol. > > > > > > ******************************************************************** > > 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 mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 26 21:44:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqQd-0002P5-GI; Mon, 26 Nov 2007 21:44:03 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IwqQb-0002ND-PL for manet-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 21:44:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqQb-0002LU-Ei for manet@ietf.org; Mon, 26 Nov 2007 21:44:01 -0500 Received: from wa-out-1112.google.com ([209.85.146.178]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwqQY-0007WE-Of for manet@ietf.org; Mon, 26 Nov 2007 21:44:01 -0500 Received: by wa-out-1112.google.com with SMTP id k40so1516456wah for ; Mon, 26 Nov 2007 18:43:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=xPtE7zw1Zck9fTxOw/e6DMKQn0RLHB/R0dlPliGdHxU=; b=TBcpLYbeUrCvMtwWBqeaiQYzbwYofB+vfzRMJBjpZKtP1V8fjtlklVM0+8JQjDBLwkxXz5U/tDH8bfzHqxcnwKaPnspAonqTxlMr6p0HNKAQQTIlr5AznCJzZrrEuGX4eU6q6Hf4oXG9fNRLqLvvw5yRAUimD5pGkLo8PRG2Jio= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=GE4FIBgNGmA+H0l9aYdYF8Cns3vt7Noi5NcH6SvVwdfIxEMjlZazGR8Q4eQlhxngNfm7YEXAodMdZ/d+9sEi/8U+rRue0aJFa0P86CWiIW2XMyN7TvwZSFyQCK2i33JH5+Y4rjOqNu3UcRUfJ0FY69h+j+GUkajKcz9KWl+In6U= Received: by 10.114.156.1 with SMTP id d1mr290889wae.1196131438049; Mon, 26 Nov 2007 18:43:58 -0800 (PST) Received: by 10.114.112.5 with HTTP; Mon, 26 Nov 2007 18:43:57 -0800 (PST) Message-ID: <1716228e0711261843x5e9a489wfd92b8d9d6d07d9a@mail.gmail.com> Date: Tue, 27 Nov 2007 11:43:57 +0900 From: "Yasunori Owada" To: "Dearlove, Christopher (UK)" Subject: Re: [manet] Packet looping issue in MANET routing protocol In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1716228e0711260041n142c1ddbxf6c8ba90f6b4c3c2@mail.gmail.com> <1716228e0711260303w233a590by4062c4ed1fbf2667@mail.gmail.com> X-Google-Sender-Auth: de58b32604cb7da0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Chris, We created the packet tracer in QualNet simulator and find this issue. Same loop could be found in OLSR without using LLN. LLN just accelerate this looping issue, and the interesting things, much loop is formed when nodes have no mobility. In the simulation result, LLN surely improve the performance in terms of packet delivery ratio. But it generate few loops as the side-effect. Usually, these looping paths are updated and resolved within a short period, but in the case that heavy traffic are generated such as video streaming, many unicast packets may go into the loop and keep forwarding until TTL expires (Usually 64 is used as default TTL value in most operating system, so ONE packet is once enter the loop, it is forwarded 63 times!). These packets only waste the radio resources and should be discarded. -- Assistant Professor of Natural Hazard and Disaster Recovery, Niigata University, Japan. Yasunori Owada TEL: +81-25-262-7429 2007/11/26, Dearlove, Christopher (UK) : > If you implement LLNs correctly, I do not see why > LLNs make a significant difference to the issue as > you suggest. Local changes occur on a short timescale > whether due to LLNs or other mechanisms. You do of > course have to have timescales appropriate to your > mobility. > > As for sending TCs when things change, that also is > a SHOULD. Yes, it increases load, but the minimum > intervals in OLSRv2 (which we first implemented in > OLSRv1, see my paper at the first OLSR Interop) manage > that quite successfully in our experience. > > For these and other reasons I therefore find these > results surprising, and not in keeping with results > we have seen in simulations (and reality, albeit in > smaller networks). > > > -----Original Message----- > From: yowada@gmail.com [mailto:yowada@gmail.com] On Behalf Of Yasunori > Owada > Sent: 26 November 2007 11:03 > To: Dearlove, Christopher (UK) > Cc: manet@ietf.org > Subject: Re: [manet] Packet looping issue in MANET routing protocol > > > *** 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. > > Hello Chris, > > Thank you for comment. > We thought the same thing and we'd implemented instant HELLO > generation mechanisms as you mentioned into our OLSRv2 implementation. > But that could prevent only few ping-pong loops, and most loops had > remained. > This is because these loops are formed as a result of the Topology Set > information inconsistency, and the largest number of loops are caused > from this inconsistency. > TC message generation interval is longer than HELL's one, and TC > message is usually only forwarded by the MPR. Considering the > situation that link state changes frequently, MPR selector will be > changed frequently and some TC message may not be forwarded to entire > MANET node correctly. In addition, TC information inconsistency may be > caused by Topology Set timer expiration. > Instant TC message generation is one possibility to prevent this > looping issue, but it incleases control message overhead considerably. > So current solution is just discarding the looping packet. > > -- > Assistant Professor of Natural Hazard and Disaster Recovery, Niigata > University, Japan. > Yasunori Owada > TEL: +81-25-262-7429 > > > 2007/11/26, Dearlove, Christopher (UK) : > > > > That Internet Draft says, in part > > > > The routing protocol may then act on the given LLN trigger, usually > > simply by removing a record of link from its Information Bases that > > store necessary information for routing and neighbor discovery to > be > > able to calculate and update routing table. > > > > That is not what either OLSR or OLSRv2 say to do. You do not simply > > remove the entry from the information bases, you mark the entry in > > the information bases, change its state, and report that state in > > your HELLO messages, thus ensuring consistency. Furthermore they > > both indicate that such a change may (actually, should, subject to > > minimum message intervals in OLSRv2 - and some implementations of > > OLSR) cause you to sent such a HELLO message early. > > > > If implemented as described, you will have problems. But that would > > be down to a poor implementation, not a fundamental problem with the > > protocol. > > > > > > ******************************************************************** > > 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Mon Nov 26 22:10:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwqq2-0000sb-OZ; Mon, 26 Nov 2007 22:10:18 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iwqq1-0000r6-AL for manet-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 22:10:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iwqq0-0000qx-W3 for manet@ietf.org; Mon, 26 Nov 2007 22:10:16 -0500 Received: from wa-out-1112.google.com ([209.85.146.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iwqpx-0002F1-BP for manet@ietf.org; Mon, 26 Nov 2007 22:10:16 -0500 Received: by wa-out-1112.google.com with SMTP id k40so1527589wah for ; Mon, 26 Nov 2007 19:10:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=NvHzjjlQ5BjC/NcuhslYr4iN8cNryLIoG+bskChO6e4=; b=nLHH+BrPD2WiR1f45CQJ3ocngkyCt1DJbi9G1YXu3codKNUL8dQLhoUrHupqGFE/sQ+kjXz6yJ010HoDe5Z+/VjRxI3HzHhH/6k0U9UyXDXe7iXbZSvLsh5RbHPG6PbdYh06O8vaqyosuq5oHC3Q+au/jpqiLdT9xpS2EUnoPws= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=WWOPpz3d8uD7chDS6mAG2cbxGk94HRPvo4ipphBw0vAQWZBmIgloRB3aFQBKRfNTBPoBr67zNVAkN48Cy3NE+A1FNMhm5fF1St98pt86O0683fEcE2I8O9lYnrEtg3iBwjFRNSk1su7OL5D+YBsJd1iDee1rpyWDB5sscbDmQZA= Received: by 10.114.94.1 with SMTP id r1mr79631wab.1196133012675; Mon, 26 Nov 2007 19:10:12 -0800 (PST) Received: by 10.114.112.5 with HTTP; Mon, 26 Nov 2007 19:10:12 -0800 (PST) Message-ID: <1716228e0711261910w1481a852nc3fa2685c215709f@mail.gmail.com> Date: Tue, 27 Nov 2007 12:10:12 +0900 From: "Yasunori Owada" To: YangCheng.Huang@cs.ucl.ac.uk Subject: Re: [manet] Packet looping issue in MANET routing protocol In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1716228e0711260041n142c1ddbxf6c8ba90f6b4c3c2@mail.gmail.com> <1716228e0711260303w233a590by4062c4ed1fbf2667@mail.gmail.com> X-Google-Sender-Auth: 9cc4724dd2e079cc X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hello Yangcheng, Thank you for reviewing our implementation source code. To implement LLN, we modified Wireless LAN device driver (for Keystream Chipset wireless LAN card) to count the number of unicast frame retransmission timeout in each destination MAC address. OLSRv2 Linux daemon poll the WLAN driver every polling interval and get the list of MAC address and retransmission timeout count. When the retransmission timeout count difference between previous one and current one is larger than the LLN_THRESHOLD, then the link to the destination MAC address assumes to be disconnected. ARP cash is used for resolving the destination MAC address to IP address. If address resolution from MAC address to IP address failed, LLN procedure doesn't happen. Unfortunately, current LLN implementation only works on the Keystream Wireless LAN card with modified wireless LAN device driver. If someone would implement LLN function that works on ar5k chipset wireless LAN card with MAD-WiFi driver, it's a great help for us. Thanks, -- Assistant Professor of Natural Hazard and Disaster Recovery, Niigata University, Japan. Yasunori Owada TEL: +81-25-262-7429 26 Nov 2007 17:07:14 +0000, Yangcheng Huang : > The results are surprising to me. Just had a quick look at the source code. > From the following functions of LLN, ARP entries are used to determine > whether the link is valid or not. > > ks2k_proc_lln > proc_link_layer_notification > > /////// > if(ifp->now[i].diff > LLN_THRESHOLD){ > proc_link_layer_notification(olsr, ifp, ip); > check = 1; > } > > The OLSR main program polls the system's ARP cache periodically to get an > up-to-date ARP table. > > olsr_scheduler(void *ptr) > ... > while(tmp_if) { > get_arp_entry(); > //dump_arp_entry(); > ks2k_proc_lln(olsr, tmp_if); > ... > > So the problems might be caused by the ARP timeout value. By a simple > googling, the default ARP time out value for redhat seems to be 60s, which > brings inconsistency when the node is in mobility. > > > > > On Nov 26 2007, Dearlove, Christopher (UK) wrote: > > >If you implement LLNs correctly, I do not see why > >LLNs make a significant difference to the issue as > >you suggest. Local changes occur on a short timescale > >whether due to LLNs or other mechanisms. You do of > >course have to have timescales appropriate to your > >mobility. > > > >As for sending TCs when things change, that also is > >a SHOULD. Yes, it increases load, but the minimum > >intervals in OLSRv2 (which we first implemented in > >OLSRv1, see my paper at the first OLSR Interop) manage > >that quite successfully in our experience. > > > >For these and other reasons I therefore find these > >results surprising, and not in keeping with results > >we have seen in simulations (and reality, albeit in > >smaller networks). > > > > > >-----Original Message----- > >From: yowada@gmail.com [mailto:yowada@gmail.com] On Behalf Of Yasunori > >Owada > >Sent: 26 November 2007 11:03 > >To: Dearlove, Christopher (UK) > >Cc: manet@ietf.org > >Subject: Re: [manet] Packet looping issue in MANET routing protocol > > > > > > *** 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. > > > >Hello Chris, > > > >Thank you for comment. > >We thought the same thing and we'd implemented instant HELLO > >generation mechanisms as you mentioned into our OLSRv2 implementation. > >But that could prevent only few ping-pong loops, and most loops had > >remained. > >This is because these loops are formed as a result of the Topology Set > >information inconsistency, and the largest number of loops are caused > >from this inconsistency. > >TC message generation interval is longer than HELL's one, and TC > >message is usually only forwarded by the MPR. Considering the > >situation that link state changes frequently, MPR selector will be > >changed frequently and some TC message may not be forwarded to entire > >MANET node correctly. In addition, TC information inconsistency may be > >caused by Topology Set timer expiration. > >Instant TC message generation is one possibility to prevent this > >looping issue, but it incleases control message overhead considerably. > >So current solution is just discarding the looping packet. > > > > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 27 03:09:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwvVI-0003Ks-PQ; Tue, 27 Nov 2007 03:09:12 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IwvVG-0003Ke-T0 for manet-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 03:09:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwvVG-0003KW-JL for manet@ietf.org; Tue, 27 Nov 2007 03:09:10 -0500 Received: from hpsmtp-eml20.kpnxchange.com ([213.75.38.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwvVC-0000BI-Na for manet@ietf.org; Tue, 27 Nov 2007 03:09:10 -0500 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 09:09:05 +0100 Received: from M90Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 09:09:05 +0100 From: "Teco Boot" To: "'Yasunori Owada'" , "'Dearlove, Christopher \(UK\)'" References: <1716228e0711260041n142c1ddbxf6c8ba90f6b4c3c2@mail.gmail.com> <1716228e0711260303w233a590by4062c4ed1fbf2667@mail.gmail.com> <1716228e0711261843x5e9a489wfd92b8d9d6d07d9a@mail.gmail.com> In-Reply-To: <1716228e0711261843x5e9a489wfd92b8d9d6d07d9a@mail.gmail.com> Subject: RE: [manet] Packet looping issue in MANET routing protocol Date: Tue, 27 Nov 2007 09:09:04 +0100 Message-ID: <001b01c830cc$c70319f0$55094dd0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acgwn+6JcKvln6/vTNCSzbWNLZENJAAKbM6Q Content-Language: nl X-OriginalArrivalTime: 27 Nov 2007 08:09:05.0181 (UTC) FILETIME=[C718C4D0:01C830CC] X-Spam-Score: -1.0 (-) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi, I am interested in the relation between user traffic load and MANET micro loops. I think in a heavily loaded MANET (many TCP flows), with some bad links, probability on loops is increased and loop duration is typically longer. I am interested in simulation results on this. I am also interested in results when adding metrics. I think it can help preventing loops, when updating metrics smoothly. The effect could be highly dependent on the metrics update mechanism. And I am also interested in effects on fish-eye routing, i.e. sending TC with different hoplimits. I think long-lived loops could occur. I support putting effort on loop prevention, loop detection and looped packet elimination in MANET WG. Teco. > -----Oorspronkelijk bericht----- > Van: Yasunori Owada [mailto:yowada@net.ie.niigata-u.ac.jp] > Verzonden: dinsdag 27 november 2007 3:44 > Aan: Dearlove, Christopher (UK) > CC: manet@ietf.org > Onderwerp: Re: [manet] Packet looping issue in MANET routing protocol > > Hello Chris, > > We created the packet tracer in QualNet simulator and find this issue. > Same loop could be found in OLSR without using LLN. LLN just > accelerate this looping issue, and the interesting things, much loop > is formed when nodes have no mobility. > In the simulation result, LLN surely improve the performance in terms > of packet delivery ratio. But it generate few loops as the > side-effect. Usually, these looping paths are updated and resolved > within a short period, but in the case that heavy traffic are > generated such as video streaming, many unicast packets may go into > the loop and keep forwarding until TTL expires (Usually 64 is used as > default TTL value in most operating system, so ONE packet is once > enter the loop, it is forwarded 63 times!). These packets only waste > the radio resources and should be discarded. > > > -- > Assistant Professor of Natural Hazard and Disaster Recovery, Niigata > University, Japan. > Yasunori Owada > TEL: +81-25-262-7429 > > > 2007/11/26, Dearlove, Christopher (UK) : > > If you implement LLNs correctly, I do not see why > > LLNs make a significant difference to the issue as > > you suggest. Local changes occur on a short timescale > > whether due to LLNs or other mechanisms. You do of > > course have to have timescales appropriate to your > > mobility. > > > > As for sending TCs when things change, that also is > > a SHOULD. Yes, it increases load, but the minimum > > intervals in OLSRv2 (which we first implemented in > > OLSRv1, see my paper at the first OLSR Interop) manage > > that quite successfully in our experience. > > > > For these and other reasons I therefore find these > > results surprising, and not in keeping with results > > we have seen in simulations (and reality, albeit in > > smaller networks). > > > > > > -----Original Message----- > > From: yowada@gmail.com [mailto:yowada@gmail.com] On Behalf Of > Yasunori > > Owada > > Sent: 26 November 2007 11:03 > > To: Dearlove, Christopher (UK) > > Cc: manet@ietf.org > > Subject: Re: [manet] Packet looping issue in MANET routing protocol > > > > > > *** 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. > > > > Hello Chris, > > > > Thank you for comment. > > We thought the same thing and we'd implemented instant HELLO > > generation mechanisms as you mentioned into our OLSRv2 > implementation. > > But that could prevent only few ping-pong loops, and most loops had > > remained. > > This is because these loops are formed as a result of the Topology > Set > > information inconsistency, and the largest number of loops are caused > > from this inconsistency. > > TC message generation interval is longer than HELL's one, and TC > > message is usually only forwarded by the MPR. Considering the > > situation that link state changes frequently, MPR selector will be > > changed frequently and some TC message may not be forwarded to entire > > MANET node correctly. In addition, TC information inconsistency may > be > > caused by Topology Set timer expiration. > > Instant TC message generation is one possibility to prevent this > > looping issue, but it incleases control message overhead > considerably. > > So current solution is just discarding the looping packet. > > > > -- > > Assistant Professor of Natural Hazard and Disaster Recovery, Niigata > > University, Japan. > > Yasunori Owada > > TEL: +81-25-262-7429 > > > > > > 2007/11/26, Dearlove, Christopher (UK) > : > > > > > > That Internet Draft says, in part > > > > > > The routing protocol may then act on the given LLN trigger, > usually > > > simply by removing a record of link from its Information Bases > that > > > store necessary information for routing and neighbor discovery > to > > be > > > able to calculate and update routing table. > > > > > > That is not what either OLSR or OLSRv2 say to do. You do not simply > > > remove the entry from the information bases, you mark the entry in > > > the information bases, change its state, and report that state in > > > your HELLO messages, thus ensuring consistency. Furthermore they > > > both indicate that such a change may (actually, should, subject to > > > minimum message intervals in OLSRv2 - and some implementations of > > > OLSR) cause you to sent such a HELLO message early. > > > > > > If implemented as described, you will have problems. But that would > > > be down to a poor implementation, not a fundamental problem with > the > > > protocol. > > > > > > > > > > ******************************************************************** > > > 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 mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 27 19:01:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxANA-0007um-Ja; Tue, 27 Nov 2007 19:01:48 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IxAN8-0007uP-IS for manet-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 19:01:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxAN8-0007uE-7h for manet@ietf.org; Tue, 27 Nov 2007 19:01:46 -0500 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxAN7-0001m2-Ru for manet@ietf.org; Tue, 27 Nov 2007 19:01:46 -0500 Received: from 89.124.240.169 by bells.cs.ucl.ac.uk with Internet SMTP id ; Wed, 28 Nov 2007 00:01:37 +0000 Message-ID: <474CAFE2.5050306@cs.ucl.ac.uk> Date: Wed, 28 Nov 2007 00:01:38 +0000 From: Yang Cheng Huang User-Agent: Thunderbird 2.0.0.6 (X11/20070728) MIME-Version: 1.0 To: Yasunori Owada Subject: Re: [manet] Packet looping issue in MANET routing protocol References: <1716228e0711260041n142c1ddbxf6c8ba90f6b4c3c2@mail.gmail.com> <1716228e0711260303w233a590by4062c4ed1fbf2667@mail.gmail.com> <1716228e0711261910w1481a852nc3fa2685c215709f@mail.gmail.com> In-Reply-To: <1716228e0711261910w1481a852nc3fa2685c215709f@mail.gmail.com> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: y.huang@cs.ucl.ac.uk List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org > When the > retransmission timeout count difference between previous one and > current one is larger than the LLN_THRESHOLD, then the link to the > destination MAC address assumes to be disconnected. > Any proof/mechanisms behind such a method? Why the DIFFERENCE between the number of timeouts can indicate link status? > ARP cash is used > for resolving the destination MAC address to IP address. If address > resolution from MAC address to IP address failed, LLN procedure > doesn't happen. My guess is the OLSR implementation doesn't make changes in the linux ARP code. Each arp entry lasts 60s before timed-out. So the address resolution would succeed even if the neighboring node moves away. The data packets would get dropped if sent to such neighbors. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 27 21:35:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxCmF-0003wT-MU; Tue, 27 Nov 2007 21:35:51 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IxCmD-0003wM-Sa for manet-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 21:35:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxCmD-0003wE-J4 for manet@ietf.org; Tue, 27 Nov 2007 21:35:49 -0500 Received: from nz-out-0506.google.com ([64.233.162.231]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxCmD-0005Ub-7J for manet@ietf.org; Tue, 27 Nov 2007 21:35:49 -0500 Received: by nz-out-0506.google.com with SMTP id n1so936509nzf for ; Tue, 27 Nov 2007 18:35:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=8YjO8Y4SadUNsJtS/uhWJJgzD/NOgywp4yFUfI6g9tU=; b=VVCK959Xt6wLW+1JCe1ect9bjc37yFoD8FxQ2nG5cCGi6vyWxCBiHC/Df1jTY4PT9h6abrsGzFqh/AhGoZip7PMFnzRWZV7eyEiOBsm4OTQPizV6AcU3ZgzLThz7XR8oOuXprrXT00Ycgy1kx3K3YnUx132r5VxN9P4mpsHbmhY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=CV/RkzNmv4j0RyzCovOx0axy3UAOL6z2bKXfzbM5guBP2TjcjQ18zolVM+0dp6Xyyr30jf3jDX/RQHNYDL2AolK5fWcgacR7rhaeuhXyZKh8kwI+4y5Pnx+7B4lU/QzW1Cbwy3phWyznKYiL8aZ5pwU66883Mf13IdifACcw56w= Received: by 10.114.66.2 with SMTP id o2mr461098waa.1196217347717; Tue, 27 Nov 2007 18:35:47 -0800 (PST) Received: by 10.114.112.5 with HTTP; Tue, 27 Nov 2007 18:35:47 -0800 (PST) Message-ID: <1716228e0711271835o70f06a4creccbf0d95e71b2e1@mail.gmail.com> Date: Wed, 28 Nov 2007 11:35:47 +0900 From: "Yasunori Owada" To: y.huang@cs.ucl.ac.uk Subject: Re: [manet] Packet looping issue in MANET routing protocol In-Reply-To: <474CAFE2.5050306@cs.ucl.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1716228e0711260041n142c1ddbxf6c8ba90f6b4c3c2@mail.gmail.com> <1716228e0711260303w233a590by4062c4ed1fbf2667@mail.gmail.com> <1716228e0711261910w1481a852nc3fa2685c215709f@mail.gmail.com> <474CAFE2.5050306@cs.ucl.ac.uk> X-Google-Sender-Auth: a3c79f55984f7d38 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Comments inline. > > > When the > > retransmission timeout count difference between previous one and > > current one is larger than the LLN_THRESHOLD, then the link to the > > destination MAC address assumes to be disconnected. > > > Any proof/mechanisms behind such a method? Why the DIFFERENCE between > the number of timeouts can indicate link status? First, we defined MAC frame retry-out as link disconnection because IEEE802.11 ad-hoc mode doesn't define any link connection consept. Then we implemented LLN based on this link sensing method in QualNet simulator and evaluated its performance, and confirm that the packet delivery performance improves well. To confirm these results in the real world experiments, we also implement this function to the wireless LAN device driver. But too many LLN occures in the real world experiments because of the fading and shadowing. So that we also added the LLN_THRESHOLD to reduce the LLN occurrence. > > > ARP cash is used > > for resolving the destination MAC address to IP address. If address > > resolution from MAC address to IP address failed, LLN procedure > > doesn't happen. > My guess is the OLSR implementation doesn't make changes in the linux > ARP code. Each arp entry lasts 60s before timed-out. So the address > resolution would succeed even if the neighboring node moves away. The > data packets would get dropped if sent to such neighbors. Our LLN detects such data pcakets loss in each nexthop. The MAC frame retry-out means the data packet loss as you said. This mechanism don't need any change to ARP code because this mechanism only uses ARP cache entry to resolve reverse address resolution from MAC address to IP address. -- Assistant Professor of Natural Hazard and Disaster Recovery, Niigata University, Japan. Yasunori Owada TEL: +81-25-262-7429 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Tue Nov 27 23:58:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxF0N-0005rr-Jr; Tue, 27 Nov 2007 23:58:35 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IxF0L-0005iJ-QL for manet-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 23:58:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxF0L-0005iA-Fk for manet@ietf.org; Tue, 27 Nov 2007 23:58:33 -0500 Received: from hermes.eit.lth.se ([130.235.201.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxF0K-0000m4-13 for manet@ietf.org; Tue, 27 Nov 2007 23:58:33 -0500 Received: from [130.235.200.67] (130.235.200.67) by hermes.eit.lth.se (130.235.201.3) with Microsoft SMTP Server (TLS) id 8.0.751.0; Wed, 28 Nov 2007 05:58:28 +0100 Message-ID: <474CF572.2080603@eit.lth.se> Date: Tue, 27 Nov 2007 20:58:26 -0800 From: Ali Hamidian User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: MANET References: <474C6566.1060908@eit.lth.se> In-Reply-To: <474C6566.1060908@eit.lth.se> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [manet] WMM in ad hoc mode? X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi, Does anyone know about any wireless adapter (USB/cardbus) that supports WMM (wireless multimedia; 802.11e EDCA) in ad hoc mode? I've tried many adapters but so far WMM hasn't worked in ad hoc mode in any of them. Thanks Ali _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 28 10:10:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOY9-0003Fr-Fl; Wed, 28 Nov 2007 10:10:05 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IxOY6-000399-Sf for manet-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 10:10:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOY6-000364-CA for manet@ietf.org; Wed, 28 Nov 2007 10:10:02 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxOY6-0000Bt-02 for manet@ietf.org; Wed, 28 Nov 2007 10:10:02 -0500 Received: by ug-out-1314.google.com with SMTP id u2so1712997uge for ; Wed, 28 Nov 2007 07:10:01 -0800 (PST) Received: by 10.78.100.1 with SMTP id x1mr5643807hub.1196262600877; Wed, 28 Nov 2007 07:10:00 -0800 (PST) Received: by 10.78.170.19 with HTTP; Wed, 28 Nov 2007 07:10:00 -0800 (PST) Message-ID: <25c114b90711280710w2a950fadq62c65dad0261de3c@mail.gmail.com> Date: Wed, 28 Nov 2007 16:10:00 +0100 From: "Ulrich Herberg" To: manet@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 8c5c07177a1774af X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [manet] 802.11 PCI card in ad-hoc demo mode X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi, I need a 802.11 PCI card for a MANET testbed. Can anyone of you recommend me a decent (but not overpriced) adapter which runs smoothly under Linux, and is capable of running in monitor and pseudo -IBSS (i.e. ad hoc demo) mode? It should also be able to run as a software access point. I heard that the Atheros chipset might be a good choice, but I am not sure that every card equipped with that chipset has all the above-mentioned capabilities. Thanks! Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 28 10:26:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOoK-0005y3-KG; Wed, 28 Nov 2007 10:26:48 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IxOoI-0005wB-Ui for manet-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 10:26:46 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxOoI-0005vl-KX for manet@ietf.org; Wed, 28 Nov 2007 10:26:46 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxOoH-0003pU-Ts for manet@ietf.org; Wed, 28 Nov 2007 10:26:46 -0500 Received: (qmail invoked by alias); 28 Nov 2007 15:26:44 -0000 Received: from 153.83-43-196.Admin.morogoro.ttcldata.net (EHLO localhost) [196.43.83.153] by mail.gmx.net (mp032) with SMTP; 28 Nov 2007 16:26:44 +0100 X-Authenticated: #2746672 X-Provags-ID: V01U2FsdGVkX18dNSMuI/8dwQHVK2GedDbRnMJCNurlGpDCNLS+ng pdDDh2Dli7Gplh From: elektra Organization: kein logo To: manet@ietf.org Subject: Re: [manet] 802.11 PCI card in ad-hoc demo mode Date: Wed, 28 Nov 2007 18:26:25 +0300 User-Agent: KMail/1.9.6 References: <25c114b90711280710w2a950fadq62c65dad0261de3c@mail.gmail.com> In-Reply-To: <25c114b90711280710w2a950fadq62c65dad0261de3c@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711281826.25648.onelektra@gmx.net> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi - currently Atheros is the best choice. If you see Super-G and XR (Extended Range) advertised on the package it is a Atheros card. Make sure you are using a recent version of the Madwifi driver. cu elektra > I need a 802.11 PCI card for a MANET testbed. Can anyone of you > recommend me a decent (but not overpriced) adapter which runs smoothly > under Linux, and is capable of running in monitor and pseudo -IBSS > (i.e. ad hoc demo) mode? It should also be able to run as a software > access point. > > I heard that the Atheros chipset might be a good choice, but I am not > sure that every card equipped with that chipset has all the > above-mentioned capabilities. > > Thanks! > Ulrich > > > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 28 14:03:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSCN-00028I-7z; Wed, 28 Nov 2007 14:03:51 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IxSCM-00028B-Eh for manet-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 14:03:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxSCM-000282-5A for manet@ietf.org; Wed, 28 Nov 2007 14:03:50 -0500 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxSCK-00033K-QN for manet@ietf.org; Wed, 28 Nov 2007 14:03:50 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1309264nfb for ; Wed, 28 Nov 2007 11:03:47 -0800 (PST) Received: by 10.78.147.6 with SMTP id u6mr5974182hud.1196276626902; Wed, 28 Nov 2007 11:03:46 -0800 (PST) Received: by 10.78.170.19 with HTTP; Wed, 28 Nov 2007 11:03:46 -0800 (PST) Message-ID: <25c114b90711281103y38230af3ked376353e5abf671@mail.gmail.com> Date: Wed, 28 Nov 2007 20:03:46 +0100 From: "Ulrich Herberg" To: elektra Subject: Re: [manet] 802.11 PCI card in ad-hoc demo mode In-Reply-To: <200711281826.25648.onelektra@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <25c114b90711280710w2a950fadq62c65dad0261de3c@mail.gmail.com> <200711281826.25648.onelektra@gmx.net> X-Google-Sender-Auth: 12a616d950952dd3 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi Elektra, thanks for your reply. Are all network adapters equipped with an Atheros chipset equal in terms of functionality? I mean, can I buy any Atheros card and still count on the ad-hoc demo mode? Regards, Ulrich On 11/28/07, elektra wrote: > Hi - > > currently Atheros is the best choice. If you see Super-G and XR (Extended > Range) advertised on the package it is a Atheros card. > > Make sure you are using a recent version of the Madwifi driver. > > cu elektra > > > I need a 802.11 PCI card for a MANET testbed. Can anyone of you > > recommend me a decent (but not overpriced) adapter which runs smoothly > > under Linux, and is capable of running in monitor and pseudo -IBSS > > (i.e. ad hoc demo) mode? It should also be able to run as a software > > access point. > > > > I heard that the Atheros chipset might be a good choice, but I am not > > sure that every card equipped with that chipset has all the > > above-mentioned capabilities. > > > > Thanks! > > Ulrich _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 28 19:03:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWsP-0006ea-1c; Wed, 28 Nov 2007 19:03:33 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IxWsN-0006eV-PI for manet-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 19:03:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWsN-0006eN-Fc for manet@ietf.org; Wed, 28 Nov 2007 19:03:31 -0500 Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxWsN-0002CP-87 for manet@ietf.org; Wed, 28 Nov 2007 19:03:31 -0500 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 045EE5761E; Wed, 28 Nov 2007 19:03:31 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 28 Nov 2007 19:03:31 -0500 X-Sasl-enc: vG7KtZIo5f10Qya4wt16WaMf1ZR1lRcUGsHcSUETUrVe 1196294610 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 62A283287; Wed, 28 Nov 2007 19:03:30 -0500 (EST) Message-ID: <474E01D1.8050707@incunabulum.net> Date: Thu, 29 Nov 2007 00:03:29 +0000 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: y.huang@cs.ucl.ac.uk Subject: Re: [manet] Packet looping issue in MANET routing protocol References: <1716228e0711260041n142c1ddbxf6c8ba90f6b4c3c2@mail.gmail.com> <1716228e0711260303w233a590by4062c4ed1fbf2667@mail.gmail.com> <1716228e0711261910w1481a852nc3fa2685c215709f@mail.gmail.com> <474CAFE2.5050306@cs.ucl.ac.uk> In-Reply-To: <474CAFE2.5050306@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Yang Cheng Huang wrote: > My guess is the OLSR implementation doesn't make changes in the linux > ARP code. Each arp entry lasts 60s before timed-out. So the address > resolution would succeed even if the neighboring node moves away. The > data packets would get dropped if sent to such neighbors. > This is largely expected -- layer 3 routing protocols should not be making changes to layer 2 state. I'm thinking both ARP and IGMP should be optional in the kernel interface MIB for interfaces designated for MANET operation -- as they are of limited utility in the MANET scenario. Whilst ARP could be used with MANET, and indeed currently is, most of the MANET protocols I've seen maintain host routes anyway, plumbing them into the Layer 3 FIB even when they aren't strictly needed or are already covered by interface routes, in the absence of any intermediary RIB. Layer 2 mapping information could therefore be maintained e.g. using the HELLO packets which are part of OLSRv1, or as part of NHDP in OLSRv2 and DYMO. regards, BMS _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Wed Nov 28 19:16:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxX5B-00050s-Lv; Wed, 28 Nov 2007 19:16:45 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IxX5A-00050c-0U for manet-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 19:16:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxX59-00050U-Mz for manet@ietf.org; Wed, 28 Nov 2007 19:16:43 -0500 Received: from out1.smtp.messagingengine.com ([66.111.4.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxX59-0002eL-Fb for manet@ietf.org; Wed, 28 Nov 2007 19:16:43 -0500 Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 65D3C57EF6; Wed, 28 Nov 2007 19:16:43 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Wed, 28 Nov 2007 19:16:43 -0500 X-Sasl-enc: oGPRYAT5Flv3DtTbb0xhQQ+By+xRbXf440kXx78MKOEf 1196295403 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id CFC1320F78; Wed, 28 Nov 2007 19:16:42 -0500 (EST) Message-ID: <474E04E9.4070506@incunabulum.net> Date: Thu, 29 Nov 2007 00:16:41 +0000 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.6 (X11/20070928) MIME-Version: 1.0 To: macker@itd.nrl.navy.mil References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: manet@ietf.org Subject: [manet] Comments on draft-ietf-manet-smf-06 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I am a bit disappointed that the current I-D for MANET SMF has no provision for the encapsulation of MANET SMF datagrams in IPv4. My points: * ip_id is only 16 bits wide, making its usefulness limited in large MANET topologies. * Both BSD and Linux may be configured to randomize the ip_id field as a defensive measure against IP host fingerprinting. * Choosing ip_id as a tag for the histogram based duplicate packet detection requires that NAT routers on the path examine ip_id, in addition to being examined by any software multicast forwarding plane implementation. * Encapsulation considerably simplifies implementation within existing software multicast forwarding planes, again, re: BSD and Linux. * The overhead of demux and rewrite of BSD mbufs or Linux skbufs is likely to be the same, i.e. O(n), for ip_id versus an encapsulation header. * For multicast flows between PIM domains and MANET domains, the overhead of prepending such encapsulation at the gateway is very likely to be within acceptable performance limits. I would therefore encourage you to consider the benefits of allowing the use of encapsulation in SMF viz the above points. Kind regards BMS _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 29 09:31:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxkQd-0002RI-2u; Thu, 29 Nov 2007 09:31:47 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IxkQc-0002Qo-7o for manet-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 09:31:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxkQb-0002Qb-U8 for manet@ietf.org; Thu, 29 Nov 2007 09:31:45 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IxkQb-0001XV-F4 for manet@ietf.org; Thu, 29 Nov 2007 09:31:45 -0500 Received: (qmail invoked by alias); 29 Nov 2007 14:31:42 -0000 Received: from 147.83-43-196.Admin.morogoro.ttcldata.net (EHLO [10.11.1.17]) [196.43.83.147] by mail.gmx.net (mp010) with SMTP; 29 Nov 2007 15:31:42 +0100 X-Authenticated: #2746672 X-Provags-ID: V01U2FsdGVkX1+WL/h2BZiWLxYpTk8QUF6b9QDwPBjPb2JKzloOPG +OeAafB43wQthQ From: elektra Organization: kein logo To: "Ulrich Herberg" Subject: Re: [manet] 802.11 PCI card in ad-hoc demo mode Date: Thu, 29 Nov 2007 17:31:15 +0300 User-Agent: KMail/1.9.6 References: <25c114b90711280710w2a950fadq62c65dad0261de3c@mail.gmail.com> <200711281826.25648.onelektra@gmx.net> <25c114b90711281103y38230af3ked376353e5abf671@mail.gmail.com> In-Reply-To: <25c114b90711281103y38230af3ked376353e5abf671@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200711291731.16064.onelektra@gmx.net> X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: manet@ietf.org X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Hi - > thanks for your reply. Are all network adapters equipped with an > Atheros chipset equal in terms of functionality? No. Older chipsets don't support XR and Super-G - but these are really old and you won't find them if you buy new cards. Some chipsets support 802.11abg, others only 802.11bg. I have no experience with 802.11n chipsets manufactured by Atheros so far. > I mean, can I buy any > Atheros card and still count on the ad-hoc demo mode? AFAIK - yes. As it is mostly a software defined radio. The biggest disadvantage of Atheros is very high CPU and interrupt load. You should consider that if you put these cards in embedded low cost APs with slow CPUs. Since you are going to use PCI-Cards this shouldn't be an issue, presuming that you use PCs that are younger than 8 years. cu elektra _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 29 17:54:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxsH1-00034O-Ny; Thu, 29 Nov 2007 17:54:23 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IxsH0-00033q-32 for manet-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 17:54:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxsGz-00033Y-Pa for manet@ietf.org; Thu, 29 Nov 2007 17:54:21 -0500 Received: from rv-out-0910.google.com ([209.85.198.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxsGz-0005DF-Cw for manet@ietf.org; Thu, 29 Nov 2007 17:54:21 -0500 Received: by rv-out-0910.google.com with SMTP id l15so1612495rvb for ; Thu, 29 Nov 2007 14:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; bh=vFfcSdD6/rdU8YtuZktqIARxEGGVtStZEhHjXtjISdc=; b=PZQN+SIhFOr2vwRUMh2G67YcOm/rxzhZOgl26asjwDSOF8PAcJ0PRdBYyagUFFSNT5+z2DL8LU/26IOtfvqdmR0yTDzgt+I3p3W5Rvs9fJgM+1nlJvDMZ5YH3hEuxJ7MFMAlLjULE+Po508Qx+wLeashOXJJwGBGKhHUjECcH1I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:mime-version:content-transfer-encoding:message-id:content-type:to:from:subject:date:x-mailer; b=Zb2yrHrZe4q5O7WF7u8PiCzRKO7PdXJ/2XI4eoNB5ZIFRIcnQcC1rU4uLzcgQ2criSg70L+don6SDr1xUJrz3zlpo/CnopRAqOBagP6elJTIIeHxG7IW147ikjEiKpUIGuoGLJGi0Zmr2FhyXVrXg2T9e8asTluZXi92cx7Imjg= Received: by 10.140.164.1 with SMTP id m1mr3638787rve.1196376860345; Thu, 29 Nov 2007 14:54:20 -0800 (PST) Received: from ?192.168.1.132? ( [70.167.209.179]) by mx.google.com with ESMTPS id l27sm6115101rvb.2007.11.29.14.54.18 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 29 Nov 2007 14:54:19 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <81360D2A-1521-4C86-8FF2-6D0CDD0995DB@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: manet From: Ian Chakeres Date: Thu, 29 Nov 2007 20:41:39 +0530 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 1.9 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [manet] MANET Area Identifier - TLV & Functionality X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org I wrote up a small I-D (draft-chakeres-manet-manetid-00.txt) specifying a TLV to administratively identify a particular MANET routing area. The idea is to enable a concept similar to OSPF areas, where different administrative routing regions are defined. I'd like to start some discussion on the TLV itself and the functionality that should/must be included in NHDP, OLSRv2, and DYMO. I'd like your opinion: Regarding the TLV, do you think the MANET area ID should be restricted to packets? Or messages? Regarding functionality, given MANETs' expected operating conditions (e.g. wireless) - containing or otherwise administratively blocking devices from receiving MANET routing protocol packets is likely infeasible. What is the best method to control propagation of routing control messages for our protocols? What must be included in the current specifications to make this a reality? There are lots of other issues in this space, please feel free to bring them up in this thread or another more specific thread. Thanks. Ian Chakeres Note: This topic is on the agenda for the WG meeting next week in Vancouver. _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 29 19:16:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxtWc-0000VS-TH; Thu, 29 Nov 2007 19:14:34 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1IxtWb-0000V8-MH for manet-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 19:14:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxtWb-0000V0-Cj for manet@ietf.org; Thu, 29 Nov 2007 19:14:33 -0500 Received: from rn-out-0910.google.com ([64.233.170.188] helo=rn-out-0102.google.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxtWb-0006tz-5t for manet@ietf.org; Thu, 29 Nov 2007 19:14:33 -0500 Received: by rn-out-0102.google.com with SMTP id i50so2009947rne for ; Thu, 29 Nov 2007 16:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; bh=buxQYsxg5dkAd4+SU2H5qO33tVpUpmxF2epQwqAO2yo=; b=J5LPSNf3HrDYaBf80W6ekVeILOxwOwaT4Loy4odq632H+WE4s1M4+woXyCgEHnsvAqfFTaG6GHsh8BtRN4eYQz78rXRxA61fQllfqOifmxFX2ppXI6xmiFd4PEXtNrrnBX/cSxYwDLtuyBt0xKXxZaVzZCzywQONaj3tuaPjGcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=FknhDCegxRUHr2RQUpaEcJhCvBoF65MVmEJUf6AzrW1FzEclp5srHToJD3izw4djnQ1/MzVQWHfl+NofYyolrXwIw0p4KS2KBpB6ZIE/GGiCBhqtGJhF6eMHvF9dbUCJJw6djmWWsWqRQjsJTFALma9l2HWTo4JjtSisIYwNiYQ= Received: by 10.150.54.6 with SMTP id c6mr1789360yba.1196381672902; Thu, 29 Nov 2007 16:14:32 -0800 (PST) Received: by 10.150.144.5 with HTTP; Thu, 29 Nov 2007 16:14:32 -0800 (PST) Message-ID: <13786f330711291614s2409f461v8267c1d49aed586f@mail.gmail.com> Date: Thu, 29 Nov 2007 19:14:32 -0500 From: "Joseph Kopena" To: manet Subject: Re: [manet] MANET Area Identifier - TLV & Functionality In-Reply-To: <81360D2A-1521-4C86-8FF2-6D0CDD0995DB@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <81360D2A-1521-4C86-8FF2-6D0CDD0995DB@gmail.com> X-Google-Sender-Auth: 5bb9102396f8a729 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org On Nov 29, 2007 10:11 AM, Ian Chakeres wrote: > Regarding the TLV, do you think the MANET area ID should be > restricted to packets? Or messages? Hi Ian & everyone, I can foresee potential uses for MANET_ID in address block TLVs. An example would be reporting on the area of other nodes. The draft seems to allow this, is there a motivation to disallow it? Thx -- - joe kopena right here and now _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Thu Nov 29 19:32:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixtmc-00049P-B9; Thu, 29 Nov 2007 19:31:06 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Ixtmb-000499-4u for manet-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 19:31:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixtma-00048z-Q5 for manet@ietf.org; Thu, 29 Nov 2007 19:31:04 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixtma-0006lH-Bi for manet@ietf.org; Thu, 29 Nov 2007 19:31:04 -0500 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id lAU0UwJ9011449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Nov 2007 16:30:58 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id lAU0UvP1002197; Thu, 29 Nov 2007 18:30:57 -0600 (CST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id lAU0UoTY001997; Thu, 29 Nov 2007 18:30:57 -0600 (CST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 16:30:57 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] MANET Area Identifier - TLV & Functionality Date: Thu, 29 Nov 2007 16:30:17 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029EDC67@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <81360D2A-1521-4C86-8FF2-6D0CDD0995DB@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] MANET Area Identifier - TLV & Functionality Thread-Index: Acgy2ugnGckOcVqqQGOH2teJ/uzGzwADO15w References: <81360D2A-1521-4C86-8FF2-6D0CDD0995DB@gmail.com> From: "Templin, Fred L" To: "Ian Chakeres" , "manet" X-OriginalArrivalTime: 30 Nov 2007 00:30:57.0067 (UTC) FILETIME=[4624AFB0:01C832E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian, I wonder if there is overlap with the autoconf wg in terms of what exactly constitutes a MANET identifier, since that is where the MANET Architecture work is taking place? Thanks - Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Ian Chakeres [mailto:ian.chakeres@gmail.com]=20 > Sent: Thursday, November 29, 2007 7:12 AM > To: manet > Subject: [manet] MANET Area Identifier - TLV & Functionality >=20 > I wrote up a small I-D (draft-chakeres-manet-manetid-00.txt) =20 > specifying a TLV to administratively identify a particular MANET =20 > routing area. >=20 > The idea is to enable a concept similar to OSPF areas, where =20 > different administrative routing regions are defined. >=20 > I'd like to start some discussion on the TLV itself and the =20 > functionality that should/must be included in NHDP, OLSRv2, and DYMO. >=20 > I'd like your opinion: >=20 > Regarding the TLV, do you think the MANET area ID should be =20 > restricted to packets? Or messages? >=20 > Regarding functionality, given MANETs' expected operating conditions =20 > (e.g. wireless) - containing or otherwise administratively blocking =20 > devices from receiving MANET routing protocol packets is likely =20 > infeasible. What is the best method to control propagation of=20 > routing =20 > control messages for our protocols? What must be included in the =20 > current specifications to make this a reality? >=20 > There are lots of other issues in this space, please feel free to =20 > bring them up in this thread or another more specific thread. >=20 > Thanks. > Ian Chakeres >=20 > Note: This topic is on the agenda for the WG meeting next week in =20 > Vancouver. >=20 >=20 > _______________________________________________ > manet mailing list > manet@ietf.org > https://www1.ietf.org/mailman/listinfo/manet >=20 _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 30 04:50:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy2Vq-0006s3-Bd; Fri, 30 Nov 2007 04:50:22 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iy2Vo-0006rj-5x for manet-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 04:50:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy2Vn-0006rY-RR for manet@ietf.org; Fri, 30 Nov 2007 04:50:19 -0500 Received: from smtp1.bae.co.uk ([20.133.0.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy2Vn-00058g-8N for manet@ietf.org; Fri, 30 Nov 2007 04:50:19 -0500 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id lAU9oBnR026710 for ; Fri, 30 Nov 2007 09:50:11 GMT Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id lAU9oB70000336 for ; Fri, 30 Nov 2007 09:50:11 GMT Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Fri, 30 Nov 2007 09:50:11 -0000 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.2499); Fri, 30 Nov 2007 09:50:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] MANET Area Identifier - TLV & Functionality Date: Fri, 30 Nov 2007 09:50:09 -0000 Message-ID: In-Reply-To: <81360D2A-1521-4C86-8FF2-6D0CDD0995DB@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [manet] MANET Area Identifier - TLV & Functionality Thread-Index: Acgy2uf1uxRd96vsSYepzzFnDGZPzwAWpN1w References: <81360D2A-1521-4C86-8FF2-6D0CDD0995DB@gmail.com> From: "Dearlove, Christopher (UK)" To: "Ian Chakeres" , "manet" X-OriginalArrivalTime: 30 Nov 2007 09:50:11.0074 (UTC) FILETIME=[65E3D620:01C83336] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: manet-bounces@ietf.org Ian Chakeres: > Regarding the TLV, do you think the MANET area ID should be =20 > restricted to packets? Or messages? This pre-supposes that the MANET area ID is the right solution. Before taking that step, I would want a statement of what the problem is, and consideration of whether alternative solutions (for example using address prefixes) are more appropriate. For this reason I'm also not sure if Autoconf, rather than Manet, isn't the right home for this. (If we get to that point, the specific answer to your question is, I'm fairly confident, messages. But we're not at that point yet.) ******************************************************************** 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 mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet From manet-bounces@ietf.org Fri Nov 30 12:11:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9P5-0002FD-NU; Fri, 30 Nov 2007 12:11:51 -0500 Received: from manet by megatron.ietf.org with local (Exim 4.43) id 1Iy9P3-0002EM-Ut for manet-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 12:11:49 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9P3-0002EA-Jw for manet@ietf.org; Fri, 30 Nov 2007 12:11:49 -0500 Received: from ug-out-1314.google.com ([66.249.92.174]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy9P3-0002qB-5b for manet@ietf.org; Fri, 30 Nov 2007 12:11:49 -0500 Received: by ug-out-1314.google.com with SMTP id u2so3090088uge for ; Fri, 30 Nov 2007 09:11:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; bh=v/2WrDKKyDRTKiHOSx57attqG7+ePzrXSMowRnYXbH4=; b=Ev5b14cSBqI3VV6DPgXNMrnHJr4vkKePwoL7fYfZSDFh+iAAP49I91A6AxUDfwJxdr9FGwAtXUGiI9Tyi9iQpY4S85hfGQ2OpyY7Y7y9ZV8N5FwlsAJlCnblnH2PT/9uhEKstDBGbnM+aCFQgtsqHRG9rnuLDQJdsPvu6kGD410= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=vP/Wi2qM3qRe0v1FaVXq0eTM3dUqDsgzgTJPFXatBIU+Dy+m1dtTHg2crXm3sQ6VaMACwdxb5eHW5tvGnNaNNuPnfur3palJqVFOET0UheiV7YLZSnUP41JG4hBNP4jsK+Vf2sbI0bIfyrm/17lK+rj7Gzk75WBXcQrk+nV7jfk= Received: by 10.66.216.8 with SMTP id o8mr2118690ugg.1196442708112; Fri, 30 Nov 2007 09:11:48 -0800 (PST) Received: by 10.67.10.14 with HTTP; Fri, 30 Nov 2007 09:11:48 -0800 (PST) Message-ID: <5abf39e60711300911v71e9b765i171db0ebe552dd2d@mail.gmail.com> Date: Fri, 30 Nov 2007 22:41:48 +0530 From: "Pushpita Chatterjee" To: manet@ietf.org In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [manet] Re: manet Digest, Vol 43, Issue 33 X-BeenThere: manet@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobile Ad-hoc Networks List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0252210103==" Errors-To: manet-bounces@ietf.org --===============0252210103== Content-Type: multipart/alternative; boundary="----=_Part_1508_12995127.1196442708103" ------=_Part_1508_12995127.1196442708103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline I am going to model a trust based framework for MANET, want to formulate trust establisment without using traditional cryptographis techniques like key exchange, etc. suggest me some fields from where i can get idea for building initial trust? Pushpita ------=_Part_1508_12995127.1196442708103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
I am going to model a trust based framework for MANET, want to formulate trust establisment without using traditional cryptographis techniques like key exchange, etc.
suggest me some fields from where i can get idea for building initial trust?
Pushpita

------=_Part_1508_12995127.1196442708103-- --===============0252210103== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet --===============0252210103==--