Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Weaver]

Does anyone know if it's possible for ISPs to deliver some of the advanced features of PPP to routers, such as PPP VJ header compression, or even MPPC? Those wondrous things in the days of dial-up that made it possible for top-end ISPs to deliver such huge improvements in throughput.

And I suppose the other question is, if they can, is there any such kit on the market?

[mr_chris]

I've wondered about this myself - and the only thing I can conclude is that surely somebody must have already thought about it, and decided that it just isn't feasible or worthwhile.

Otherwise, surely it would have been implemented before now?!

[kitz]

I'm not sure- I'd need to do some digging really (dont have time right now).  lol I actually did compression for my dissertation but I concentrated more on data file storage and the algorithms rather than for transmission so I know nada about VJ header compression/MPPC (before my adsl days).

I'm just spouting off the top of my head here - I recall the special V90/Flex dial up numbers provided by my ISP, but wasnt the theoretical maximum of dial up supposed to be 33k..  until digital modulation which allowed 56/33 and had its own special algorithm.

Adsl uses modulation - DMT to be precise and multiplexing.  Each subchannel has maximum capability of 56kbps (depending on how many bits are loaded).. therefore the more frequencies in use the higher the sync speed.

ADSL(1&2) has a maximum available 223 downstream subchannels. 223 x 56kbps = 12Mbps.
ADSL2+ doubles the amount of available frequencies (subchannels) and we get 24Mbps.

My thoughts re "PPP VJ header compression" ... if its just header compression we are talking about... would it be as beneficial on adsl as it is on dial up?
Reason being that adsl uses much larger MTUs and RWINs than dial up.. therefore header compression certainly wouldn't be as advantageous as it would be on lots of TCP/IP smaller dial up packets.


Edit -
I just did a really, really quick look to see what MPPC was based on.. and it relies on software on the PC - therefore something like OnSpeed?

OnSpeed works ok on dial up but isnt much benefit on adsl.. the faster the speed the less effective this type of compression gets.. and by the time you reach 1-2Mb its certainly not worth it. I dont know any figures.. but thinking of the processing power to cope with and compressing/decompressing data at that type of speed too..  and wondering how much it would slow down even a modern processor at very fast speeds.  The overheads/processing for the compression on "lots of 56k modems" I should imagine could be quite intensive.

Then theres also the downside of adding further compression - the better performing algorithms are normally lossy - therefore dont even work well on types of files that are already compressed.  jpgs/mpgs etc are already very effectively compressed and no benefit can be gained by further compressing these types of files..  by attempting to compress them further you actually increase the file size.  Therefore if using anything like Onspeed etc, you decrease the quality and pictures etc become blocky and horrible.

[mr_chris]

Just to add really, having thought about it too - potentially even up to 40-odd byte saving in a packet header would potentially be useless since the ATM cells are padded anyway if they aren't full.

As for MPPC compression, this is built into dial-up networking on PCs and is slightly different to OnSpeed, as MPPC works by compressing the raw packet (a bit like zipping each packet and transmitting the zipped data, then decompressing it at the other end), whereas OnSpeed simply compresses HTML pages and images, very much at the application layer. OnSpeed is not really any different to a transparent proxy that compresses the pages and images on the fly, like AOL (certainly used to?) do.

[kitz]

>> potentially even up to 40-odd byte saving in a packet header would potentially be useless since the ATM cells are padded anyway if they aren't full.

another valid reason.

>> as MPPC works by compressing the raw packet

I'll take your word for it since I still havent had time to investigate myself 

Same theory though... it would it still be of little benefit? Most larger files that are transferred these days are already heavily compressed such as photos, jpgs,  music, mp3s , streaming etc with the best possible algorithms, therefore compressing the data again could actually increase the file size.

