Dear Mister Cragie, Thank you for your comprehensive reply.
> <RCC2>I think you are missing my point. When designing a system based on a > constrained platform, many considerations have to be made for optimization. > That is acknowledged in the statement above. However, the scope and remit of > lwig (part of the INT area) concerns the Internet protocol stack part alone > and even then, the implementation of the IETF-specified protocols. So, for > example, there may be a novel way to represent buffers which provides a good > optimization for a constrained system. However, this does not fall under the > remit of the lwig WG. There are many good references outside of the IETF to > obtain guidance for such areas of optimization.</RCC2> I don't think that I am missing the point. Please let explain me why. The network layer IP is dependent of the MAC Layer, hence the need for 6LoWPAN on top of 802.15.4 which uses short packets. However, the MAC is also tightly coupled to the underlying Hardware. Especially, I would greatly appreciate to invite you to a further reading of the paper entitled "The Lambda-MAC framework: redefining MAC protocols for wireless sensor networks". To quote [0] : "We feel that this is important because simulation is a poor guide to how something as low-level and radio hardware dependent as a MAC protocol will behave on real hardware." Thus, my advice to have a bottom-top approach. > <RCC2>Unfortunately, just stating it is "no sense" does not really give me a > good position from which to discuss this further. Firstly, I think you mean > slide 9. not 10. With regard to the statement "Where is the point of > compressed IP packets on low power PANs ?": I presume you mean "where do I > make the point?" as opposed to "what is the point?". The slide states > "optimize limited bandwidth". I guess I could have elaborated further but > this is a presentation and not meant to be a detailed discussion. For > wireless especially, clearly shorter packets means less radio time, which > means less power consumption as the dominant power consumption is usually > the analog Rx/Tx. Also, these type of networks have more recently been > described as "lossy/low power" (the "LL" in ROLL WG) where the two do not > necessarily go hand-in-hand; it is possible to envisage a lossy network but > not one which is low power.</RCC2> a) "Firstly, I think you mean slide 9. not 10." : yes, sorry. for the mistake. b) "shorter packets means less radio time which means less power consumption as the dominant power consumption is usually the analog Rx/Tx." : you could also increase the throughput. Especially, Power Consumption is becoming less and less critical due to recent advances in Energy Harvesting. By the way, I would greatly appreciate to invite you to a further reading of the publication entitled "Opal: A Multi-radio Platform for High Throughput Wireless Sensor Network". To quote [1] : "Energy-efficiency has so far been a dominant design target in WSN platforms, due to the limited battery capacity imposed by the device form factor. However, recent advances in energy harvesting, such as solar, have shown networks that can operate for years [1]. While energy remains a key consideration, the focus on energy-efficiency has so far sidelined other design considerations in WSNs, such as communication throughput and range." > <RCC2>You are entitled to your opinion. There are many wireless standards > out there and consequently many (IMHO often pointless) debates about which > one is better than the other. As I said in my earlier post, I believe if the > focus is more on enabling subnets on different MAC/PHYs to work together, > then it provides a more level playing field and then the market can > decide.</RCC2> 802.15.4g is what I call a winner :-) : https://mentor.ieee.org/802.15/dcn/09/15-09-0485-02-004g-fpp-sun-technical-overview.pdf By the way, it removes the need for 6LoWPAN : http://tools.ietf.org/wg/6lowpan/minutes?item=minutes79.html "We do not need a 6lowpan over 802.15.4g document." Best Regards, [0] http://www.springerlink.com/content/17t7n74336v6qu57/fulltext.pdf [1] http://www.es.ewi.tudelft.nl/papers/2011-Jurdak-opal.pdf Guillaume FORTAINE On Mon, Jan 30, 2012 at 10:42 AM, Robert Cragie <[email protected]> wrote: > Hi Guillaume, > > More comments inline, bracketed by <RCC2></RCC2>. > > Robert > > > On 30/01/2012 2:30 AM, Guillaume Fortaine wrote: >> >> Dear Mister Cragie, >> >> Thank you for your comprehensive reply. >> >> >>> <RCC>They are outside the scope of the document because it is outside the >>> scope and charter of the lwig WG: >>> http://datatracker.ietf.org/wg/lwig/charter/</RCC> >> >> True, but contradictory : >> >> "Building a small implementation does not have to be hard. Many small >> devices use stripped down versions of general purpose operating systems >> and their TCP/IP stacks. However, there are implementations that go even >> further in minimization and can exist in as few as a couple of kilobytes >> of code, as on some devices this level of optimization is necessary. >> Technical and cost considerations may limit the computing power, battery >> capacity, available memory, or communications bandwidth that can be >> provided. To overcome these limitations the implementors have to employ >> the right hardware and software mechanisms. For instance, certain types >> of memory management or even fixed memory allocation may be required. It >> is also useful to understand what is necessary from the point of view of >> the communications protocols and the application employing them. For >> instance, a device that only acts as a client or only requires one >> connection can simplify its TCP implementation." > > <RCC2>I think you are missing my point. When designing a system based on a > constrained platform, many considerations have to be made for optimization. > That is acknowledged in the statement above. However, the scope and remit of > lwig (part of the INT area) concerns the Internet protocol stack part alone > and even then, the implementation of the IETF-specified protocols. So, for > example, there may be a novel way to represent buffers which provides a good > optimization for a constrained system. However, this does not fall under the > remit of the lwig WG. There are many good references outside of the IETF to > obtain guidance for such areas of optimization.</RCC2> > >> >> >>> <RCC>I think such statements are unnecessary and do not add anything >>> constructive to the discussion. I can assure you that contributors like >>> Carsten and others I work with have a superior knowledge of what is >>> required >>> to implement Internet protocol-based devices in low power devices with >>> small >>> footprints</RCC> >> >> No. Especially, I have read with interest your presentation entitled >> "The ZigBee IP Stack : IPv6-based stack for 802.15.4 network", slide >> "IETF 6lowpan-hc adaptation layer", p.10 [0] : This is totally no >> sense. Where is the point of compressed IP packets on low power PANs ? > > <RCC2>Unfortunately, just stating it is "no sense" does not really give me a > good position from which to discuss this further. Firstly, I think you mean > slide 9. not 10. With regard to the statement "Where is the point of > compressed IP packets on low power PANs ?": I presume you mean "where do I > make the point?" as opposed to "what is the point?". The slide states > "optimize limited bandwidth". I guess I could have elaborated further but > this is a presentation and not meant to be a detailed discussion. For > wireless especially, clearly shorter packets means less radio time, which > means less power consumption as the dominant power consumption is usually > the analog Rx/Tx. Also, these type of networks have more recently been > described as "lossy/low power" (the "LL" in ROLL WG) where the two do not > necessarily go hand-in-hand; it is possible to envisage a lossy network but > not one which is low power.</RCC2> > >> >> >>> <RCC>I think it would behove the DASH7 Alliance to produce something akin >>> to >>> what the BT-LE folks did, i.e. produce a draft of 6LoWPAN over DASH7. To >>> write off 6LoWPAN just because it was initially targeted at 802.15.4 >>> seems >>> pointless; it is applicable to any low power wired or wireless technology >>> which uses short packets and would benefit from some header/payload >>> compression</RCC> >> >> There are people working on this topic : "IPv6 on wireless DASH7 links" >> [1]. > > <RCC2>I look forward to it being submitted as an Internet Draft, like the > BT-LE folks did. Antonio Jura and his colleagues' work looks interesting too > and I shall read his paper.</RCC2> > >> >> >>> <RCC>In what way is 802.15.4 not open? I can download the standard from >>> the >>> IEEE free of charge: >>> http://standards.ieee.org/getieee802/download/802.15.4-2006.pdf >> >> Yes, like DASH7. But, indeed, these two standards are flawed by design. > > <RCC2>You are entitled to your opinion. There are many wireless standards > out there and consequently many (IMHO often pointless) debates about which > one is better than the other. As I said in my earlier post, I believe if the > focus is more on enabling subnets on different MAC/PHYs to work together, > then it provides a more level playing field and then the market can > decide.</RCC2> > >> >> >> Best Regards, >> >> [0] http://labs.chinamobile.com/attachments/wiise/MiracleW-3.pdf >> [1] >> http://kurser.iha.dk/ee-ict-master/tienprau/ProjectProposals/Communication%20Technology/Engineering%20Research%20Projects%20-%206LOWPAN%20on%20DASH7.htm >> >> Guillaume FORTAINE >> >> >> > _______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
