Subject: [6lowpan] WG Last call on Problem Statement Document

From: Geoff Mulligan <[email-masked]>
Date: Wed, 19 Jul 2006 15:29:49 -0600

Folks,
  This note formally starts the WG Last Call for comments on
draft-ietf-6lowpan-problem-04.txt, "6LoWPAN: Overview, Assumptions,
Problem Statement and Goals".

The document can be found at:
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-problem-04.txt

The document is intended to be submitted by this Working Group to the
IESG for publication as an Informational Document.

Please review the document carefully (one last time), and send your
comments to the 6lowpan list.  Please also indicate in your response
whether or not you think this document is ready to go to the IESG.

This Last Call will end on Wednesday 02 August 2006 at 2359 UTC.

	Thanks,
		Geoff & Carsten

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 19 Jul 2006 14:48:46 -0700 (PDT)

Hi Geoff,
 
This document had already gone thruogh WG last call. The changes done were as a result of that.
So wouldn't the draft now be ready to be sent to the IESG?
 
tnx,.
 
-gabriel

----- Original Message ----
From: Geoff Mulligan <[email-masked]>
To: 6lowpan <[email-masked]>
Sent: Wednesday, July 19, 2006 2:29:49 PM
Subject: [6lowpan] WG Last call on Problem Statement Document

Folks,

    Thanks,
        Geoff & Carsten

---

From: Geoff Mulligan <[email-masked]>
Date: Wed, 19 Jul 2006 16:02:01 -0600

Gabriel,
  In our discussions and the limited feedback that we originally
received from the working group, we felt that since it didn't make sense
to send one document without the other to the IESG that we would err on
the side of greater opportunity and call a WG last call on both
documents.

	geoff

---

From: Soohong Daniel Park <[email-masked]>
Date: Wed, 19 Jul 2006 16:07:18 -0700

Seems really odd. Is it a second WGLC ?

Anyhow, I believe it is ready to the IESG, Good job.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

---

From: gabriel montenegro <[email-masked]>
Date: Wed, 19 Jul 2006 16:28:39 -0700 (PDT)

I guess that would argue for (1) *not* advancing the prob statement until the format document catches up
(and then advancing both in lockstep), not necessarily for (2) issuing another WG LC on the prob statement. 
The latter seems superfluous.
 
-gabriel

----- Original Message ----
From: Geoff Mulligan <[email-masked]>
To: gabriel montenegro <[email-masked]>
Cc: 6lowpan <[email-masked]>
Sent: Wednesday, July 19, 2006 3:02:01 PM
Subject: Re: [6lowpan] WG Last call on Problem Statement Document

Gabriel,

    geoff

---

From: Philip Levis <[email-masked]>
Date: Wed, 19 Jul 2006 15:34:17 -0700

> whether or not you think this document is ready to go to the IESG.

One consideration and one question about an implication. Both stem  
from the scarcity of storage (RAM or non-volatile) on many of these  
devices, due to power and cost considerations.

Consideration: the draft acknowledges that LowPAN devices may be  
deployed in large numbers (possibly in high density) but require low- 
state/low-overhead protocols. It might be useful to make this  
statement a little stronger, and comment that protocols which require  
state for every "neighbor" (whatever that means) are not feasible.  
Rather, protocols which can scale to different degrees of accuracy  
(e.g., I can store 10% of the neighbors, vs. 50%) are preferred.  
Otherwise, you have a box with 10,000 nodes in it and the protocols  
collapse.

Question: The requirement for fragmentation and assembly below IP,  
given the minimum packet size of 1280 octets, seems to preclude most  
devices that have, e.g., 2K of RAM and no other feasible storage  
medium. I don't mean to suggest that this limitation on scope or  
statement of requirements is a problem: you have to cut the line  
somewhere. Rather, would making this explicit be helpful?

Phil

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Jul 2006 20:10:06 -0700 (PDT)

I agree with Phil, I think we should have his consideration considered seriously.
Regarding his question, in the format draft, 802.15.4 MAC layer is assumed and the frame sizes are from IEEE standard. This WG assumes that even the light sensors support 802.15.4 MAC (kind of like Telos motes). In that sense this WG is addressing futuristic sensor nodes on which IP stack can be implemented. How close that future be, we do not know.

