Subject: [6lowpan] rfc4944, hc and dispatchs

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Thu, 9 Oct 2008 16:09:22 +0200

Hi all,
 
questions about rfc4944 and the new header compression scheme:
- does it officialy deprecate the old header compression scheme?
- are there other things we discovered can be improved or deprecated in
rfc4944?
- regarding hc: after recent discussions, and as we want to keep one
byte only for the new encoding, would it be ok to revise dispatch
values?
I would propose to take two more bits for address compression, hence we
would need 13 bits
 
For now there are 148 dispatch values used, 108 free. I feel the 64 for
"not a lowpan frame" could be replaced by 1, which would mean 85 values
used, 171 free. 
New HC with 13 bits would use 32 of them, leaving 139 reserved...
 
I would propose something like:
00000000 not a lowpan frame                                (1 value)
00000001 ipv6                                                      (1
value)
00000010 escape - additional dispatch byte follows (1 value)
00000011 broadcast                                             (1 value)
000001xx reserved                                               (4
reserved)
00001xxx frag 1                                                   (8
values)
00010xxx frag n                                                   (8
values) 
00011xxx                                                            (8
reserved)
001xxxxx HC                                                       (32)

01xxxxxx mesh                                                   (64)
11xxxxxx                                                            (128
reserved)
 
Note that this way, the reserved blocks are easily usable, meaning that
if you want 32 values, you can have them with the same first 3 bits,
which is not feasible with the dispatchs values from 4944...
 
What do you think?
Cheers,
Julien

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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 Oct 2008 16:42:39 +0200

> - does it officialy deprecate the old header compression scheme?

My impression of the mailing list consensus is that this is what the  
WG wants to achieve.
At the time this was discussed, I cautioned that it is premature to  
decide on replacing something existing with known flaws with something  
not yet quite cooked (and, hence, with unknown flaws).
So I expect we'll ultimately decide this question at the time HC and  
the related specs come up for WGLC.
Clearly, the stated intention of many WG members is to make this  
happen, as it would be wasteful to support two HC schemes in tiny  
implementations.

Gruesse, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 9 Oct 2008 19:41:15 +0200

Hi Carsten:

Some implementations and dependant standards would require a timeline
for this. Leaving it up in the air does not help our users do their
product planning? 

Considering the attention and the work on the new LOWPAN_IPHC, I expect
that we'll be ready for WGLC after 2/3 more respins. That could be
achieved by Minneapolis time if we can rally all interested parties to
comment on the existing published spec. So could you chairs please:

>>>>>>>>>> propose a time line to the WG along those lines <<<<<<<<<<<<
>>>>>>>>>> raise WG attention on this work?                <<<<<<<<<<<<

Also by or at Minneapolis, my sensation is that we should not only
discuss the terms of deprecating RFC 4944 HC but also consider the spec
as a whole:

- Mesh Header is a layer violation. I talked to implementers and their
message is that they do not use it because it's never exactely what that
specific radio needs; so they end up with their own mesh header anyway
and will not duplicate things for the sake of comliance. Instead we
might need a Routing header, pretty useful for source routing in route
over. 

- Fragments are not recovered individually. We have enough experience to
know where that leads should a 6LoWPAN network experience either high
load or high BER. We have a draft on the works to deprecate that with
recoverable fragments.

- The Current HC WG doc covers all the compression cases in RFC 4944,
bigger and badder.

So what's left? 

My proposal is to start a 4944bis that would focus on the addressing
architecture, would be the placeholder to control the dispatch type but
would defer to the drafts/RFCs that actually detail the operation of
each dispatch type. 

What do you think?

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Carsten Bormann
>Sent: jeudi 9 octobre 2008 16:43
>To: Julien Abeille (jabeille)
>Cc: Carsten Bormann; [email-masked]
>Subject: Re: [6lowpan] rfc4944, hc and dispatchs
>

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 9 Oct 2008 12:17:21 -0700

In general, I'm in support of Pascal's proposal. Cleaning up the  
format to use a stacked-header format was just one of the items and  
there were many other things we wanted to fix before pushing out RFC  
4944. But we were far too late to the game in doing a complete  
overhaul of the doc. I think *now* is the time to make improvements to  
RFC 4944.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 10 Oct 2008 17:51:14 +0200

I'm all with you, Jonathan, as long as that does not delay HC. 

This is why I proposed a structured set of document that leaves HC with
its current scope as opposed to making it a full revision of 4944. Makes
sense?

Pascal

