Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
 
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 3027 times)

Weaver

  • Kitizen
  • ****
  • Posts: 4680
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Advanced PPP features from the dial-up days still live?
« Reply #15 on: August 13, 2015, 04:19:45 PM »

@ejs  - thx very much for that tip about Nitro. This is indeed outside the scope of this thread, which is about PPP.

From what I read, it's a Broadcom-to-Broadcom non-standard feature. Very interesting. deserves and needs a separate thread, and so if anyone finds out some good stuff on it, please contribute to the thread below:

    http://forum.kitz.co.uk/index.php/topic,15947.0.html
« Last Edit: August 13, 2015, 07:04:10 PM by Weaver »
Logged

Weaver

  • Kitizen
  • ****
  • Posts: 4680
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Advanced PPP features from the dial-up days still live?
« Reply #16 on: August 13, 2015, 07:04:48 PM »

Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 5283
Re: Advanced PPP features from the dial-up days still live?
« Reply #17 on: August 22, 2015, 05:18:58 PM »

here stats from 2 hour'ish session mostly streaming.

Statistics
TUN/TAP read bytes   134876428
TUN/TAP write bytes   3293776427
TCP/UDP read bytes   3458901056
TCP/UDP write bytes   313423933
Auth read bytes   3293777099
pre-compress bytes   4480330
post-compress bytes   4495858
pre-decompress bytes   9993975
post-decompress bytes   13070650
Logged
Sky Fiber Pro - Billion 8800NL bridge & PFSense BOX running PFSense 2.4 - ECI Cab - LINE STATISTICS CLICK HERE

Weaver

  • Kitizen
  • ****
  • Posts: 4680
  • Retd sw dev; A&A; 3 × 7km ADSL2; IPv6; Firebrick
Re: Advanced PPP features from the dial-up days still live?
« Reply #18 on: May 15, 2018, 05:10:10 AM »

I hear what people said about processing of user data, L4 payload (L4 SDUs or L4 PDUs) by a PPP compressor on DSL. It would cost a lot in CPU cycles and the nodes in question do not have access to long enough buffers full of ingress data, not without introducing latency and guzzling ram per flow a setup that doesn't scale especially because of the ram. In any case that's what servers can and do sometimes do, eg http servers with gzip and a terrifying amount of ram. The access to buffer length thing was true for dialup modems. PCs and ISPs’ PPP servers as compared to dialup modems had more ram, dialup was slower so ingress queues were long enough so that they had access to more ingress data to consider so allowing compression a good longish context to work on in each buffer full.

However.

IP and TCP and TCP+IP header compression ought to be doable as far as I can see.

In fact, leaving aside PPP for a moment, in the case of the stupid PPPoEoA stack you could build a PPPoEoA-speaking compressor in a DSLAM that would knock out 24 - 36bytes of PPPoEoA crap completely. In some cases this would save a whole ATM cell, but not in the particular IP PDU 1500 case unfortunately.

Combining it with saving of part of an IP header or IP+TCP header then you would certainly save a cell with nearly 40 + 24 bytes saved for IPv4, and for IPv6 60+24 bytes which nearly saves you 2 cells (nearly at 96 bytes payload) so sometimes you would save two cells. So for some short packets you would halve the size of the data, for other sizes you would cut it down to one third the size on IPv6. Wouldn’t help applications much because they are often concerned about the turnaround time in a ping-pong/stop-and-wait protocol, or about one-way latency. But it would conserve bandwidth available to other flows where there is a substantial stream of short L3 packets. Perhaps that is too much of a niche.

Combined PPPoEoA + IP (esp IPv6) + TCP gives you an extra ~3% speed with IP 1500 byte PDUs and a massive saving (size cut down to 50%) on each TCP ack.

This kind of thing was found to be worthwhile before with dialup, and the opportunities available with IPv6, ATM and PPPoEoA are even greater.

Does make me wonder, anyway.
Logged
Pages: 1 [2]