Hi Guillaume, More comments inline, bracketed by <RCC2></RCC2>.
Robert On 30/01/2012 2:30 AM, Guillaume Fortaine wrote:
<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>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>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 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>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>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>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><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.pdfYes, like DASH7. But, indeed, these two standards are flawed by design.
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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Lwip mailing list [email protected] https://www.ietf.org/mailman/listinfo/lwip