>From: Jonathan Hui [mailto:[email-masked]]
>Sent: jeudi 9 octobre 2008 21:17
>To: Pascal Thubert (pthubert)
>Cc: Carsten Bormann; Geoff Mulligan; [email-masked]

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 10 Oct 2008 09:02:25 -0700

Hi Pascal:

I'm for pushing HC through as quickly as possible. We are already  
behind according to the charter text.

The one dependency I see is the structure of the dispatch byte. If we  
choose a dispatch value(s) that is compatible with RFC 4944, then we  
are fine, I think. But if we want extra bits by changing the layout of  
the dispatch values/identifiers for Frag/Mesh headers (as both I and  
Julien have proposed) then this creates a dependency on defining that  
new dispatch assignment scheme.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 10 Oct 2008 18:41:58 +0200

Hi Jonathan

Maybe a good reason to stick to the current format and change the
misleading wording around it, what do you think? In any case, I'm all
for starting 4944bis and recoverable frags today, though.

Pascal

>Sent: vendredi 10 octobre 2008 18:02

---

From: Jonathan Hui <[email-masked]>
Date: Fri, 10 Oct 2008 10:08:37 -0700

Hi Pascal,

Yes, you are right - hc-01 supports all header values (just carry  
everything in-line).

Regarding Julien's comments, I think hc-01 and the format proposed to  
support Julien's cases are straight-forward to implement. I think the  
more important issue is whether Julien's cases will be common in  
6LoWPAN applications. We (Arch Rock) do not commonly use the cases  
that Julien wishes to add compression for. But if Julien/others can  
demonstrate a strong need for them (i.e. cases that will be used  
fairly often in relevant 6LoWPAN applications), then I do think we  
should consider them. Julien, can you explain important commonly used  
cases that would not be supported by hc-01?

--
Jonathan Hui

On Oct 10, 2008, at 9:41 AM, Pascal Thubert (pthubert) wrote:

>>>>> achieved by Minneapolis time if we can rally all interested  
>>>>> parties
>>> to
>>>>> message is that they do not use it because it's never exactely  
>>>>> what
>>>>> that
>>>>> architecture, would be the placeholder to control the dispatch  
>>>>> type
>>>>> but

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 13 Oct 2008 10:13:55 +0200

Hi Jonathan , all,

I do not have particular use cases in mind for specific address types. 

My approach is the following:
- how many bits can we afford?
- with this amount of bits, let's try to support as many IP scenarios as
possible, keeping a low level of complexity and a high level of clarity.

For the first question:
- there are currently around 150/255 dispatch values used. 
- A priori I would be in favor of deprecating some (mesh, not a lowpan
frame), or at least do you agree they are less important than HC. This
would drag the number of values to 25/255
- I do foresee some new 6lowpan specs will take some of them, but not
that many. Do you see anything else appart from fragment recovery?
Hence I am convinced taking 32 values is very acceptable (this is 8 bits
for address compression)
Do you agree with this?

For the second question:
- with 8 bits for address compression, we can do something very clean
and easy to implement, handling all IP addressing scenarios.

I will send today an example on 8bits and pseudo code to be able to
compare 7-bit/8-bit complexity

Regards,
Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Hui
Sent: vendredi 10 octobre 2008 19:09
To: Pascal Thubert (pthubert)
Cc: Carsten Bormann; [email-masked]; Geoff Mulligan
Subject: Re: [6lowpan] rfc4944, hc and dispatchs

Hi Pascal,

Regarding Julien's comments, I think hc-01 and the format proposed to
support Julien's cases are straight-forward to implement. I think the
more important issue is whether Julien's cases will be common in 6LoWPAN
applications. We (Arch Rock) do not commonly use the cases that Julien
wishes to add compression for. But if Julien/others can demonstrate a
strong need for them (i.e. cases that will be used fairly often in
relevant 6LoWPAN applications), then I do think we should consider them.
Julien, can you explain important commonly used cases that would not be
supported by hc-01?

--
Jonathan Hui

>> are fine, I think. But if we want extra bits by changing the layout 
>> of the dispatch values/identifiers for Frag/Mesh headers (as both I 
>> and Julien have proposed) then this creates a dependency on defining 
>> that new dispatch assignment scheme.
>>
>> --
>> Jonathan Hui
>>
>>
>>> This is why I proposed a structured set of document that leaves HC 
>>> with its current scope as opposed to making it a full revision of 
>>> 4944.
>>> Makes
>>> sense?
>>>
>>> Pascal
>>>

>>>> there were many other things we wanted to fix before pushing out 
>>>> RFC 4944. But we were far too late to the game in doing a complete 
>>>> overhaul of the doc. I think *now* is the time to make improvements

