Subject: [Lwip] guidelines for the LWIP BOF

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Sep 2010 15:12:42 +0300

This BOF was approved for IETF-79!

Here are some suggestions on how to scope the discussion in the BOF and 
what to do in the weeks before the meeting. My hope is that this will 
increase the likelihood of having a successful meeting.

The original BOF scope included five topics:

> 1. TCP header compression. Many applications use TCP as the transport 
> to provide some robustness and reliability. Since the IEEE 802.15.4 
> frame size is very limited and not able to accommodate much protocol 
> headers, it is desirable to provide header compression for TCP. 
> 6LowPan WG has defined the IPv6 header compression, and UDP header 
> compression. But there is not standardized TCP header compression 
> mechanism.
>
> 2. Lightweight transport protocol. In some lightweight operation 
> systems, for example, Contiki and TinyOS, it turns out that the TCP 
> codes take up to 50% of the code size and the switch between different 
> TCP states consumes much memory size. It is desirable to design a new 
> transport layer protocol to do flow control and congestion control.
>
> 3. Lightweight key exchange protocol. IEEE 802.15.4 has defined MAC 
> security , but there is no keying there and applications are 
> struggling if they do not have the keys. Most security protocols are 
> resource consuming, and it is difficult to apply them directly to 
> smart devices. For example, there are some proposals of making Host 
> Identity Protocol diet so as to provide keys for the MAC layer.
>
> 4. Profiles for different application scenarios. For different 
> scenarios, different set of protocols could be applied. It is 
> desirable to have a document specifying those profiles and benefit 
> application deployment.
>
> 5. Documentation of implementation techniques. There are lots of 
> tricks to make the IP stack lightweight so as to fit into the very 
> constrained nodes. But these techniques are not well documented 
> formally. In order to facilitate the ongoing/future developers on 
> these constrained platforms, there is a need to document these 
> activities and common technologies.

I would like to see the group focus on the last one of these, 
documentation of implementation techniques or guidance for implementing 
core IP protocols on a lightweight node. This may include actual 
implementation techniques, advice about what protocol aspects can be 
simplified on one without compromising interoperability, etc. I would 
also love to see contributions from people who have built actual stacks. 
For instance, Bob Hinden sent me this list:

http://savannah.nongnu.org/projects/lwip/
http://www.computer.org/portal/web/csdl/doi/10.1109/AINA.2009.53
http://www.eurojournals.com/ejsr_22_2_15.pdf
http://www.sics.se/~adam/uip/uip-0.9-refman/main.html
http://www.unusualresearch.com/tinytcp/tinytcp.htm
http://www.utwente.nl/ewi/dacs/assignments/completed/bachelor/reports/B-assignment_vanderPloeg.pdf

He searched these from Google, there's likely much more if you search in 
more detail. From these you should be able to find a list of 
implementations, many of which are open source. The first success 
criteria of the BOF effort is that you are capable of attracting the 
attention of some of the folk who have built these types of stacks (and 
there may of course already be some in the group). Hopefully you can 
make some progress on this before the meeting. It would also be great to 
have some drafts about the implementation guidance.

I believe the other parts in the initial scope list are not ready to be 
discussed at a BOF at this stage. It is crucial that we first understand 
the limitations and opportunities in implementation techniques and prune 
protocol parts that are not essential for interoperability. It may be 
that once we have that understanding, we see more clearly a need for 
some further work, e.g., some new protocols. However, at this stage I'm 
a bit skeptical about that. On item 1, we already have many header 
compression mechanisms (often not implemented or not used), it would be 
necessary to understand why some new work is needed. On item 2, I 
suspect that if reliability and congestion avoidance are requirements, 
you cannot get much simpler than TCP. There is of course a great 
difference between a full-blown all-features implementation and 
something that is carefully tailored for small environments, parameter 
settings optimized for minimum memory usage, etc. I have some experience 
in building small implementations of var'ious things and it is 
surprising how much you can do. On item 3, it is unclear if this is an 
effort that the IETF should undertake. IEEE key exchange protocols such 
as 802.11i have traditionally been developed in the IEEE. On item 4, it 
is unclear whether this would be desirable if one Internet and global 
interoperability is the goal.

