Geoff Mulligan wrote:
2. Produce “Problem Statement for Stateful Header Compression in
6lowpans” to document the problem of using stateful header compression
(2507, ROHC) in 6lowpans. Currently 6lowpan only specifies the use of
stateless header compression given the assumption that stateful header
compression may be too complex. This document will determine if the
assumption is correct and will be an informational document.
The need for and value of this document escapes me, but maybe it's
just me.
The 6lowpan format document contains the following language:
10. Header Compression
There is much published and in-progress standardization work on
header compression. Nevertheless, header compression for IPv6 over
IEEE 802.15.4 has differing constraints summarized as follows:
Existing work assumes that there are many flows between any two
devices. Here, we assume a very simple and low-context flavor of
header compression. Whereas this works independently of flows
(potentially several), it does not use any context specific to any
flow. Thus, it cannot achieve as much compression as schemes that
build separate context for each flow to be compressed.
Given the very limited packet sizes, it is highly desirable to
integrate layer 2 with layer 3 compression, something
traditionally not done (although now changing due to the ROHC
working group).
It is expected that IEEE 802.15.4 devices will be deployed in
multi-hop networks. However, header compression in a mesh departs
from the usual point-to-point link scenario in which the
compressor and decompressor are in direct and exclusive
communication with each other. In an IEEE 802.15.4 network, it is
highly desirable for a device to be able to send header compressed
packets via any of its neighbors, with as little preliminary
context-building as possible.
While we might consider tightening up this language, I think it at
least hints at all the reasons why 6lowpan networks need a static
header compression scheme:
o We really need to compress headers where ever possible, not just in
those cases where existing IETF approaches work (e.g., on
point-to-point links and with flows that are long enough to
create enough state to do the compression).
o 6lowpan devices can't affort to hold much state for any purpose,
much less for dynamic header compression algorithms.
o 6lowpan topologies are likely to be highly dynamic (e.g., most
devices may sleep most of the time). Synchronizing the header
compression state information after, for example, a device
wakes up will probably be much more costly than using a stateless
header compression scheme like that described in the 6lowpan
document.
How is the existing language in the 6lowpan format document fail
to meet what ever objective is embodied in this work item?
I suggest that we:
o Include any necessary justification for a stateless header
compression scheme in the 6lowpan format document, rather than
clutter up the RFC process and repository with another RFC that
doesn't really say very much.
o Figure out whether and how the existing language in the 6lowpan
format document is deficient, and enhance it (if necessary).
(By the way, JPL developed some stateless header compressed
Internet protocols, namely SCPS-NP (IP), SCPS-TP (TCP) and
SCPS-SP (IPsec).)
-tjs
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