Regards,

Behcet

----- Original Message ----
From: Philip Levis <[email-masked]>
To: Geoff Mulligan <[email-masked]>
Cc: 6lowpan <[email-masked]>
Sent: Wednesday, July 19, 2006 5:34:17 PM
Subject: Re: [6lowpan] WG Last call on Problem Statement Document

Phil

---

From: Philip Levis <[email-masked]>
Date: Thu, 20 Jul 2006 08:52:49 -0700

On Jul 19, 2006, at 8:10 PM, Behcet Sarikaya wrote:

> Regarding his question, in the format draft, 802.15.4 MAC layer is  
> assumed and the frame sizes are from IEEE standard. This WG assumes  
> that even the light sensors support 802.15.4 MAC (kind of like  
> Telos motes). In that sense this WG is addressing futuristic sensor  
> nodes on which IP stack can be implemented. How close that future  
> be, we do not know.
>

You can totally write an IP stack -- even a TCP stack -- on sensor  
nodes today, admittedly the ones that have the biggest  
microcontrollers you can buy (atmega128L, MSP430F1611, etc.). The TCP  
stack might not have a lot of RAM for windowing and high performance,  
but that's rarely the goal.  You can do it.

I don't think the requirements the document implies are unrealistic  
or onerous. As I said, you have to cut the line somewhere. My comment  
was just that they *do* preclude smaller nodes whose storage cannot  
hold a complete IPv6 packet, and it might be useful to note as such,  
since the document is defining the problem statement, and therefore  
the problem scope.

Phil

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 20 Jul 2006 13:05:00 -0700 (PDT)

OK, I think Phil is commenting on:
This is obviously far below the minimum IPv6 packet size of 1280 octets,

1280 octets is not necessarily the minimum IPv6 packet size, but you can set 1280 as the MTU size which would mean the maximum packet size.
This point is clear in the format draft, draft-ietf-6lowpan-format-03.txt but it should be clarified in the PS draft as well.

Regards,

Behcet

----- Original Message ----
From: Philip Levis <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: Geoff Mulligan <[email-masked]>; 6lowpan <[email-masked]>
Sent: Thursday, July 20, 2006 10:52:49 AM
Subject: Re: [6lowpan] WG Last call on Problem Statement Document

Phil

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 20 Jul 2006 14:32:12 -0600

> but that's rarely the goal.  You can do it.

We have already built an 802.15.4MAC/AODVtiny/IPv6/UDP stack that will
run on a 64K part and, with some optimization in the MAC, should run on
a 32K part.  For a non-routing node (read RFD) it should run on a 16K
part!  As Phil rightly points out, RAM is actually more of a constraint.

> since the document is defining the problem statement, and therefore  

There certainly could be a problem for very small parts (ie those with
very limited RAM - 2k) where it could be nearly impossible for the
device to store a complete 1280 byte IPv6 packet, but I think with some
judicious use of memory it might be doable even on a 2k ram device so
long as it isn't trying to maintain routing tables.

	geoff

---

From: Philip Levis <[email-masked]>
Date: Thu, 20 Jul 2006 14:31:57 -0700

> part!  As Phil rightly points out, RAM is actually more of a  

16K RAM or program memory? If RAM, it sounds like you're talking  
about an ARM or an MCU with an external memory attachment. The  
largest microcontroller (not microprocessor) I know of is the  
MSP430F1611, with 10K. Are there others? I'm sure you could easily do  
all of those things  in much less than 16K of RAM.

If you're talking about program memory, yeah, 32K sounds right, and  
16K would be really squeaking it in.

> long as it isn't trying to maintain routing tables.

OK, we can quibble about where the line is (2K, 1K, 1.5K, 1529 bytes,  
etc), but I think the point remains: there will be devices that  
cannot receive complete IPv6 packets, and will therefore either be  
precluded from interoperability or require breaking the end-to-end  
argument by fragmenting and reassembly at the IP layer (not below, as  
the draft mentions).

