Adding a compression & decompression func. at the network layer?

Hi, all,

I get some random thought about our current network protocol.
I wonder if adding a compression & decompression func at the
network layer can improve performance.

Rough idea:
1. network layer has its own compression & decompression func;
2. at the source end, files are compressed and sent out;
3. at the dest. end, files are decompressed;
4. in the middle, packages are not modified and processed;

Advantages:
1. (?) If files are big, e.g. media data, time to compress,
decompress, and transmit compressed data may be smaller
than the time needed to transmit original files.
2. Will introduce less traffic on the internet.
3. Computing resources are more powerful than that on the
internet. (A PC or laptop can do the compression/decp
easily, while we don't know what will happen on the
internet.)

What do you think about it? (critical comments preferred)

Thanks.
Kathy

Kathy <(E-Mail Removed)> wrote:
> I get some random thought about our current network protocol.

Which is? (the protocol, that is).

> I wonder if adding a compression & decompression func at the
> network layer can improve performance.

Sometimes it can. But you mean transport layer, no? Anyway, try it and
see. Use an ssl or ssh channel. Ssl certainly compresses each packet
sent (and signs each compressed packet). If you like you can elect to
use zero encryption.

Or use a cipe tunnel or other tunnel. They all do encryption and/or
compression.

> 1. network layer has its own compression & decompression func;

What? I really think you mean "transport layer">

> 2. at the source end, files are compressed and sent out;

Why? I thought you said you wanted the "network" layer to do the
compressing?

> 3. at the dest. end, files are decompressed;

Sure, what would one expect!

> 4. in the middle, packages are not modified and processed;

Well, of course not. Uh, you mean no fragmentation? Wll, normally one
doesn't care because one is running over IP.

> Advantages:
> 1. (?) If files are big, e.g. media data, time to compress,
> decompress, and transmit compressed data may be smaller
> than the time needed to transmit original files.

In fact video files ARE compressed, heavily, to start with. They'd be
enormous if not. Ditto audio.

> 2. Will introduce less traffic on the internet.

You are confused about the target area. It would be uncompressed "files"
that would benefit, like text messages :-). Yes, SMS messages really
should be compressed and encoded. But the poor old chip in the mobile
telephone or smart card only goes at a few KHz (well, I guess the phone
may make a MHz, but the smartcard will be down in the low KHz).

> 3. Computing resources are more powerful than that on the
> internet. (A PC or laptop can do the compression/decp
> easily, while we don't know what will happen on the
> internet.)

Yes you do - nothing. In case you haven't noticed, ethernet cables,
hubs, routers, etc. do not contain "computing resources". That is
beginning to change with the advent of smart routers and packets are
beginning to contain little programs to be run as they pass through
these, but that's far ahead of us.


> What do you think about it? (critical comments preferred)

I think you don't understand that this is already the way things
happen if you use the right transport protocol. Perhaps you are hoping
that it be done at a more profound level, say at the hardware level?
Buut as you say, nbody is going to be decompressing and recompressing
those packets ÷n route, so why bther ding it at a more profound layer
than transprt? As for your idea of compressing files, that is the
APPLICATION layer, not the transport layer, and any server client pair
is free to chose to do that. Ftp does that, if you ask it to.



Peter

On 2004-12-02, Kathy <(E-Mail Removed)> wrote:
> Hi, all,
>
Evening.

> I get some random thought about our current network protocol.
> I wonder if adding a compression & decompression func at the
> network layer can improve performance.
>
> [snipped]
>
> What do you think about it? (critical comments preferred)
>
Its called IPComp :P

http://www.faqs.org/rfcs/rfc2393.html
http://www.faqs.org/rfcs/rfc2394.html

If you are talking about level three on your OSI diagram (ie a replacement
for IP) compression already can exist.

Cheers

Alex

Thanks for your commenting, Peter!
(Sorry for my confusing post.)

1. Yes, I mean on the transport layer.
2. I mean other than applications' different compression
& decompression algorithms, we add an transport-specific
cmpr/decmpr func as a general-purpose func for all kinds
of data.

Does it make sense?

Thanks.
Kathy

Kathy <(E-Mail Removed)> wrote:
> Thanks for your commenting, Peter!
> (Sorry for my confusing post.)
>
> 1. Yes, I mean on the transport layer.
> 2. I mean other than applications' different compression
> & decompression algorithms, we add an transport-specific
> cmpr/decmpr func as a general-purpose func for all kinds
> of data.
>
> Does it make sense?

No .

Please check out ssh ssl cipe tunnels, etc.

Peter

Thanks everyone!
I'll look at your provided info.

Kathy