Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: [1] 2

Author Topic: Advanced PPP features from the dial-up days still live?  (Read 4005 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6392
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Advanced PPP features from the dial-up days still live?
« on: August 11, 2015, 10:12:43 PM »

In the days of dial-up modems, some ISPs, Demon being an outstanding example, offered all the fancy features that the PPP protocol suite provides, including header compression for IP and TCP headers to more or less make them go away, very powerful data compression too.

* I wonder if any of this goodness has survived into the modern era?

* Do any ISPs have kit powerful enough to do the sexy things we used to enjoy?

* Would this be constrained by any need to remain within the boundaries of what BT can understand?

IPv6 header compression - yum, yes please. And TCP header compression, still relevant.

Obviously the ISP is hardly going to be motivated if no CPE is available that can handle this yummy goodness at the user's end.

I noticed that our cheerful Scot from BT - speaking at a recent UKNOF iirc, his name has just gone - mentioned how they would like to get rid of PPP and do IPoE.

Who ordered that? Yet more bloat from the arguably useless Ethernet headers, but I can see the attraction for multiplexing and getting strange functions via VLANs that caould make ISPs money from non-Internet services (and start to get up to all kinds of disturbing tricks too which may be hard for us the users to monitor and control). And more chaos and wasted money in the transition too.
Logged

GigabitEthernet

  • Kitizen
  • ****
  • Posts: 1888
Re: Advanced PPP features from the dial-up days still live?
« Reply #1 on: August 11, 2015, 11:02:08 PM »

I very much like your curiosity! ;D

Unfortunately on this occasion I cannot be of much assistance, other than to say I will be watching this thread with a keen interest ;)
« Last Edit: August 11, 2015, 11:26:25 PM by AlecR »
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6392
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Advanced PPP features from the dial-up days still live?
« Reply #2 on: August 11, 2015, 11:17:03 PM »

I have failed in my attempts to google this subject, its the time/era thing that Google doesn't seem to be capable of understanding.
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5457
Re: Advanced PPP features from the dial-up days still live?
« Reply #3 on: August 11, 2015, 11:34:15 PM »

the problem is these days compression at the network level now has more limited benefits, because things like gzip compression on http pages e.g. is now the norm.

As for your curiousity tho I can give you some stats in regards to network level compression the next time I enable my VPN to watch a game, it does get reasonably impressive compression levels.

However I expect if isp's were to do this network wide there would be massive cpu usage across the board.
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6392
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Advanced PPP features from the dial-up days still live?
« Reply #4 on: August 11, 2015, 11:44:52 PM »

> massive cpu usage

and a lot of totally incompressible data too. Email and html aren't significant in term of the fraction of bandwidth they represent out of the total.

But crazy CPUs should be able to do things such as header compression, Moore's law and multicore can take care of the stresses placed upon these nodes surely.

I'd be interested to know how important very short messages are. VoIP is short? DNS queries (not enough of them). Very short IP packets over IPv6 might be candidates for a big percentage decrease in size? I'm not sure.

What's a high rate, short packet protocol?
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5457
Re: Advanced PPP features from the dial-up days still live?
« Reply #5 on: August 12, 2015, 05:34:31 AM »

Those wouldnt be worth bothering with, dns lookups slow you down due to the high exchanges of packets. Compression would do very little if anything to speed up that process.

So a 10ms 500kbit line will do dns lookups faster than a 100ms gigabit line.  With DNS bandwidth isnt the issue, latency is.
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6392
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Advanced PPP features from the dial-up days still live?
« Reply #6 on: August 12, 2015, 07:14:33 AM »

@Chrysalis - agreed. :-)
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 31654
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Advanced PPP features from the dial-up days still live?
« Reply #7 on: August 12, 2015, 06:24:03 PM »

Only just seen this.  Please sir I think I may know why. :waves hand in the air:

First a wee bit of a background into compression:   
Compression is primarily designed to make file sizes smaller.  There are various compression algorithms which are effectively judged by how much they can reduce the file by.  The most 'efficient' algorithms are not necessarily the quickest to parse. The larger the file size the longer it takes to scan through looking for duplicates. Compression is processor hungry and it takes time to parse a file.   Certain 'fast' algorithms such as CBR (audio) and DCT (jpg) wont do the job for data because they are lossy.  Network data compression has to be lossless and it can be slow to parse.   Grab any decent size file and see how long it takes to zip/unzip it even on a fast PC.

The most common algorithm used network data is Lempel Ziv Stac (LZS). My dissertation was in compression and although I've forgotten most of the in-depth stuff now, I've certainly not forgotten how its full name can be difficult to say.  Seriously try pronouncing it several times - I'm not alone in this - and in some circles it was shortened to "Stac".

As mentioned Lempel Ziv Stac is heavy on processing for the parse, the larger the file the longer it takes to go through the loop and theres many, many loops of them inside the algorithm, trying to find duplicates. Also bear in mind that you cant compare a pre-processed compressed file stored on a server for download to having to it continually on the fly for real time data throughput. Ok that out of the way... the reasons why its not used.

-----

Packet size
: Dial up = 576 bytes.  DSL = 1500 bytes.  So header is comparatively small compared to useful data for DSL packets. Therefore not as large of a saving to be made.

Processor intensive: Already covered above, the faster the speed the more data having to be compressed on the fly.