Anyways, I guess the question is whether the WG feels that mentioning  
this constraint is important enough to include in the document.  
Sounds like opinion is mixed. Given that it's such a minor point, I  
don't think it's a big deal if it's not included; I just think its  
presence would help define the problem space a little bit more  
precisely.

Phil

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 20 Jul 2006 15:56:34 -0600

> 16K would be really squeaking it in.

We have the code currently running on a 64K flash part with 4K of ram.
The biggest problem we are seeing with 16k flash parts is that they
generally only have 2K (max) of ram.  This is critically small for
buffer space.

> argument by fragmenting and reassembly at the IP layer (not below, as  

How does ip fragmentation "break" end-to-end?

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 20 Jul 2006 16:23:51 -0600

Behcet,
  Just to be clear - the future is now.  We have and others have
implemented IPv6 on 802.15.4 - it works and is deployed.  Our stack is
not yet 6lowpan compliant in that our frame format is not the same as
6lowpan but this is a small tweak.

	geoff

On Wed, 2006-07-19 at 20:10 -0700, Behcet Sarikaya wrote:
> that even the light sensors support 802.15.4 MAC (kind of like Telos
> motes). In that sense this WG is addressing futuristic sensor nodes on
> which IP stack can be implemented. How close that future be, we do not
> know.
> 
> Regards,
> 
> Behcet
>

---

From: Philip Levis <[email-masked]>
Date: Thu, 20 Jul 2006 15:31:05 -0700

> How does ip fragmentation "break" end-to-end?

I think I was unclear and miswrote; since you cannot receive the  
complete IP-level packet, you cannot receive the complete packet from  
the L4+ protocol. Therefore the L4+ protocol needs to break its  
packet up into finer parts. E.g., rather than break a single UDP  
packet into multiple IP fragments, you might actually have to break  
it up into multiple UDP packets. But since it's end-to-end  
fragmentation/assembly anyway, I guess this isn't a big deal.

Phil

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Thu, 20 Jul 2006 20:05:12 -0700

> since the document is defining the problem statement, and therefore

Your point is valid. Though IMHO, drawing a strict line on non-applicability
on low RAM devices may not be wise. But I do agree that having a few lines
of text about the issues on having low RAM or tiny micro-controllers  would be
useful to discuss. It will actually help the implementors make the
right decision
on optimization on their implementation, if possible, in case they decide to use
6lowpan stack on those low-capability HW devices.

Regards,
-Samita

---

From: Philip Levis <[email-masked]>
Date: Fri, 21 Jul 2006 11:59:34 -0700

On Jul 20, 2006, at 8:05 PM, Samita Chakrabarti wrote:

> on low RAM devices may not be wise.

Of course; it would be counter-productive for the document to say  
"this means IPv6 cannot be implemented on hardware XYZ," as the  
future and some interesting techniques might show such a hard  
statement to be wrong. Rather, something such as "IPv6's requirement  
of sub-IP reassembly may pose challenges for low-end LowPAN devices  
that do not have enough RAM or storage for a  1280-octet packet."

But anyways. Sounds like I've beaten this horse to death.

Phil

---

From: gabriel montenegro <[email-masked]>
Date: Tue, 25 Jul 2006 18:18:44 -0700 (PDT)

I think your text below makes sense, and see no problem adding it, unless there's heated objection.
In general, though, this 1280 byte number is just thrown in to say that we comply with IPv6
requirements. Having enough buffer space for such large packets does not make it a good idea to
throw them around a LoWPAN network. Nor does having insufficient buffer space mean that such
a device won't be able to participate in a LoWPAN network, given that judicious applications 
better NOT use such large packets anyhow.
 
I guess the upcoming document on application best practices (if we ever finish our current
docs and recharter) can offer advice in this regard.
 
-gabriel

----- Original Message ----
From: Philip Levis <[email-masked]>
To: Samita Chakrabarti <[email-masked]>
Cc: 6lowpan <[email-masked]>
Sent: Friday, July 21, 2006 11:59:34 AM
Subject: Re: [6lowpan] WG Last call on Problem Statement Document

Phil