Subject: [6lowpan] Size of NS+ARO+SLLAO in nd-10

From: Zach Shelby <[email-masked]>
Date: Tue, 6 Jul 2010 11:52:28 +0300

Looking through ND-10 I think we are getting pretty close to our limits in the size of NS/NA+ARO+SLLAO. 

NS/NA = 24 octets
ARO = 16-32 octets
SLLAO = 8-16 octets

Best case  = 48 octets
Worst case = 72 octets

We have a request from e.g. backbone-router-02 to add a new 16-bit TID field to ARO, and this is just one example for the future. There may be other options to be carried in the NS as well. Is there anything we can/should do to reduce the worst case for NS/NA? Some random thoughts:

1. What is Target Address in our unicast NS/NAs actually being used for right now? Why don't we put the Registered Address there instead of in the ARO option? That would save 16 octets.

2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10 second granularity. That frees up 16-bits of reserved space.

3. Change the Length of ICMPv6 options to 4 byte granularity. Would save size in SLLAO for 16-bit addresses at least. Likely would save in other options as well. 

4. Make use of the 32-bits of reserved NS/NA space? I would rather not start to re-define the NS/NA message though...

Other ideas, thoughts? 

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Daniel Gavelle <[email-masked]>
Date: Tue, 06 Jul 2010 10:36:18 +0100

Zach,

I like the idea of saving bits on the registration time.  The DAD table 
also needs to hold a registration time for every node on the network so 
reducing the lifetimes to 16 bits would save e.g. 1K of RAM on a 500 
node network.

I also think a strict specification of the target address would be 
useful in saving bytes and avoiding duplication of an address in the ARO.

I am not so keen on options 3 and 4 as they are changing the meaning of 
the fields in RFC4861.

I also noticed an RA is fragmented at the 6LowPAN layer when I include a 
112 bit CO.  Some savings here would be useful, especially allowing 
context zero to be specified by a flag in the PIO.

We could also save some space by eliding the sllao and tllao from the 
Layer 2 MAC address.  We elide addresses from the layer 2 in 6LowPAN. 
However, this isn't generic for all MACs so this optimisation is only 
valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than 
a generic ND for LLNs.

Daniel.

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________

---

From: "Colin O'Flynn" <[email-masked]>
Date: Tue, 6 Jul 2010 10:57:24 +0100

Hello,

> I like the idea of saving bits on the registration time.

