Subject: [6lowpan] context information

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 26 Nov 2008 09:26:58 +0100

Dear lowpanners

Draft -03 says:

    How the shared context is assigned and managed is beyond
    the scope of this document.

In fact, all HC needs is that the information necessary to expand the
addresses is present in the context table and indexed by information in
the packet (interface ID, source/dest short addresses, context ID or
default).

So HC would work in different environments, for instance:
- only a default context and but a table indexed by short addresses
- multiple contexts but just one prefix per context
- multiple interfaces, one prefix per interface

There's no point in enforcing any of these case in the spec. I wish to
add this text:

    The information that is maintained in that shared context is out of
scope.

Resulting in:

2.1.2.  Context Identifier Extension

   This specification expects that a concept of context is shared
   between the node that compresses a packet and the node(s) that need
   to expand it.  The specification enables a node to use of up to 16
   contexts.  How the contexts are shared and maintained is out of
   scope.  What the context information is is out of scope.  Actions in
   response to unknown and/or invalid contexts are out of scope.

What do you think?

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

---

From: Zach Shelby <[email-masked]>
Date: Wed, 26 Nov 2008 10:31:54 +0200

Pascal,

I support this approach, the added text is enough to clarify this.

- Zach

-- 

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti
FINLAND

mobile: +358 40 7796297

This e-mail and all attached material are confidential and may contain 
legally privileged information. If you are not the intended recipient, 
please contact the sender and delete the e-mail from your system without 
producing, distributing or retaining copies thereof.
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Nov 2008 09:43:43 +0100

On Nov 26, 2008, at 09:26 , Pascal Thubert (pthubert) wrote:

> What the context information is is out of scope.  Actions in

A couple of things:

We need to decide whether "the context" is singular or plural.
I.e., is the context the information shared in the lowpan or is the  
information shared in the lowpan structured into multiple contexts.

Second, "What the context information is is out of scope" will only  
work insofar as HC is not concerned.
HC needs 16 byte strings, indexed by a number from 0 to 15.  This  
clearly defines "What the context information is" to a certain extent.

I would prefer to state this as an interface to the context, as in:

   This specification can make use of some form of context that is
   shared between the node that compresses a packet and the node(s)
   that need to decompress it.  The specification enables a node to
   obtain up to 16 values from this context, indexed by a number from 0
   to 15, each containing a byte string of 0 to 16 bytes.  How the
   context is shared and maintained, including its representation, is
   out of scope.

I don't know what the following is supposed to mean:

   Actions in response to unknown and/or invalid contexts are out of
   scope.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 26 Nov 2008 09:52:19 +0100

Hi Carsten:

I agree that we only need define the interface to the context db.
That's what I'm trying to do as well.

>clearly defines "What the context information is" to a certain extent.

I disagree that the specification can only extract 16 values. The
specification can only pass 16 context IDs but the parameters in
interface do not have to be limited to the context ID.
We have short addresses, long addresses, network interface ID, etc...

That's why I say it's out of scope. 

>   Actions in response to unknown and/or invalid contexts are out of
This is a spec about a compression mechanism. The ICMP error and such
stuff when the context is invalid should be defined in the context spec.

Pascal

>-----Original Message-----
>From: Carsten Bormann [mailto:[email-masked]]
>Sent: mercredi 26 novembre 2008 09:44
>To: Pascal Thubert (pthubert)
>Cc: Carsten Bormann; 6lowpan
>Subject: Re: [6lowpan] context information
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 26 Nov 2008 10:36:31 +0100

> We have short addresses, long addresses, network interface ID, etc...

OK, let's try to put this slightly more precisely:

My view:

The context provides a function

     f(CID: 0..15) -> byte-string(0..16)

Your view:

The context provides a function

     f(CID: 0..15, unspecified stuff) -> byte-string(0..16)

While this sure can be made to work, my "interoperability nightmare"  
bell just went on.

But in any case, there *is* a defined interface, except that your  
version has this additional set of unspecified parameters.
Can you explain what you would use it for?
How do you make sure "unspecified stuff" is the same at compressor and  
decompressor?

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 26 Nov 2008 10:58:11 +0100

Hi Carsten:

The way I see it, the  f(CID: 0..15, unspecified stuff) ->
byte-string(0..16) must be specified somewhere and used homogeneously
within an environment. 

But HC does not have to imply what f is. There can be RFC f1, RFC f2
etc... and HC will work for them all. A given deployment will have to
select which fx is used.

Pascal

>Sent: mercredi 26 novembre 2008 10:37

---

From: Kris Pister <[email-masked]>
Date: Wed, 26 Nov 2008 11:11:36 -0800

Pascal et al. -
can you clarify the role of contexts relative to (vs.) the IPv6 flow label?
It seems to me that we are talking about establishing contexts that will 
be appropriate for certain kinds of flows.
For most applications today, and certainly many applications in the 
future, the overwhelming majority of packets flow multi-point to point.  
If I understand what you're doing, this type of flow would likely have a 
single context, and there wouldn't be too much overhead to set it up and 
maintain it, and I'd be able to do pretty good header compression as a 
result of that.
But wouldn't the same be true if I just used a flow label?  I think that 
I'd get all of the benefits of the existing context proposal, and on top 
of that be able to elide almost everything after the flow label.
Flow setup and maintenance should be the same as with contexts (I think?).
Maybe this makes Carsten happier too, since f(flow label) --> 
everything, and the setup and maintenance has to explicitly define that 
mapping.

