Subject: [6lo] Martin Stiemerling's Block on charter-ietf-6lo-00-04: (with BLOCK)

From: "Martin Stiemerling" <[email-masked]>
Date: Wed, 09 Oct 2013 01:25:10 -0700

Martin Stiemerling has entered the following ballot position for
charter-ietf-6lo-00-04: Block

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/charter-ietf-6lo/

----------------------------------------------------------------------
BLOCK:
----------------------------------------------------------------------

I have no general concern about chartering this WG but I would like to
see a clarification with respect to this point:

"3. Specifications, such as header compression, that are applicable to
more
than one adaptation layer specification"

Has there been any work or concerns discussed to see what's already out
there, e.g., in the old ROHC WG (
https://datatracker.ietf.org/wg/rohc/charter/)?

Especially the documents describing how to do header compression for
various levels in the protocol stack:
https://datatracker.ietf.org/wg/rohc/

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 9 Oct 2013 11:25:11 +0200

Hi Martin,

> https://datatracker.ietf.org/wg/rohc/charter/)?

Good point.
We had a similar discussion during the chartering of 6LoWPAN in 2007.

We had good expertise about ROHC in the 6LoWPAN WG and will have the same in 6lo.

There are significant differences between ROHC's flow-based compression approach and what can be sensibly done on a constrained node.  
(Instead of reciting all the details, let me just attach a little text excerpt from the 6lowpan book.)

In 6LoWPAN, this led us to develop stateless header compression (RFC 4944) and later header compression relying on global state only (RFC 6282).  The 6lo work is meant to continue this simple approach.

> https://datatracker.ietf.org/wg/rohc/

As with ROHC, this is about header compression in the adaptation layer.

The ROHC profiles encode a lot of knowledge on the details of the protocols above IP (TCP, RTP, but also ESP), so it was a natural fit to do that work in TSV.
So far, in 6LoWPAN header compression we have just a very small dependency on UDP itself.
Other above-IP protocols are planned to be addressed by 6lo work such as GHC (DTLS, ICMP), but mainly in the form of benchmarking the still very basic compression scheme against them, not in the form of interacting intricately with them like in ROHC.

It is probably worth to point out that DICE is also looking at ways to encode DTLS in a more compact way, which could be used both as an alternative end-to-end packet encoding and as part of an adaptation layer header compression scheme.  We'll need to coordinate this closely with what 6lo does in this space.  

Grüße, Carsten

(from the 6LoWPAN book:)

The ROHC standards and its predecessors focus on compressing flows of packets, such as the sequence of packets from a single TCP connection or an RTP stream. They expend considerable complexity for compressing the full stack of headers (IP/TCP or IP/UDP/RTP, possibly with embedded extension headers) down to a very small, usually single-digit number of bytes. This works by setting up flow state for each new connection/stream, and stepping through a set of compression states during the exchange of the initial packets of the flow until a high level of compression is attainable.

The main problem that flow-based header compression needs to solve is that the per-flow state, the context, is likely to get out of sync between the sender and the receiver when packets get lost. Various techniques such as positive acknowledgments or optimistic compression with checksums and negative acknowledgments either avoid progressing the context state in this case or allow quick recovery (robustness).

While significant efficiencies can be reaped for long-running flows such as Voice over IP, the required complexity to achieve these gains ranks ROHC among the top dozen most complex IETF protocols just judging from specification size, in the same league with SIP [RFC3162], NFSv4 [RFC3530], IOTP [RFC2801], iSCSI [RFC3720], IPP [RFC2911], OSPF [RFC2328] etc. A protocol of this complexity was judged inappropriate for the resource-constrained systems envisaged in a LoWPAN.

Instead, the original 6LoWPAN format standard exclusively employs stateless compression, see Section 2.6.1. Without state, there is no synchronization problem, and the algorithms become very simple.
[...]
Unfortunately, there is no way to compress the large globally routable IPv6 addresses without at least some state. The 6LoWPAN WG has therefore agreed to standardize a second header compression method, context-based header compression with a slowly evolving global context, discussed in Section 2.6.2, with a view to deprecating the stateless-only header compression scheme once context-based compression is completed.

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 09 Oct 2013 11:55:26 +0200

Hi Carsten,

This helps me a lot :)