Computing power @ home:  With dial up the compression tool sat on the local machine as the modem was inside the PC.  With DSL & a NAT network its the router that would be having to do the processing. Your average DSL routers aren't really equipped to handle this sort of high power processing.  They already juggle acting as multiple 56k modems (DMT), then stuff like FEC, Interleaving and now G.INP.

Lag: The processing causes lag - you may not notice say 1ms on 56k, but as data bandwidth increases, the greater the delay.

Computing power at the ISP
:  In days of 56k, the ISP customers were in the 100's or 1000's.  The ISPs didn't have that many EU's hooked up to one of their routers, but to cope with compression, they needed an additional co-processor specifically to do the compression/decompression.   Today's ISPs have 100's of thousand of EUs - some millions.  There is no way that the ISP gateway routers could handle processing 10's of GBs of data.  I cant remember now but I seem to recall even with co-processing is (was) limited to something like 8Mbps before it caused any noticeable slow downs.   This is 8Mbps for all their customers so it probably worked well if you had 1000 x 56kbps users. 

Back in the days of dial up ekeing out a few extra kbps made a big difference.  Similar to the early days of DSL how we would tweak MTU to get a few extra kbps, but once the speeds get faster no-one seems to bother MTU tweaking unless its impacting something other than speed.
PPP header compression was ditched with DSL as just not worth it for very little gain.  Its not an ISP specific thing - its a worldwide industry thing.


Quote
I have failed in my attempts to google this subject, its the time/era thing that Google doesn't seem to be capable of understanding.

For the reasons I mentioned above, try searching for 'Stac' as it pronounced by those that actually used the technology. Unfortunately it really does seem to be one of those things whereby if you didn't already know, then there aren't any back links!
Logged
Please do not PM me with queries for broadband help as I may not be able to respond.
-----
How to get your router line stats :: ADSL Exchange Checker

Dray

  • Kitizen
  • ****
  • Posts: 2362
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6392
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Advanced PPP features from the dial-up days still live?
« Reply #9 on: August 13, 2015, 06:44:08 AM »

Remember LZ/W too?

No I was very much if the opinion that IP packet payload (an L3 SDU) is not worth compressing, with the exception of TCP headers possibly, but TCP packets are often huge so the gains in TCP header compression are relatively insignificant. IP (+TCP) headers, esp. IPv6 headers would be the only thing I could possibly think of which could have any potential benefit in some circumstances.

(Dial-up Demon used to offer Microsoft something compression for IP payload, iirc.)
Logged

ejs

  • Kitizen
  • ****
  • Posts: 1768
Re: Advanced PPP features from the dial-up days still live?
« Reply #10 on: August 13, 2015, 07:39:48 AM »

It would probably get even worse if you take the fixed size ATM cells (the A in PPPoA) used on ADSL into consideration. 53 byte ATM cell, consisting of a 5 byte header and 48 bytes of payload, or payload plus padding to make up the 48 bytes. If compressing a higher level header only saved 10 bytes, that could just end up as 10 extra bytes of padding in one ATM cell, not actually saving any bandwidth.

I think the biggest overhead on ADSL is the 5 byte ATM cell header in each 53 byte ATM cell. So the biggest gain would come from dealing with that.
Logged

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6392
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Advanced PPP features from the dial-up days still live?
« Reply #11 on: August 13, 2015, 08:11:24 AM »

@ejs  - this argument works both ways of course. A saving of one byte could mean a saving of an entire unneeded ATM cell.

[I discuss this very point in the wikipedia section on PPPoE overheads. (Really bad article, still.)]

Of course losing ATM altogether would be a fine thing, reclaiming about 10% complete waste. (Well 5/48 overall, and the fixed 8 byte trailer per packet )

But failing ditching it altogether, you canít compress ATM cell headers. (i) They're at a lower and inaccessible layer in the xDSL protocol stack. The PPP entities don't know about the existence of ATM. (ii) They have an error checking role, which you would lose. This is what a HEC error is. Bloating the ATM byte stream in this way makes any errors more detectable.



« Last Edit: August 13, 2015, 08:29:30 AM by Weaver »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5457
Re: Advanced PPP features from the dial-up days still live?
« Reply #12 on: August 13, 2015, 09:06:07 AM »

it may help pppoe actually now I think about it.

If the compression would allow pppoe to use 1500byte mtu packets (without jumbo frames) then it would be worth looking into.
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6392
  • Retd sw dev; A&A; 4 ◊ 7km ADSL2; IPv6; Firebrick
Re: Advanced PPP features from the dial-up days still live?
« Reply #13 on: August 13, 2015, 11:39:39 AM »

@Chrysalis - that's a good point. I hadn't thought about that.

Yes, we just need to claw back 6+8 bytes, but reliably. Sometimes something, sometimes nothing is the usual order of the day, and the great length of the data won't help us because we can't exploit IP payload, as it might be random.
Logged

ejs

  • Kitizen
  • ****
  • Posts: 1768
Re: Advanced PPP features from the dial-up days still live?
« Reply #14 on: August 13, 2015, 02:20:39 PM »

Yes, good point about the fixed size ATM cells working both ways.

I think with a Broadcom based DSLAM and CPE, there's something proprietary called Nitro which is apparently a "ATM header compression scheme". Sky might use it. Not on BTWholesale ADSL equipment of course.
Logged
Pages: [1] 2
 

anything