Compression works best on text so would have been of huge benefit in the days of dial up when you were downloading say text newsgroups and html pages.  In todays day speeds this isnt of so much importance.  Even when it comes to surfing, most of todays websites its not the html content that youre waiting for, its things like images or flash content - both of which should already be efficiently compressed.
Same with email - in the days of dial up text could still take a while to come down - with adsl the text content is nothing and its any attachments that take the time.  Zipping/raring things like word docs would decrease download time.  I suppose downloadable prog files could also benefit... but then again install packages are normally compressed as self extracting files.  WinZip and Winrar etc make it their business to know and implement the best possible algorithms.

[mr_chris]

> Same theory though... it would it still be of little benefit?

Correct - sorry, should have said I wasn't disputing that, I was just pointing out the difference between MPPC and OnSpeed-type progs

[Weaver]

I accept your point about VJ header compression, and your point about ATM cell padding is a fair one, but if a non-optimised MTU of 1500 were used for example (where non-optimised means not set to 1478 or 1430 to get to an exact full cell multiple including PPPoA overhead) saving >22 bytes would save just one whole cell, and VJ for IPV4 should be able to do that sometimes. The point is if you have random length packets, and save say half a cell every time, then you gain on average half a cell saving - you save one cell half the time, zero cells half the time. Of course, it's likely that the lengths won't be random, and with TCP generating max-length IP packets to fit the MTU, if you have an MTU that is "optimised" to begin with, in the sense given earlier, then you're completely out of luck, ironically.

As for the actual data compression PPP protocols, MPPC was extremely effective with dialup, often worth a 200%-400% throughput gain in say emails or http HTML downloads. Demon certainly offered it, and so did Freeserve originally (but later dropped it as they cheapened their free service). Before ADSL arrived, MPPC kept me sane.

This came to mind in fact because I was ruminating about IPv6 for SOHO users and how it might ever start to become a practical reality. Now VJ header compression for native IPV6, now that really would be something - huge IP headers with those big addresses. And IPV6 tunnelled over IPv4 would have a very high hit rate for VJ on the IPv4 headers as the IPV4 addresses would always be the same (the tunnel endpoints).

I would have thought that MPPC could be a killer differentiating feature for top-end ISPs if they could afford the cost of all that CPU time in their PPP endpoints, but the bandwidth savings of 200-400% with the right kind of traffic would compensate for the pain.

And of course if IPv6 tunnelling starts to become a popular way of breaking the impasse of non-support in SOHO routers and IPv4-only ISPs, then it's not the ISP who controls things, it's the tunnel endpoint provider.

[kitz]

This is a ramble type post - as Im interested too... and as I start it, god knows where it will end up .    These are just my random thoughts as I go through a few things in my head.. and its a total "blurb and type" sort of post...  so shouldnt be seen as 100% factual, nor may it make sense 



-------------

I will fully agree that something like MPPC/PPP deflate had a huge place to play in the days of dial up and could very possibly have decreased the amount of bandwidth required to transmit files.  But over the past 10 years or so development seems to have been focussed on compressing and optimising everything for the internet in a specific file format.  Therefore even if you used MPPC on a .swf file you wont see any benefit... but you would if you were transferring a load of .txt files.

I dont think you would ever get near a 200-400% improvement with MPCC on adsl.  At slower speeds the savings seem much larger and more beneficial and on top of that most content itself is now compressed and optimised for the internet.

I know onspeed isnt MPCC - but one of the things that does and has always irked me about its claims is that its up to.. and in reality it doesn't work on todays faster adsl connections... nor does it/seldom achieve its headline claims  particularly when so much content is now pre-compressed.



Network/Link/Transport layer compression.


Re Header compression which is performed at the network link layer, There is already a compression method aimed at adsl and ATM cells - ATM Header compression

The invention provides an ATM switch having a compression module for compressing ATM cell headers without affecting the virtual circuit established for the call.

http://www.freepatentsonline.com/6111871.html