>>>> to RFC 4944.
>>>>> Some implementations and dependant standards would require a 
>>>>> timeline for this. Leaving it up in the air does not help our 
>>>>> users do their product planning?
>>>>>
>>>>> Considering the attention and the work on the new LOWPAN_IPHC, I 
>>>>> expect that we'll be ready for WGLC after 2/3 more respins. That 
>>>>> could be achieved by Minneapolis time if we can rally all 
>>>>> interested parties
>>> to

>>>>> discuss the terms of deprecating RFC 4944 HC but also consider the

>>>>> spec as a whole:
>>>>> what that specific radio needs; so they end up with their own mesh

>>>>> header
>>> anyway
>>>>> and will not duplicate things for the sake of comliance. Instead 
>>>>> we might need a Routing header, pretty useful for source routing 
>>>>> in
>>> route
>>>>> over.
>>>>>
>>>>> - Fragments are not recovered individually. We have enough 
>>>>> experience to know where that leads should a 6LoWPAN network 
>>>>> experience either high load or high BER. We have a draft on the 
>>>>> works to deprecate that with recoverable fragments.
>>>>>
>>>>> - The Current HC WG doc covers all the compression cases in RFC 
>>>>> 4944, bigger and badder.
>>>>>
>>>>> So what's left?
>>>>>
>>>>> type but would defer to the drafts/RFCs that actually detail the 
>>>>> operation
> of
>>>>> each dispatch type.
>>>>>
>>>>> What do you think?
>>>>>
>>>>> Pascal
>>>>>
>>>>>> My impression of the mailing list consensus is that this is what 
>>>>>> the WG wants to achieve.
>>>>>> decide on replacing something existing with known flaws with 
>>>>>> something not yet quite cooked (and, hence, with unknown flaws).
>>>>>> So I expect we'll ultimately decide this question at the time HC 
>>>>>> and the related specs come up for WGLC.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 13 Oct 2008 12:15:47 +0200

Hi Julien:

Pseudo code is good. Please remember that the reference is the current
spec, so we need to compare pseudo code of a proposed change with pseudo
code of that reference. In the reference, the compression of the pair of
addresses is specifiied using 6 bits. 

Consuming more and more of the dispatch space:
- multiplies by 2 the number of consumed dispatches each time
- reduces the space allocated for future extensions
- will require a revamp of 4944 right away with no backward
compatibility

It's very hard to reach a solution than will please all for all the
various standpoints and priorities (smaller HC, lmarger coverage,
smaller code, smaller memory...). And we could keep changing these
formats forever. So we need rules and limits, in particular we need to
keep in mind that: 
- Making implementation simpler or smaller is good
- Making the base HC bigger is bad, every bit costs dearly
- Compressing cases for which we have no known usage has very marginal
value.

Would you agree with that?

Pascal

>From: Julien Abeille (jabeille)
>Sent: lundi 13 octobre 2008 10:14
>To: Jonathan Hui; Pascal Thubert (pthubert); Carsten Bormann;
[email-masked]; Geoff Mulligan
>Subject: RE: [6lowpan] rfc4944, hc and dispatchs
>
>Hi Jonathan , all,
>
>- with this amount of bits, let's try to support as many IP scenarios
as possible, keeping a low
>level of complexity and a high level of clarity.
>
>For the first question:
frame), or at least do you
>agree they are less important than HC. This would drag the number of
values to 25/255
>- I do foresee some new 6lowpan specs will take some of them, but not
that many. Do you see anything
>else appart from fragment recovery?
>Hence I am convinced taking 32 values is very acceptable (this is 8
bits for address compression)
>- with 8 bits for address compression, we can do something very clean
and easy to implement, handling
>all IP addressing scenarios.
>
Behalf Of Jonathan Hui
everything in-line).
>Regarding Julien's comments, I think hc-01 and the format proposed to
support Julien's cases are
>straight-forward to implement. I think the more important issue is
whether Julien's cases will be
>common in 6LoWPAN applications. We (Arch Rock) do not commonly use the
cases that Julien wishes to
>add compression for. But if Julien/others can demonstrate a strong need
for them (i.e. cases that
>will be used fairly often in relevant 6LoWPAN applications), then I do
think we should consider them.
supported by hc-01?

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 13 Oct 2008 14:07:38 +0200

Hi Pascal, all,

I comment inline 

-----Original Message-----
From: Pascal Thubert (pthubert) 
Sent: lundi 13 octobre 2008 12:16
To: Julien Abeille (jabeille); 'Jonathan Hui'; 'Carsten Bormann';
[email-masked]'; 'Geoff Mulligan'
Subject: RE: [6lowpan] rfc4944, hc and dispatchs