Jari

---

From: Zhen Cao <[email-masked]>
Date: Wed, 29 Sep 2010 23:28:03 +0800

Thank you, Jari.  See my comments inline.

Regards,
Zhen

> http://www.utwente.nl/ewi/dacs/assignments/completed/bachelor/reports/B-assignment_vanderPloeg.pdf

Basically I came across most of these implementation.  And there are
also some more based on TinyOS.
We are working on have more people from these hands-on projects.

> implementations, many of which are open source. The first success criteria
> of the BOF effort is that you are capable of attracting the attention of
> some of the folk who have built these types of stacks (and there may of
> course already be some in the group). Hopefully you can make some progress
> on this before the meeting. It would also be great to have some drafts about
> the implementation guidance.
>
> discussed at a BOF at this stage. It is crucial that we first understand the
> limitations and opportunities in implementation techniques and prune
> protocol parts that are not essential for interoperability. It may be that
> once we have that understanding, we see more clearly a need for some further
> work, e.g., some new protocols. However, at this stage I'm a bit skeptical
> about that.

In some of our internet of things practice, we found the wireless
sensing devices have different layer2 technologies, and the current
6lowpan (which is only based on 802.15.4-2006) would not be able to
serve.  And there are needs of a generic adaption layer for different
layer-2 techniques, lightweight naming service and lightweight
mobility solutions as well.  We are considering them right now and
will come up with more.

> On item 1, we already have many header compression mechanisms
> (often not implemented or not used), it would be necessary to understand why
> some new work is needed. On item 2, I suspect that if reliability and
> congestion avoidance are requirements, you cannot get much simpler than TCP.
> There is of course a great difference between a full-blown all-features
> implementation and something that is carefully tailored for small
> environments, parameter settings optimized for minimum memory usage, etc. I
> have some experience in building small implementations of var'ious things
> and it is surprising how much you can do. On item 3, it is unclear if this
> is an effort that the IETF should undertake. IEEE key exchange protocols
> such as 802.11i have traditionally been developed in the IEEE. On item 4, it

On item 3, normally IEEE will take some IETF protocol as the basis for
their design (fill into the frame).  Item 4 is difficult since the
scenarios varies from case to case, and profiles are not easy to
reach.

Besides the above, we are currently working on the scenarios and the
story, and will post to the list once finished.

Thank you for the suggestions very much!

> Jari
>
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 29 Sep 2010 19:15:23 +0300

Zhen,

> We are working on have more people from these hands-on projects.

Great!

> mobility solutions as well.  We are considering them right now and

I think the generic adaptation layer is called IP... its pretty minimal :-)

But I would indeed advice against bringing in lightweight versions of 
naming or mobility services to the BOF. Just to pick one item here, name 
service in the Internet is extremely simple already. I don't think we 
want to spend all of our time in the BOF in argument how necessary or 
unnecessary these things are. Perhaps if we do good work on the 
implementation advice then in the future we can talk about how that 
shows we need to provide some simplified versions of existing Internet 
mechanisms. However, that is a very significant step, given that the 
Internet architecture attempts to serve everyone with a single mechanism 
if at all possible (see RFC 1958, Section 3.2). And there would be 
interoperability problems if there were multiple mechanisms.

> their design (fill into the frame).

Yes, they sometimes do. But in those cases there are typically very 
clear requirements and
some level of separation between a general end-to-end protocol and its 
application in the IEEE context. For instance, IETF designed EAP and 
IEEE used it. However, related protocols needed to support EAP in the 
IEEE context (EAPOL, 802.11i) were all developed by IEEE. Are there 
requirements today for 802.15.4 keying? What is the IEEE itself doing in 
this space?

Jari