Re: Network Acceleration Module vs Service

[Justin Yaple <yaplej@gmail.com>]

> So, what makes it better than ipcomp?

At this point probably nothing, but it is a little different.  After
reading the RFC it looks like ipcomp compresses the entire IP packet
data field while this only compresses TCP segments data field leaving
the majority of the TCP header alone. I do modify the TCP options a
bit.  I looked up how to setup ipcomp, and correct me if I am wrong it
seems to only work on VPN tunnels while this can compress/decompress
any traffic the host is forwarding so it is mesh friendly for MPLS,
Frame Relay, and other meshed WANs.

> That is essentially the definition of coding/compression,
> which you already seem to have (minus one change that you don't
> throw away the dictionary).

Maybe I was not very clear in what these signatures would represent.
They would not be common patterns within the segment data field, but
they would represent an entire TCP segment data field.  When a TCP
segment is sent between two of these hosts they would copy the data
field to the drive, and generate a 40 byte signature composed of a 32
byte SHA-256 base signature, and a 8 byte unique ID.  So a 1400 byte
payload would be replaced by a 40 byte signature when that same data
is transmitted again.  Its effectively substituting the data field for
the signature.  Of course you cannot create signatures for every
possible data field so it would have to use a system to count commonly
sent data, and keep those while allowing the less common ones to be
removed from the system.

> If it is not the case already, devise a mechanism so that userspace gathers
> multiple nfqueued packets at once instead of one-at-a-time.
>  - multi-threading the userspace process might be worth looking into
>  - using NFQUEUE to deliver into separate queues per CPU
>   (so that one CPU does not have to wait for the lock of another)

That is exactly what I was thinking, but was not sure if it was a good
idea or not as I have never tried anything like this.  I was thinking
of using one thread to gather the packets, and assign them to queues
each queue would be processed by a separate worker thread per CPU core
- 1 if there are more than one core.  The thread for gathering the
packets would share the CPU with the rest of the system, and other
processes that might be implemented such as a WCCPv2 client.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html