Hi Martin, On Tue, Sep 09, 2014 at 11:17:15AM +0100, Martin Townsend wrote: > Hi Alex, > > On 09/09/14 10:46, Alexander Aring wrote: > > Hi Martin, > > > > On Tue, Sep 09, 2014 at 10:28:36AM +0100, Martin Townsend wrote: > > ... > >>> I thought more about that, you mean the receiving part only? So the > >>> uncompression. The point is that we don't have no interface for an user > >>> that can decide if he like to use UDP compression like RFC 6282 or UDP > >>> compression like GHC. This is only relevant for the transmit part. So > >>> compression is optionally. (We should have some interface to make this > >>> configurable by user -> adding this to the nhc layer, later). > >> I've implemented compression and decompression. You are right in that we need a mechanism of configuring what gets compressed by what method. > > ok. But how we deal with that currently with GHC UDP and UDP RFC6282 > > compression. We can't not support both compression methods. > > > > btw. how we should call it now? Uncompression or decompression, I can > > also name the callbacks to decompression. I am not a native speaker so > > I will ask you which is better now. :-) > As an English speaker I have to admit I don't know. Here's one link I found on the subject > http://english.stackexchange.com/questions/56480/difference-between-uncompress-and-decompress > to confuse you even more :) > > > > >>> On the uncompression part, means the receiving part we can support both. > >>> UDP RFC 6282 or UDP like GHC, the next header id value should be > >>> different there. That means currently we can receive every packets but > >>> transmit only RFC6282 compression formats. > >>> > >>> So for receiving this, it's okay. But for compression, since we don't > >>> have some interface to make this configurable we should use RFC 6282. > >> So I will ensure UDP is compressed by 6282. Then I was going to start out by just compressing ICMPv6 with GHC and monitor how much data is saved by using GHC. Later on we will implement a mechanism of configuring what gets compressed and by which compression method. > > Okay, you mean that you will leave UDP compression by 6282 but insert a > > receive handling (decompression) for UDP GHC? > > > > RFC6282 doesn't describe any compression/decompression(or uncompression) > > format for ICMPv6, so we could handle there compression and > > uncompression. I understand now you did it that way, or? > For the moment I will assume all ICMPv6 traffic is compressed and decompressed with GHC as this will be the only Next Header Compression format. In future we need something better. We also need a method of knowing what compression formats a device supports. I can see a list of compression formats which could also be a list by protocol. Then when sending to a device you would select the highest ranking supported compression format for that device. Is "what compression methods like a device to use" part of any RFC? Is there something which I don't know? I mean, okay you can do that in any application layer in userspace. But I don't see that we need something like this in kernelspace. I know there is no suggestion that you want to implement something like this in kernelspace, but I want to clarify this. Application layer in userspace means, use some own coap(or whatever) based protocol and setup the right compressions via userspace by some application. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