I'm not sure on this, but I think DMT also my also use some sort of basic DCT (Discrete Cosine Transform) type algorithm/method of data compression.  Something else - Unless Im dreaming, I seem to recall reading once about how BTw could effectively also treat different types of traffic differently on their network (no Im not talking the traffic shaping/throttling/priority element here) to ensure that further delay isnt added to time sensitive traffic such as VoIP - which would not work well if any further attempts were made to compress this type of data.

Another area to research if you have time (sorry I dont) is L2TP compression methods.  BTw use L2TP tunnelling for presentation to IPStream ISPs.

... and whilst it doesnt really fit in here... other advances have been made in adsl technology which enable faster speeds.  The limitation in adsl1 of 8128 kbps is due to the overheads for RS encoding and the maximum word size. By combining 2 RS code words into one using something called s=1/2 mode, we now in the land of 12Mbps.  (This is how some interleaved lines may report a sync speed of more than the theoretical max of 7616kbps).

Platform dependant Compression.

As regards to MSCC, I had a quick google and did find some mention of it being PCU intensive on high speed connections, and also that it increases latency due to the time required to compress/decompress.
MSCC only works on windows based systems (although there are linux plug ins) but PPP Deflate seems to be the choice for other systems.

Advancements have been made in platforms specifically aimed at delivering content to end users such as Thompson's Cobra + Triple Play Content

As mentioned above, I didnt research into compression at protocol level, so I wont pretend to know anything much about in that particular area... most of the real benefits of compression now seem to occur at Application Layer which is often where most of the real benefits are seen today.

Application Layer/ File Compression.

As the internet has become more popular, more efficient algorithms are being used on the actual data type  specific data and file types.  Files which are stored on our PCs are often in the format efficient for transferring the data over the internet.  .jpgs have replaced .bmp, MP3s and other MPEG formats replaced the midi files and many new video formats are around which compress to smaller file sizes to make them quicker to send over a network.

Specific algorithms that work best for the actual data type are applied to the medium eg VoIP, MPEG, IP-TV, Streaming Video etc etc are already compressed and optimised at source.  Different algorithms will work best on the type of data that is being transmitted and application designers will know if the data type can afford lossy or lossless compression or how much loss (if any)  can be applied to that applications data stream.  If a new algorithm is invented that works best for a particular data type then you need to install a viewer application, or decompressor, or install a new codec.

Lets take Flash for example:-

Flash has seen various improvements in compression methods making Flash movies a popular choice for viewing online content. Each new version of Flash has better and more up to date compression methods... often based on, or combining different old and more traditional types of data compression.... and its why its often preferred by so many content sites today.

Theres not much point compressing flash files - try doing so and see what happens.  Ive just chose 3 completely random .swf files from my internet cache and tried compressing them.  File 1 when compressed increased by 112 bytes. File 2 when compresed increased by 172 bytes. File 3 stayed exactly the same size.
Obviously it will depend on the original file and how much the author has decided to compress them at time of construction. If the author has deliberately chosen less compression because they want better quality, then you could possibly compress it further. But if you try compressing a flash file that has already been optimised for the internet, then it will likely increase in file size due to the actual compression overheads.


Its more efficient to apply a specific algorithm best suited to the data type rather than 'across the board generic one size fits all solution'.  Because VoIP/IP-TV/Flash/MPEGs/JPEGs/name-the-data-type have already been compressed during compilation, then adding additional compression will either bring little or no benefit and may even add to the delay.
By applying compression on the data type you are ensuring that it works on all platforms and not just depending on the network protocol in use.

In the world of todays high speeds and content types, I would imagine the only data that would benefit by using MSCC is things like text or bitmap... 

... or possibly if you are setting up your own tunnelling system/VPN which encrypts data, then you could apply your own compression method relevant to the type of data transmitted... and at that point we are probably back in the land of L2TP type compression methods.



-------------

yee gawds that was a ramble - sorry if it dont make sense, but now Ive typed it all,  I need to go get something to eat... so excuse the probably many trypos etc.