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:

Author Topic: Greater sophistication in o/s regarding networking  (Read 263 times)

Weaver

  • Addicted Kitizen
  • *****
  • Posts: 6566
  • Retd sw dev; A&A; 4 × 7km ADSL2; IPv6; Firebrick
Greater sophistication in o/s regarding networking
« on: September 12, 2018, 12:42:04 AM »

I definitely think that operating systems’ networking APIs and subsystems are far far too basic.

I would like to see firewalling and ACLs available per app with standardised APIs. Also support for QoS type rules behind standardised APIs. It ought to be easy to have named sub pipes so that for example apps could easily put certain types of activity into a named pipe that is shared or exclusive and which has bandwidth limits on it, and also this could be applied to apps without their knowledge or consent, set by a privileged policy definition app. So for example all stars downloads could be put into at least one of three or more sub pipes, one high priority, one or more with a fractional bandwidth limit and one that is background. This would mean that a fast-ish download could be set going but interactive manual web browsing would still not be too painful as the web browsing could be high priority and some bandwidth could always be left free because the fast-ish downloads would be in the limited-to-fractional subpipe.

Very sophisticate schedulers could do things like setting a tiny inter-packet gap for outgoing traffic so that a high priority app such as our manual web browser could always get an outgoing packet in within a guaranteed minimum wait time. But if no such apps are active, then the outgoing stream goes to being absolutely flat out.

We also want a standard o/s-to-o/s control channel so that an o/s can ask the remote end to do throttling and prioritisation and is on, and this would control downloads properly without needing to do ugly and wasteful things like dropping inbound packets prematurely, in the case if TCP, where this is done in order to trick the sender into slowing down, a kludge which is protocol-specific and would not work for UDP in any case. In the case of TCP, delaying ACKs is of course better, but dangerous, since delaying them too long will trigger retransmissions which is a disaster.

We also need o/s group coordination protocols and router/gateway to host o/s protocols that are sophisticated. These should allow such things as groups of machines getting together to coordinate their combined use of a gateway so they leave some free bandwidth on a link; detect idle time in a group so that certain machines can choose to only use a link when it has been idle; get stats on a link’s nature, performance capabilities and current performance stats; detect failover or changes such as when a gateway switches to a backup link, or [shudders] there is a change of routing / addressing that will break transport connections by forcing apps to change source IP address, or there is a change of MTU. The right way to implement a lot of these things is to selectively use IPv6 link-local multicast; multicast for efficiency and link-local and well-known addresses for reliability

Decades have passed and o/s have not got more sophisticated in APIs, policy standards and ACLs and o/s-to-o/s control channels.
Logged

22over7

  • Member
  • **
  • Posts: 65
Re: Greater sophistication in o/s regarding networking
« Reply #1 on: September 12, 2018, 09:37:32 PM »

Generally, most of these things are desirable. Two remarks:

  • What an operating system? It's worth distinguishing between things that provide policy (that is very likely to be changed), and things that put mechanism ("basic") at the disposal of revisable policy. An operating system, I'm not at all sure, is maybe layer upon layer of policies, that can be more or less difficult to disentangle
  • Maybe what you're after could be called virtual networking. (The now swallowed-up company Brocade used to use the term, ICBW). We have virtual memory, virtual CPUs, "machines", printers, virtual this-that-and-the-other. Why not networking.  But what  does virtualisation in general ("basically") mean?
Logged

kitz

  • Administrator
  • Senior Kitizen
  • *
  • Posts: 31696
  • Trinity: Most guys do.
    • http://www.kitz.co.uk
Re: Greater sophistication in o/s regarding networking
« Reply #2 on: September 13, 2018, 12:10:03 AM »

I saw this question earlier, but wasn't quite sure what you were getting at so apols if I've misunderstood, but a few points.

Would it not depend on which operating system and which version? 
 - ie operating systems for mobile devices -v- desktop machines - v - machines that run server software.
 - Generally speaking you wouldnt expect he likes of a mobile o/s to have such a need.
 - I don't know about other o/s, but the inbuilt firewall for Windows for desktops has some config options which allow you to create rules and policies (but not QoS)
 - Most Windows users don't even know the options are there - I bet some don't even realise there's a firewall is there or even what one is
 - I doubt the average user would have a need and if they did would purchase a software firewall.
 - Organisations/business would use specialised Network Operating Systems ie Windows Server or the old Novell for all machines on the network.
 - Other open source software such as pfSense
 - Would the router not be the place to control traffic coming into and off the LAN?
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

chenks

  • Reg Member
  • ***
  • Posts: 553
Re: Greater sophistication in o/s regarding networking
« Reply #3 on: September 13, 2018, 08:47:09 AM »

i agree with the above.
the client OS is not really the place for such things.

they who want such things will have separate appliances to deal with such things.
relying on the client OS to handle such things is foolhardy at best.
Logged