Can we refine the bullet to this text:
NEW
"3. Specifications, such as stateless or globale state only header 
compression, that are applicable to more than one adaptation layer 
specification"

Probably adding the references to it would be good too.

   Martin

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Oct 2013 09:04:15 -0400

> https://datatracker.ietf.org/wg/rohc/charter/)?

The header compression we're talking about has already been developed in 6lowpan; 6lo is just intended to continue along that trend.  If you take the bullet item you are commenting on out of the context of the rest of the charter, I could see the cause for the concern you have raised, but if you consider it in the context of the first hunk of text in the charter, and the paragraph following the numbered list, I think it's clear that it's just talking about more of the same work that was done in 6lowpan.

It's also worth noting that Carsten Bormann was the chair of 6lowpan, tech advisor to RoHC, and has been instrumental in forming the 6lo working group, so from that perspective as well I doubt that the work done in RoHC will be lost or ignored by 6lo.

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 10 Oct 2013 12:56:42 +0200

On 10/09/2013 03:04 PM, Ted Lemon wrote:
>> Has there been any work or concerns discussed to see what's already
>> out there, e.g., in the old ROHC WG (
> The header compression we're talking about has already been developed
> in 6lowpan; 6lo is just intended to continue along that trend.  If
> you take the bullet item you are commenting on out of the context of
> the rest of the charter, I could see the cause for the concern you
> have raised, but if you consider it in the context of the first hunk
> of text in the charter, and the paragraph following the numbered
> list, I think it's clear that it's just talking about more of the
> same work that was done in 6lowpan.

If it has been done in 6lowpan and it has a name, why not reusing the 
name in the charter to make it clear what out of the large field of 
header compression is meant?

>
> It's also worth noting that Carsten Bormann was the chair of 6lowpan,
> tech advisor to RoHC, and has been instrumental in forming the 6lo
> working group, so from that perspective as well I doubt that the work
> done in RoHC will be lost or ignored by 6lo.

I know, as I have been working on rohc too in some old ages.

   Martin

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 10 Oct 2013 14:45:11 +0200

On Oct 10, 2013, at 12:56, Martin Stiemerling <[email-masked]> wrote:

> If it has been done in 6lowpan and it has a name, 

It doesn't really have a proper name.
Saying "stateless and global-state-only header compression" is descriptive of the current approaches, but not really making the point properly (we might even invent a third approach).

If we want to give it a name, how about "low-complexity header compression".

Grüße, Carsten

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 10 Oct 2013 17:27:29 +0200

On 10/10/2013 02:45 PM, Carsten Bormann wrote:
> It doesn't really have a proper name. Saying "stateless and
> global-state-only header compression" is descriptive of the current
> approaches, but not really making the point properly (we might even
> invent a third approach).
>

that would work for me!

Thanks,

   Martin

---

From: Ulrich Herberg <[email-masked]>
Date: Thu, 10 Oct 2013 08:36:21 -0700

Sounds good to me. This would result in:

=================
OLD
3. Specifications, such as header compression, that are applicable to more
than one adaptation layer specification

NEW
3. Specifications, such as low-complexity header compression, that are
applicable to more than one adaptation layer specification
=================

Regards
Ulrich

Ulrich

On Thu, Oct 10, 2013 at 8:27 AM, Martin Stiemerling <[email-masked]> wrote:
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: Martin Stiemerling <[email-masked]>
Date: Thu, 10 Oct 2013 17:38:01 +0200

> Sounds good to me. This would result in:

Yes, that's it!

I will remove my block once the update of the text is made.

Thank you,

   Martin