Agreed, I see lots of benefits there (smaller message, less RAM on host, and
realistically I doubt you'd ever need below 10 seconds granularity).  

> I am not so keen on options 3 and 4 as they are changing the meaning of 

Also agree here as well. I could be swayed for option 3, I'm just not sure
it's worth the possible battle over changing already defined meanings. 

> valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than 

Should optimizations like this (eliding options, etc) go at the 6LoWPAN
layer itself? e.g.: like how there is UDP compression for 6LoWPAN, there
could also be a ICMPv6 compression header. 

I'm not sure if that's pushing us into "layer hell" and needlessly
complicating things; I get the feeling it is. After all the draft itself is
called "6lowpan-nd", so presumably we can assume 6lowpan is below us?

On the other hand a suitably designed generic 6lowpan ICMPv6 compression
header could work without 6lowpan-nd even if someone wishes to do so. This
would allow eliding/compressing options if possible, without needing to
think too much at higher layers.

This could include compressing IP addresses inside options for instance in a
similar matter to addresses being compressed in the IPv6 header.

Regards,

  -Colin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Daniel Gavelle
Sent: July 6, 2010 10:36 AM
To: Zach Shelby
Cc: 6lowpan
Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10

Zach,

Daniel.

Zach Shelby wrote:
> We have a request from e.g. backbone-router-02 to add a new 16-bit TID
field to ARO, and this is just one example for the future. There may be
other options to be carried in the NS as well. Is there anything we
can/should do to reduce the worst case for NS/NA? Some random thoughts:
> 
> 1. What is Target Address in our unicast NS/NAs actually being used for
right now? Why don't we put the Registered Address there instead of in the
ARO option? That would save 16 octets.
> 
> 2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10 second
granularity. That frees up 16-bits of reserved space.
> 
> 3. Change the Length of ICMPv6 options to 4 byte granularity. Would save
size in SLLAO for 16-bit addresses at least. Likely would save in other
options as well. 
> 
> 4. Make use of the 32-bits of reserved NS/NA space? I would rather not
start to re-define the NS/NA message though...

-- 
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371  Registered In England
http://www.jennic.com
__________________________________________________
_______________________________________________
6lowpan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lowpan

---

From: Zach Shelby <[email-masked]>
Date: Tue, 6 Jul 2010 13:56:26 +0300

On Jul 6, 2010, at 12:36 PM, Daniel Gavelle wrote:

> Zach,
> 
> I like the idea of saving bits on the registration time.  The DAD table also needs to hold a registration time for every node on the network so reducing the lifetimes to 16 bits would save e.g. 1K of RAM on a 500 node network.

In that case the Valid Lifetime field in 6CO should be changed to 16-bits with 10 second resolution as well. I agree this does save RAM space both on routers and border routers. 32-bit values are not efficient to deal with on 8-bit and 16-bit micro-controllers either. 

> I also think a strict specification of the target address would be useful in saving bytes and avoiding duplication of an address in the ARO.

Exactly, this would be a huge savings if there is no other real use of the Target Address (I can't think of any for our case, but might be missing something).

> I am not so keen on options 3 and 4 as they are changing the meaning of the fields in RFC4861.

Like it said, random thoughts ;-) Let's just forget I mentioned 3 and 4.

> I also noticed an RA is fragmented at the 6LowPAN layer when I include a 112 bit CO.  Some savings here would be useful, especially allowing context zero to be specified by a flag in the PIO.

We really can't mess with PIO, but how about this. We make a rule that is a single PIO is present in an RA, then it is assumed that this is CID=0 by default. 

> We could also save some space by eliding the sllao and tllao from the Layer 2 MAC address.  We elide addresses from the layer 2 in 6LowPAN. However, this isn't generic for all MACs so this optimisation is only valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than a generic ND for LLNs.

The title is "Neighbor Discovery Optimization for Low Power and Lossy Networks" - and I think that is the right direction. 6LoWPAN is our most important LLN here, but these optimizations could be applied elsewhere also. This will be important in moving this through the IESG as well I guess.

Including the SLLAO in ND messages allows a priori L2 information to be exchanged between neighbors. The SLLAO/TLLAO are used for multihop DAD as well so that the 6LR doesn't have to save temporary state during DAD. I am not sure how well it would work to elide the SLLAO/TLLAO - it is more straightforward to have it always there (a clear MUST rather than a SHOULD...).

Zach

> 
> Daniel.
> 
> Zach Shelby wrote:
>> Looking through ND-10 I think we are getting pretty close to our limits in the size of NS/NA+ARO+SLLAO. NS/NA = 24 octets
>> ARO = 16-32 octets
>> SLLAO = 8-16 octets
>> Best case  = 48 octets
>> Worst case = 72 octets
>> 3. Change the Length of ICMPv6 options to 4 byte granularity. Would save size in SLLAO for 16-bit addresses at least. Likely would save in other options as well. 4. Make use of the 32-bits of reserved NS/NA space? I would rather not start to re-define the NS/NA message though...
>> Other ideas, thoughts? Zach
> 
> --

---

From: Zach Shelby <[email-masked]>
Date: Tue, 6 Jul 2010 14:02:57 +0300

> I like the idea of saving bits on the registration time.  The DAD table also needs to hold a registration time for every node on the network so reducing the lifetimes to 16 bits would save e.g. 1K…

Same goes for the ABRO Version Number, no reason why this should be a 32-bit value. 16-bit would be better.

Zach

---

From: Daniel Gavelle <[email-masked]>
Date: Tue, 06 Jul 2010 12:24:37 +0100

If there are multiple LBR's, with different PIO's, the network still 
needs a single CO.  For example, a possible Smart Grid network would be 
to have: An LBR in the meter with a PIO of the back haul to the utility 
and a prefix assigned by the utility.  A second LBR in a broadband 
router with general access to the Internet and a prefix assigned by an 
ISP.  The LBRs would need to be configured to cooperate correctly so 
there is only one set of context information in the network but each LBR 
may be advertising a different PIO.

I am not sure in this case if both LBRs advertise both PIO's or each 
advertises its own PIO.  If both advertise both PIOs, the optimisation 
is lost and the CO needs to be carried explicitly.  If each just 
advertises its own PIO, there is potential for confusion as two 
different default COs may be derived.

Daniel.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 6 Jul 2010 13:29:32 +0200

Hi Daniel:

This sort of scenario is handled in RPL by the concept of instances.
Basically, what
you are describing would be mapped in 2 different instances, and each
one 
would have a context that is scoped in the instance.

Pascal

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Daniel Gavelle
> Sent: Tuesday, July 06, 2010 1:25 PM
> To: Zach Shelby
> Cc: 6lowpan
needs a
> single CO.  For example, a possible Smart Grid network would be to
have: An
> LBR in the meter with a PIO of the back haul to the utility and a
prefix
> assigned by the utility.  A second LBR in a broadband router with
general
> access to the Internet and a prefix assigned by an ISP.  The LBRs
would need
> to be configured to cooperate correctly so there is only one set of
context
> information in the network but each LBR may be advertising a different
PIO.
> I am not sure in this case if both LBRs advertise both PIO's or each
advertises
> its own PIO.  If both advertise both PIOs, the optimisation is lost
and the CO
> needs to be carried explicitly.  If each just advertises its own PIO,
there is
> potential for confusion as two different default COs may be derived.
> 
> Daniel.
> 
> 
> 
> >
> > We really can't mess with PIO, but how about this. We make a rule
that is a
> single PIO is present in an RA, then it is assumed that this is CID=0
by default.
> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No:
3191371
> Registered In England http://www.jennic.com

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 6 Jul 2010 12:21:46 -0700

Hi Daniel,

A single Context Info option (CO) is needed indeed for a 6lowpan network for
consistency, I agree.
If this is not clear, we would clarify - perhaps in the assumption section.

Thanks,
-Samita

> Sent: Tuesday, July 06, 2010 4:25 AM
> To: Zach Shelby
> Cc: 6lowpan
> If there are multiple LBR's, with different PIO's, the network still needs
a
> single CO.  For example, a possible Smart Grid network would be to have:
An
> LBR in the meter with a PIO of the back haul to the utility and a prefix
> assigned by the utility.  A second LBR in a broadband router with general
> access to the Internet and a prefix assigned by an ISP.  The LBRs would
need
context
PIO.
> advertises its own PIO.  If both advertise both PIOs, the optimisation is
> lost and the CO needs to be carried explicitly.  If each just advertises
its
> own PIO, there is potential for confusion as two different default COs may
> be derived.
> 
> Daniel.
> 
> 
> 
> >
> > We really can't mess with PIO, but how about this. We make a rule that
is
> a single PIO is present in an RA, then it is assumed that this is CID=0 by
> default.
> >
> 
> --
> Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK Comp Reg No: 3191371

---

From: "Samita Chakrabarti" <[email-masked]>
Date: Tue, 6 Jul 2010 14:06:16 -0700

> We have a request from e.g. backbone-router-02 to add a new 16-bit TID
field
> to ARO, and this is just one example for the future. There may be other
> options to be carried in the NS as well. Is there anything we can/should
do
> to reduce the worst case for NS/NA? Some random thoughts:
> 
[SC>]  It is overloading the NUD operation. It is doable, but then DAD
option is not distinguishable by len=4. We have to then introduce some bit
for DAD operation.

> granularity. That frees up 16-bits of reserved space.
[SC>] 

 Option 2 is OK w/me.

 I am reluctant about adventuring on options 3 and 4 below.

Thanks,
-Samita

> 4. Make use of the 32-bits of reserved NS/NA space? I would rather not
start
> to re-define the NS/NA message though...
> 
> Other ideas, thoughts?
> 
> Zach
> 
> --

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 06 Jul 2010 18:09:34 -0700

> Looking through ND-10 I think we are getting pretty close to our limits in the size of NS/NA+ARO+SLLAO.

This is fixed at 16 for registrations. 32 is only for multi-hop DAD. If 
we want to optimize the multi-hop DAD case then I suggest we do a 
separate message instead of reusing NS/NA. (The target address is 
effectively unused in the special multi-hop DAD use of NS/NA.)

> Worst case = 72 octets

If we ignore multihop DAD, then the worst case is 56.

> We have a request from e.g. backbone-router-02 to add a new 16-bit
> TID field to ARO, and this is just one example for the future.

A TID doesn't seem to solve the problem; seems to need a 3-way 
handshake. But I get the general question about understanding how things 
might be extended.

> There
> may be other options to be carried in the NS as well. Is there
> anything we can/should do to reduce the worst case for NS/NA? Some
> random thoughts:
>
> 1. What is Target Address in our unicast NS/NAs actually being used
> for right now? Why don't we put the Registered Address there instead
> of in the ARO option? That would save 16 octets.

True for multi-hop DAD. But for the normal registrations the registered 
address is in the IPv6 source field.
We could create a NS' and NA' messages that do not contain the target 
address and save 16 bytes for the NS/NA registrations. But that means a 
new pair of message types and less interoperability with 4861.

We could go back to that approach, but first we need to make sure we 
would be converging instead of oscillating if we go back.

> 2. Reduce the size of Registration Lifetime to 16-bits with e.g. 10
> second granularity. That frees up 16-bits of reserved space.

Doesn't hurt to change this.

> 3. Change the Length of ICMPv6 options to 4 byte granularity. Would
> save size in SLLAO for 16-bit addresses at least. Likely would save
> in other options as well.

No more ND interoperability.

> 4. Make use of the 32-bits of reserved NS/NA space? I would rather
> not start to re-define the NS/NA message though...

I think you already in essence proposed that in #1 ;-)

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 06 Jul 2010 18:13:02 -0700

> valid if we are creating a 6LowPAN-ND for 15.4 networks only rather than

I don't think we need TLLAO anywhere in the spec, but the document 
doesn't say anything about this.

We could in theory apply this to the SLLAO in NS, RS and RA. My question 
is whether we expect all receiver implementations to be able to get at 
the layer 2 address. If not, then we'd need some form of capability 
exchange to determine whether a receiver can handle the elided SLLAO. 
That would seem like lots of extra complexity.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 06 Jul 2010 18:18:15 -0700

On 07/ 6/10 04:24 AM, Daniel Gavelle wrote:
> and a prefix assigned by the utility. A second LBR in a broadband router
> with general access to the Internet and a prefix assigned by an ISP. The
> LBRs would need to be configured to cooperate correctly so there is only
> one set of context information in the network but each LBR may be
> advertising a different PIO.
>
> its own PIO, there is potential for confusion as two different default
> COs may be derived.

The fundamental issues around such deployments are business issues. 
Suppose one could get all the technical matters worked out, and then one 
day I find that the network is not working. Do I call the Electrical 
Company or the ISP? What prevents their support lines from just pointing 
fingers at the other company?

On the technical side there are issues even if CO isn't used. For 
instance, I expect the service providers to follow best security 
practices and do ingress filtering on the source addresses. That means 
that if a host picks a source address from the ISP prefix, then those 
packets better go out via the ISP's 6LBR, and vice versa.

If we can solve that set of business issues and the ingress filtering 
issue, then how to handle CO coordination might fall out as a result; I 
would expect any solution to the issues require some coordination 
between the Electrical Company and the ISP.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 Jul 2010 09:31:44 +0200

> > to have: An LBR in the meter with a PIO of the back haul to the
> > utility and a prefix assigned by the utility. A second LBR in a
> > broadband router with general access to the Internet and a prefix
> > assigned by an ISP. The LBRs would need to be configured to
cooperate
> > correctly so there is only one set of context information in the
> > network but each LBR may be advertising a different PIO.
> >
Company or
> the ISP? What prevents their support lines from just pointing fingers
at the
> other company?
instance, I
> expect the service providers to follow best security practices and do
ingress
> filtering on the source addresses. That means that if a host picks a
source
> address from the ISP prefix, then those packets better go out via the
ISP's
> 6LBR, and vice versa.
issue, then
> how to handle CO coordination might fall out as a result; I would
expect any
> solution to the issues require some coordination between the
Electrical
> Company and the ISP.

[Pascal] All true. 

RPL expects a different instance for different 2 service cies. In the
simplest case,
 we'd end up with 2 LBRs, one serving the Electrical Company and one the
ISP.

Each LBR spawns its own DODAG. Some relay routers in the home belong to
both
instances to support both the electric lights and the security
monitoring. 
So packets are tagged to follow the right topology. 

Whatever a LBR injects is contained within the scope of the instance it
injects it 
into. It appears that the CO dissemination would benefit from the same
model.

Just like we can map the abstract TID in the RPL path sequence, would
there be a
 way to define an abstract ND context ID that could map into the RPL
instance ID?
It appears that such context ID could help scope the dissemination
process in ND.

Pascal

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 07 Jul 2010 16:30:24 -0700

> It appears that such context ID could help scope the dissemination

The RPL instances seem to assume that at least all the routers have a 
well-defined way to map a packet to/from a host to a particular 
instance. That mapping table seems like a critical piece of 
configuration information that need to be distributed for RPL.

If one wanted to have different compression contexts for 6lowpan for 
different RPL instances, then all of that mapping table would have to be 
distributed to each host, to ensure that the compression context that is 
used matches the instance that RPL would use. This sounds extremely 
brittle, because if there is any mistake e.g., due to some hosts having 
a mapping table which is out of date, the effect would be packets that 
can not be correctly decompressed.

Sounds like a bad idea to me.

    Erik

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 8 Jul 2010 15:57:45 +0200

> >   we'd end up with 2 LBRs, one serving the Electrical Company and
one
> > the ISP.
> >
> > Each LBR spawns its own DODAG. Some relay routers in the home belong
> > to both instances to support both the electric lights and the
security
> > Whatever a LBR injects is contained within the scope of the instance
> > it injects it into. It appears that the CO dissemination would
benefit
> > from the same model.
well-
> defined way to map a packet to/from a host to a particular instance.
That
> mapping table seems like a critical piece of configuration information
that
> need to be distributed for RPL.
> 
> distributed to each host, to ensure that the compression context that
is used
> matches the instance that RPL would use. This sounds extremely
brittle,
> because if there is any mistake e.g., due to some hosts having a
mapping
> table which is out of date, the effect would be packets that can not
be
> correctly decompressed.
 
[Pascal]

Same here. I do not like the idea of mapping either and I certainly hope
we can avoid that. 

To serve on or more multiple SPs,  a host needs to understand the scope
associated to each SP and then learn prefixes, CIDs and stuff that are
used within that scope.

>From there comes the need for an abstract identifier for the scope to
associate with the context option, the PIO  and whatever else that gets
disseminated for that SP.
At the moment, the ND draft does not have that scope, and thus all
information is global, and thus all must be coordinated and homogeneous
between all LBRs.
Which I understand is the valid issue in this thread. 

If the dissemination process is RPL, then the unique identifier for the
scope is quite naturally the same as the instanceId, and that means that
the host should see the instance ID as an abstract scope ID, even if the
host is not aware of RPL per se. 

If the scopeID flows in the 6LOWPAN ND messages together with a TID,
then redistributing the ND registrations into RPL as host routes becomes
doable.

I understand that RPL and 6lowpan ND wish to be able to live
independently, but I still wish to see that they can also cooperate.

Pascal

---

From: Daniel Gavelle <[email-masked]>
Date: Mon, 12 Jul 2010 09:55:49 +0100

Colin,

I think ICMP compression for 6LowPAN would make an interesting IETF 
draft.  However, even with ICMP compression, there are some things that 
are better addressed in the 6LowPAN-ND specification:-

Changing timers from 32 bit 1 second to 16 bit 10 second needs to be 
done in the 6LowPAN-ND spec as they won't be compressed with a generic 
ICMP compression algorithm.

Allowing Context zero to be implied from the prefix will also save more 
bits if done in 6LowPAN-ND, although a generic ICMP compression could 
detect the duplicate address information and save most of the bits that 
are common between the source address, prefix and context information.

If 6LowPAN-ND is now ND for LLNs, we need the sllao and tllao options 
for MACs that don't allow the MAC address to be read by the higher 
layer.  The 6LowPAN ICMP compression algorithm you suggest could save 
these duplicate bits for 6LowPAN networks.

Daniel.

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 12 Jul 2010 11:32:07 +0100

Hi Daniel,

> However, even with ICMP compression, there are some things that 

I agree completely here. The ICMPv6 header compression would be as dumb as
possible in all these regards.

Maybe I'll try to whip something up quickly and submit it, just so everyone
can understand the options I was thinking about.

Regards,

  -Colin

-----Original Message-----
From: Daniel Gavelle [mailto:[email-masked]] 
Sent: July 12, 2010 9:56 AM
To: Colin O'Flynn
Cc: 'Zach Shelby'; '6lowpan'
Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10

Colin,

Daniel.

Colin O'Flynn wrote:
>> Looking through ND-10 I think we are getting pretty close to our limits
in
> the size of NS/NA+ARO+SLLAO. 
>> NS/NA = 24 octets
>> ARO = 16-32 octets
>> SLLAO = 8-16 octets
>>
>> Best case  = 48 octets
>> Worst case = 72 octets
>>
second

---

From: Zach Shelby <[email-masked]>
Date: Mon, 12 Jul 2010 14:32:02 +0300

On Jul 12, 2010, at 11:55 AM, Daniel Gavelle wrote:

> Changing timers from 32 bit 1 second to 16 bit 10 second needs to be done in the 6LowPAN-ND spec as they won't be compressed with a generic ICMP compression algorithm.

This will be fixed in Ticket #83, so we're good there.

Zach

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Jul 2010 17:48:33 +0200

> can understand the options I was thinking about.

Then don't look at this half-baked draft:

http://www.tzi.org/~cabo/draft-bormann-6lowpan-ghc-00pre.txt

The actual spec in there is a single page (but doesn't define how it is integrated with hc-07 NHC yet; that will be another paragraph and might use up the reserved code).  It will probably need another page of "Here's a nice way to use it" for general ICMP, ND, DHCP and RPL, each.

I'm not at all sure we want to do this, that's why I never submitted it.
(It also helps if you know what RFC3320 is.  But that would be way too complicated here.)

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Jul 2010 18:10:10 +0200

On Jul 12, 2010, at 10:55, Daniel Gavelle wrote:

> Context zero

Making context zero special is not a smart move.

(I know, this is only about compression, but it will not be long until somebody makes a device where context zero is hardwired to be identical the prefix.  There goes renumbering.)

Gruesse, Carsten

---

From: Daniel Gavelle <[email-masked]>
Date: Mon, 12 Jul 2010 17:10:51 +0100

Carsten and Colin,

The codes for repeated bytes in Carsten's draft looks similar to the 
LZ77 compression used in Deflate.  Maybe Deflate could be considered for 
the ICMP compression.  Nodes may need Deflate code anyway, either for 
HTTP compression or X.509 certificate compression.

Daniel.

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 12 Jul 2010 17:13:47 +0100

Hi Carsten,

It's an interesting idea! It would also save flash space by not having
special compression for each different header etc.

I'm not sure for ICMPv6/ND if it's ideal though. Compressing the messages
with a "special purpose" HC would yield considerably smaller message sizes
than generic compression schemes. 

And I think the compression can be made sufficiently simple to avoid huge
code requirements. I'll try to get my own half-baked draft out soon enough
that you can get an idea though!

  -Colin

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: July 12, 2010 4:49 PM
To: Colin O'Flynn
Cc: [email-masked]; '6lowpan'
Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10

The actual spec in there is a single page (but doesn't define how it is
integrated with hc-07 NHC yet; that will be another paragraph and might use
up the reserved code).  It will probably need another page of "Here's a nice
way to use it" for general ICMP, ND, DHCP and RPL, each.

I'm not at all sure we want to do this, that's why I never submitted it.
(It also helps if you know what RFC3320 is.  But that would be way too
complicated here.)

Gruesse, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 12 Jul 2010 18:23:14 +0200

On Jul 12, 2010, at 18:10, Daniel Gavelle wrote:

> Carsten and Colin,
> 
> The codes for repeated bytes in Carsten's draft looks similar to the LZ77 compression used in Deflate.  

Of course, backreferences are being used in LZ77, so I'm not claiming anything in my draft is in any way new.

> Maybe Deflate could be considered for the ICMP compression.  

As the half-draft says, I thought about that.
Too complicated for my taste (even if you take out most of the gratuitous choice that is in RFC 1951).

> Nodes may need Deflate code anyway, either for HTTP compression or X.509 certificate compression.

I'm mostly thinking about nodes here that are too limited for either HTTP or X.509.
While deflate is not *that* complicated, the eight specially crafted bytecodes are about two orders of magnitude simpler.
(Maybe one can make them even simpler, but I didn't invest much time in this demonstration of concept.)

I should probably also clarify that I wrote this draft to un-stall HC, not to add complexity to ND.

Gruesse, Carsten

---

From: "Colin O'Flynn" <[email-masked]>
Date: Mon, 12 Jul 2010 17:37:03 +0100

Hi Carsten,

> I should probably also clarify that I wrote this draft to un-stall HC

I was hoping the addition of ICMP compression wouldn't require stalling HC,
and it could be added as a different I-D.

I wouldn't want to hold up HC anymore either!

  -Colin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Carsten Bormann
Sent: July 12, 2010 5:23 PM
To: [email-masked]
Cc: '6lowpan'
Subject: Re: [6lowpan] Size of NS+ARO+SLLAO in nd-10

> The codes for repeated bytes in Carsten's draft looks similar to the LZ77
compression used in Deflate.  

Of course, backreferences are being used in LZ77, so I'm not claiming
anything in my draft is in any way new.

As the half-draft says, I thought about that.
Too complicated for my taste (even if you take out most of the gratuitous
choice that is in RFC 1951).

> Nodes may need Deflate code anyway, either for HTTP compression or X.509
certificate compression.

I'm mostly thinking about nodes here that are too limited for either HTTP or
X.509.
While deflate is not *that* complicated, the eight specially crafted
bytecodes are about two orders of magnitude simpler.
(Maybe one can make them even simpler, but I didn't invest much time in this
demonstration of concept.)

I should probably also clarify that I wrote this draft to un-stall HC, not
to add complexity to ND.

Gruesse, Carsten