Hi Julien:

Consuming more and more of the dispatch space:
- multiplies by 2 the number of consumed dispatches each time
- reduces the space allocated for future extensions
[Julien] As I said in my previous email, with all this in mind, I am
convinced we can afford 32 values for HC (this is 13 bits, 5 in the
dispatch, plus one byte)
Do people agree that 32 values for HC is ok?
- will require a revamp of 4944 right away with no backward
compatibility
[Julien] sure, do the chairs or people think we must take this as design
constraint?

It's very hard to reach a solution than will please all for all the
various standpoints and priorities (smaller HC, lmarger coverage,
smaller code, smaller memory...). And we could keep changing these
formats forever. So we need rules and limits, in particular we need to
keep in mind that: 
- Making implementation simpler or smaller is good
- Making the base HC bigger is bad, every bit costs dearly
[Julien] I think that as long as we do not need another BYTE and respect
the maximum limit we fix, adding bits is at the contrary a very good
point for simplicity and implementation size. 
- Compressing cases for which we have no known usage has very marginal
value.
[Julien] As we do not know what the typical usage will be in 12 month, I
would avoid taking this as a design constraint. Again, I propose to make
the best use possible of the bits we have. If do not have enough space
to support some scenarios, then I am ok not to support them.

Regards,
Julien

Pascal

>as possible, keeping a low level of complexity and a high level of
clarity.
>bits for address compression) Do you agree with this?
>
>For the second question:
everything in-line).
>6LoWPAN applications. We (Arch Rock) do not commonly use the cases that

>Julien wishes to add compression for. But if Julien/others can
demonstrate a strong need for them (i.e. cases that will be used fairly
often in relevant 6LoWPAN applications), then I do think we should
consider them.
supported by hc-01?

>>> The one dependency I see is the structure of the dispatch byte. If 
>>> we choose a dispatch value(s) that is compatible with RFC 4944, then

>>> we are fine, I think. But if we want extra bits by changing the 
>>> layout of the dispatch values/identifiers for Frag/Mesh headers (as 
>>> both I and Julien have proposed) then this creates a dependency on 
>>> defining that new dispatch assignment scheme.
>>>
>>> --
>>> Jonathan Hui
>>>
>>>
>>>>> format to use a stacked-header format was just one of the items 
>>>>> and there were many other things we wanted to fix before pushing 
>>>>> out RFC 4944. But we were far too late to the game in doing a 
>>>>> complete overhaul of the doc. I think *now* is the time to make 
>>>>> improvements to RFC 4944.
>>>>>
>>>>> --
>>>>> Jonathan Hui
>>>>>
>>>>>
>>>>>
>>>>>> Also by or at Minneapolis, my sensation is that we should not 
>>>>>> only discuss the terms of deprecating RFC 4944 HC but also 
>>>>>> consider the spec as a whole:
>>>>>>
>>>>>> what that specific radio needs; so they end up with their own 
>>>>>> mesh header
>>>> anyway

>>>>>>> happen, as it would be wasteful to support two HC schemes in 
>>>>>>> tiny implementations.
>>>>>>>
>>>>>>> Gruesse, Carsten
>>>>>>>

---

From: "Julien Abeille (jabeille)" <[email-masked]>
Date: Mon, 13 Oct 2008 14:10:49 +0200

Formatting problem, I resend:

----Original Message-----
From: Pascal Thubert (pthubert)
Sent: lundi 13 octobre 2008 12:16
To: Julien Abeille (jabeille); 'Jonathan Hui'; 'Carsten Bormann';

[Julien] As I said in my previous email, with all this in mind, I am
convinced we can afford 32 values for HC (this is 13 bits, 5 in the
dispatch, plus one byte) Do people agree that 32 values for HC is ok?

Regards,
Julien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Abeille (jabeille)
Sent: lundi 13 octobre 2008 14:08
To: Pascal Thubert (pthubert); Jonathan Hui; Carsten Bormann;
[email-masked]; Geoff Mulligan
Subject: Re: [6lowpan] rfc4944, hc and dispatchs

Hi Pascal, all,

I comment inline 

-----Original Message-----
From: Pascal Thubert (pthubert)
Sent: lundi 13 octobre 2008 12:16
To: Julien Abeille (jabeille); 'Jonathan Hui'; 'Carsten Bormann';

Hi Julien:

Consuming more and more of the dispatch space:
- multiplies by 2 the number of consumed dispatches each time
- reduces the space allocated for future extensions [Julien] As I said
in my previous email, with all this in mind, I am convinced we can
afford 32 values for HC (this is 13 bits, 5 in the dispatch, plus one
byte) Do people agree that 32 values for HC is ok?
- will require a revamp of 4944 right away with no backward
compatibility [Julien] sure, do the chairs or people think we must take
this as design constraint?

