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

[Simon Duquennoy <[e-mail]>]

On Tue, Jan 19, 2016 at 10:10 PM, Pascal Thubert (pthubert)
<[e-mail]> wrote:
> 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.

OK the effectiveness of the compression wasn't my main concern anyway,
it was rather on the mapping between RH3 and RH3-6LoRH.

>
> 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?

Yes I see much value in both the above!
But I feel these goals could equally be achieved with simple
compression of the standard RH3 header, rather than a redesign.
I'm mostly worried about the fact that RPL implementations will have
to produce 6LoRH headers, i.e. be 6lowpan-specific and play with
6lowpan compression from a layer above.

BTW the new text you suggested above makes sense to me, it does clarify things.

Thanks,
Simon

>
> 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 =-
>> >
>> >
>> >