ksjp

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 27 Nov 2008 12:45:58 +0100

Hi Carsten:

Since we seem to agree that what we need to define is the interface to
the 
context as opposed to the context content or management, let me propose 
this change: 

   This specification expects that an abstract set of states called
   contexts is shared between the node that compresses a packet and the
   node(s) that need to expand it.  The specification enables to
   transport an opaque index that is used to lookup the abstract context
   database.  The index in encoded with 4 bits enabling to address up to
   16 contexts.

   This specification requires that services associated to the abstract
   context database implement an interface to the 6LoWPAN compressor to
   help compress and uncompress an address based on the parameters
   passed by the compressor and the information in the abstract context
   database.

   The interface MUST provide the methods to lookup a context ID from a
   prefix and a prefix length for encoding, and reversely lookup a
   prefix and a prefix length from a context ID for decoding.

   How the contexts are shared and maintained is out of scope.  The
   actual context information is out of scope.  Actions in response to
   unknown and/or invalid contexts are out of scope.

   The interface might be extended to allow for further stateful
   compression, for instance for SAC = 11, additional context
   information might be used to store the full IPv6 address using the
   Link layer Address as an additional index.

What do you think?

Pascal

---

From: Kris Pister <[email-masked]>
Date: Sat, 29 Nov 2008 14:12:14 -0800

Pascal - I think that all of the text below works if we add "flow label" 
to the last sentence of the
first paragraph.
        The index is encoded with either 4 bits or a 20 bit flow label.

ksjp

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 1 Dec 2008 08:08:46 +0100

Hi Kris

Sure works as an encoding technique; but I have issues with using the flow label for 6LoWPAN encoding:

The flow label was initially defined to flag flows that require specific routing/forwading, and such needs might be present in sensors. For instance, ISA has states in forwarding nodes that are indexed by the flow label. Note that ISA100.11a does not use context so allowing flow label to also index the context would not be an issue for that specific standard. 

Since 2460, there have been a number of attempts to define the flow label to do this or that. This seems to boil down to packet classification with RFC 3697, which specifies to use different flow labels for unrelated transport connections.

The format of the flow label is not adapted to the task. We discussed that 16 was a fair number, though some people wanted less than that. 20 bits is certainly a waste, we can't use them all. Now we could structure the flow label and impose that to the future generations bit do we really need that?

What I think is that the flow label belongs to the endpoints upper layers, not 6LoWPAN. Th eendpoint stack should not have to worry whether there is a 6LoWPAN hop on the way to figure out how to use the flow label. At the moment, we defined an octet that belongs to 6LoWPAN for 6LoWPAN use in 6LoWPAN headers. I think it is a cleaner layered approach.

What do you think?

Pascal
________________________________________
From: Kris Pister [mailto:[email-masked]] 
Sent: samedi 29 novembre 2008 23:12
To: Pascal Thubert (pthubert)
Cc: Carsten Bormann; 6lowpan
Subject: Re: [6lowpan] context information

Pascal - I think that all of the text below works if we add "flow label" to the last sentence of the
first paragraph.
        The index is encoded with either 4 bits or a 20 bit flow label.

ksjp

What do you think?

Pascal

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: mercredi 26 novembre 2008 10:37
To: Pascal Thubert (pthubert)
Cc: Carsten Bormann; 6lowpan
Subject: Re: [6lowpan] context information

Second, "What the context information is is out of scope" will only
work insofar as HC is not concerned.
HC needs 16 byte strings, indexed by a number from 0 to 15.  This
clearly defines "What the context information is" to a certain
extent.

My view:

Your view:

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 1 Dec 2008 09:01:17 +0100

> flow label

Fundamentally, we have to decide whether we want to do flow-based  
compression in 6lowpan or not.
There is significant previous work in the IETF on flow-based header  
compression, but the flows were different (mostly RTP streams in RFC  
3095/5225 and TCP connections in RFC 4996) from what I'd expect in a  
6lowpan, with significant complexity in the header compression scheme.
Note that much of the complexity comes from maintaining per-flow  
context state, assuring that that state is updated in sync between  
compressor and decompressor, and robustly dealing with failures in  
that synchronization.

The whole idea of CBHC was to avoid the complexity of per-flow state.
Instead we went for a mostly constant, per-lowpan context state, with  
an independent dissemination protocol in mind (which we now have as  
part of 6lowpan-nd).

On one hand, it is a good idea to isolate the interface between  
6lowpan-hc and that dissemination protocol.  On the other hand, I'm  
not so sure about creating interfaces in 6lowpan-hc to context state  
maintenance protocols we don't know (and whose properties we don't  
understand).  Using the flow label as an index into the context state  
(which, from 6lowpan-hc's point of view, is specified as an interface  
only) sounds like there is some per-flow state maintenance going on.   
To me it would make much more sense to integrate such a flow-based  
maintenance more closely with (a then quite different form of) 6lowpan- 
hc, as this is less likely to be mostly constant as in the existing  
CBHC approach.  But maybe I'm misunderstanding how a flow label would  
be used.

By the way, we don't have very good ways to compress flow labels in  
6lowpan-hc.  As these are relatively large and constant in a flow,  
they would be prime candidates for compression in a flow-based scheme.
If they are instead to be used as per-flow context identifiers, Pascal  
is probably right that the size of 20 bits is somewhat unmotivated.

Gruesse, Carsten