It's very hard to reach a solution than will please all for all the
various standpoints and priorities (smaller HC, lmarger coverage,
smaller code, smaller memory...). And we could keep changing these
formats forever. So we need rules and limits, in particular we need to
keep in mind that: 
- Making implementation simpler or smaller is good
- Making the base HC bigger is bad, every bit costs dearly [Julien] I
think that as long as we do not need another BYTE and respect the
maximum limit we fix, adding bits is at the contrary a very good point
for simplicity and implementation size. 
- Compressing cases for which we have no known usage has very marginal
value.
[Julien] As we do not know what the typical usage will be in 12 month, I
would avoid taking this as a design constraint. Again, I propose to make
the best use possible of the bits we have. If do not have enough space
to support some scenarios, then I am ok not to support them.

Regards,
Julien

Pascal

clarity.
everything in-line).

supported by hc-01?

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 13 Oct 2008 17:29:38 +0200

Hi Julien:

I suspect that the typical usage of IPv6 addresses in LoWPAN next year
will not be that different from the typical usages of IPv6 addresses
today; in particular the matching between source and destination scopes
that the draft supports is very classical to what SAS does though some
applications like ping will enable otherwise.

What is a lot less clear to me is the usage of other fields, RH, options
headers, etc... Additional dispatch bits might become handy when we
figure that out and I'd not lock too many of them if we can avoid that.

Like I said we have a reference. If you show clear improvement for
acceptable cost, then I'm sure the group will be interested. Let's see
what the clear improvement comes first, and then we'll see if the cost
is acceptable for that improvement. In particular, I'd wish to
understand the benefits on the resulting implementation.

Pascal

>Sent: lundi 13 octobre 2008 14:11
>To: Julien Abeille (jabeille); Pascal Thubert (pthubert); Jonathan Hui;
Carsten Bormann;
>To: Julien Abeille (jabeille); 'Jonathan Hui'; 'Carsten Bormann';
[email-masked]'; 'Geoff
>Mulligan'
convinced we can afford 32
>values for HC (this is 13 bits, 5 in the dispatch, plus one byte) Do
people agree that 32 values for
>HC is ok?
compatibility
>
>[Julien] sure, do the chairs or people think we must take this as
design constraint?
>It's very hard to reach a solution than will please all for all the
various standpoints and
>priorities (smaller HC, lmarger coverage, smaller code, smaller
memory...). And we could keep
>changing these formats forever. So we need rules and limits, in
particular we need to keep in mind
>that:
>[Julien] I think that as long as we do not need another BYTE and
respect the maximum limit we fix,
>adding bits is at the contrary a very good point for simplicity and
implementation size.
value.
>
>[Julien] As we do not know what the typical usage will be in 12 month,
I would avoid taking this as a
>design constraint. Again, I propose to make the best use possible of
the bits we have. If do not have
>enough space to support some scenarios, then I am ok not to support
them.
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Julien Abeille
>(jabeille)
>To: Julien Abeille (jabeille); 'Jonathan Hui'; 'Carsten Bormann';
[email-masked]'; 'Geoff
>Mulligan'
spec, so we need to compare
>pseudo code of a proposed change with pseudo code of that reference. In
the reference, the
>compression of the pair of addresses is specifiied using 6 bits.
>
>
in my previous email, with all
>this in mind, I am convinced we can afford 32 values for HC (this is 13
bits, 5 in the dispatch, plus
>one byte) Do people agree that 32 values for HC is ok?
compatibility [Julien] sure, do the
>chairs or people think we must take this as design constraint?
>
various standpoints and
>priorities (smaller HC, lmarger coverage, smaller code, smaller
memory...). And we could keep
>changing these formats forever. So we need rules and limits, in
particular we need to keep in mind
>that:
think that as long as we do not
>need another BYTE and respect the maximum limit we fix, adding bits is
at the contrary a very good
value.
>[Julien] As we do not know what the typical usage will be in 12 month,
I would avoid taking this as a
>design constraint. Again, I propose to make the best use possible of
the bits we have. If do not have
>enough space to support some scenarios, then I am ok not to support
them.
that
>demonstrate a strong need for them (i.e. cases that will be used fairly
often in relevant 6LoWPAN
>applications), then I do think we should consider them.
>>>>>>>> From: [email-masked]
[mailto:[email-masked]]
>>> On
>>>>>>>> At the time this was discussed, I cautioned that it is
premature