Hi Guillaume, More comments inline, bracketed by <RCC3></RCC3>.
In summary, I appreciate your contributions to the mailing list. I would rather not get into a debate over the merits of one wireless standard over another on this forum, simply because a) lwig is probably the wrong forum and b) it is subjective to a large extent and thus debate can ensue for a long time without making any real progress.
Robert On 30/01/2012 10:38 AM, Guillaume Fortaine wrote:
<RCC3>OK, let me try and put it a different way. I agree with a holistic approach to optimization which includes bottom up and top down; the application is equally important. So the aim would be for such an approach to reference guidance produced by lwig with regard to an implementation of an IP stack.</RCC3>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.
<RCC3>Indeed, you could increase the throughput also resulting in shorter packets and thus less radio time; many 802.15.4 radios have 'turbo' modes, which allow faster bit rates. There is usually a link budget cost though do to reduced chipping sequence sizes etc. but for devices in close proximity this may well be worth it. However, these modes are generally proprietary and non-interoperable. Power consumption and energy harvesting is an interesting area of discussion, probably one for off-list; similarly there have been good advances from some of the chip manufacturers in 802.15.4 radios</RCC3><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] :
<RCC3>15.4g was generally created for carrier-grade longer range wireless mesh ("Smart Utility Network") as opposed to WPAN. I agree that the longer packets and generally higher power may make the need for 6lowpan redundant. However, whilst fragmentation into smaller packets does have a header overhead, it can be a benefit in low power, lossy networks; if a long MAC/PHY packet gets corrupted, the whole packet has to be sent again, whereas shorter packets can be reassembled and only missed fragments need to be re-requested (http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-07).</RCC3><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."
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
