Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Simon:

Could we take some examples? If possible most of them reasonably realistic? We"ll see the outpout of both methods. 

Again I have nothing against allowing the precision of the byte in the compression, but then is that a real world problem worth wasting types in the 6LoRH? I'd think not for the first 6 actets of the prefix.

I agree with you for the goal
"
Any level of awareness is too much, IMO a RPL implementation should run
unmodified yet benefit from 6LoRH.
"
But the draft does not achieve it as you prescribe. 

The 6LoRH is designed to enable the insertion of a RH3, the addition a RPI, or the IP in IP encapsulation, or any combitnation thereof, without changing a bit in the packet encoded with RFC 6282 (with the restrictive assumption that the RPL artifacts are always encoded with 6LoRH).

I think there is value in:
- preserving the RFC6282 handlers without a change
- manipulating easily the headers induced by RPL without touching the original packet and in particular without the swap of destination address with RH.

Isn't that worht something?

Pascal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Simon Duquennoy
> Sent: mardi 19 janvier 2016 21:55
> To: Michael Richardson <[e-mail]>
> Cc: Pascal Thubert (pthubert) <[e-mail]>; [e-mail];
> Routing Over Low power and Lossy networks <[e-mail]>; Tengfei Chang
> <[e-mail]>; [e-mail]
> Subject: Re: [6tisch] [6lo] Proposed improvement in RH3-6LoRH
> 
> Any level of awareness is too much, IMO a RPL implementation should run
> unmodified yet benefit from 6LoRH.
> For instance, if RPL produces a RH3 with cmpri of 6 and cmpre of 10, we end
> up with two RH3-6LoRH, each with its own "size unit", which has to be
> power of two -- we end up with a compressed possibly larger than the
> original.
> Another example is when more than two RH3-6LoRH are included to benefit
> from a variety of compression levels: in such case, it is not even possible to
> translate the compressed back into a standard RH3.
> 
> Generally speaking 6lowpan offers one-to-one mappings between
> compressed and original headers, I think it is a pity that 6LoRH doesn't.
> 
> On Tue, Jan 19, 2016 at 9:34 PM, Michael Richardson
> <[e-mail]> wrote:
> >
> > Simon Duquennoy <[e-mail]> wrote:
> >     > I feel we need to make sure any valid RH3 can be compressed with
> 6LoRH. This
> >     > way, RPL implementations do not need to be aware of 6LoRH.
> >
> > I'm sensitive to your need, but I'm not sure it's worthwhile.
> >
> > What kind of awareness do you feel is required?
> > There needs to be some communication of what are the interesting
> prefixes.
> > I don't see this as a problem.
> >
> >
> > --
> > Michael Richardson <[e-mail]>, Sandelman Software
> Works
> > -= IPv6 IoT consulting =-
> >
> >
> >