I have read that Traffic Control feature in Linux will try to shape the egress traffic to remove bursts and has its own queue mechanism.
I am trying to generate traffic at higher rates as a result Traffic Control would be a bottle neck in my case.
How could I disable it so that there is no queuing done by traffic control in linux ?
AFAIK this could be done only while compiling kernel:
Many distributions provide kernels with modular or monolithic support
for traffic control (Quality of Service). Custom kernels may not
already provide support (modular or not) for the required features.
Example 1. Kernel compilation options
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_INGRESS=m
CONFIG_NET_QOS=y
CONFIG_NET_ESTIMATOR=y
CONFIG_NET_CLS=y
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_POLICE=y
Please refer to this document for more details.
Also remember that besides Traffic Control there are many other mechanisms that are limiting traffic and actually allows network to work properly (like TCP congestion control for example).
Related
I have a client with a 1-2 thousand viewer audience, with everyday streams, same concurrent number of viewers.
Ive got a server set up for their website etc, but am in the process of figuring out the best way to stream with OBS onto that server, and than re-distribute that stream to clients (as an embed on the website).
Now from the calculations i did, running that kind of concurrent viewers is very problematic, as it forces you into a 10gbit link - which is very expensive, and i would ideally like to fit within 1-2gbps, if possible.
A friend of mine recommended to look into "Multicast" which supossedly uses MUCH less bandwith than regular live streaming options. Is multicast doable? Ive had a NGINX live stream set up on my server by a friend before, but never looked into the config and if multicast is supported within that. Are there any other options? What would you recommend?
Also, the service of that live stream isnt a high profit / organisation type of deal, so any pre-made services just dont make sense, as it would easily cost 40+ dollars per stream, which is just too much for my client.
Thank you for any help!
Tom
Rather than Multicast, P2P is more practical solution on Internet, to save money not bandwidth.
Especially for H5 browser, it's possible to use WebRTC DataChannel to transport P2P data.
But Multicast does not work on internet routers.
Multicast works by sending a single stream across the network to edge points where clients can 'join' the multicast to get an individual stream for them.
It requires that the network supports multicast protocols and the edges align with your users.
It is typically used when an operator has their own IP network for service like IPTV, rather than for services over the internet.
For your scenario, you would usually use an organ server and a CDN - this will usually reduce the load on your own server as the video will be cached on the network and multiple user can access the same 'chunks' of the video.
You can see and AWS example for on demand video here - other vendor and cloud providers have solutions too so this is just an example:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/tutorial-s3-cloudfront-route53-video-streaming.html
You can find more complex On Demand and Live tutorial also but they are likley more that you need: https://aws.amazon.com/cloudfront/streaming/
Exploring P2P may be an option also as Winton suggests - some CDN may also leverage P2P technology internally.
Is it possible for each node connected to the same router to implement different congestion avoidance technique? Also, is it possible to completely disable congestion avoidance in a node connected to a router. Thanks.
The answer depends on your definition of "possible".
Internet hosts should adhere to internet standards. According to these documents TCP should implement congestion control algorithm that is "reno-friendly", that is can coexist with Reno (see RFC5681). So, if you need a TCP implementation, that adheres to these standards, then the answer is no.
Enforcing this, is however another issue, which as far as I know does not really have a solution. So, can you still implement whatever congestion control or no congestion control at all, and still connect to Internet, the yes.
Is it actually done? Yes As of now, Linux hosts use TCP Cubic, and Windows uses another congestion control mechanism, whose name I don't remember. They are both Reno friendly and coexist with each other, but they are different and they are different from Reno. Recentrly, Google deployed BBR, which may or may not be Reno friendly. Moreover, realtime multimedia streams (e.g., voice or video conferences) also should use some kind of congestion control, so they contribute to the variety as well.
Will router care? Not Really. Router does not care if the attached hosts implement congestion control or not. A simple router will do exactly the same thing. It will get incomming packets, then either send them, if outgoing interface is free, queue them, if the interface is currently busy transmitting other packets and it has space in a queue for this interface, or drop packets, if the queue is full. More complicated routers can utilize things like active queue management schemes, or quality of service with rate control. This will affect how router handles packets, but it won't affect the functionality of the router. It has to take misbehaving hosts into account.
What will be affected? Applications. Application performance for several flows sharing the same bottleneck will be affected, if the hosts implement different congestion control mechanisms or no congestion control at all. How, actually depends on bottleneck bandwidth, capabilities of the routers, and traffic patterns of the applications. It is not possible to say how. However, there is definitelly a possibility that network will not be able to transmit useful traffic (this is known as congestion collapse). One other important thing that will most likely be affected is fairness, which more or less quantifies how equally several flows sharing the same bottleneck will share available bandwidth. A flow that does not implement congestion control can highjack all available bandwidth. The same applies with flows that use more aggressive congestion control than TCP Reno and flows that don't. So, it is not nice, not to implement congestion control. Of course the router can actually do something about it, but it requires pretty expensive per-flow sheduling (you can search for fair-queueing or flow-queueing), and routers usually do not do this.
References:
requirements for internet hosts: RFC1122
latest congestion control algorithm specification
RFC5681.
I wonder if there are any situations where one would prefer software load balancer over hardware load balancer or vice-versa. I've played around with f5, A10, Nginx, and HAproxy briefly, and the only marginal difference I was able to notice was the price, apart from slightly better API documentation etc. So my question is:
Are there any particular use cases where one would prefer Software load balancers over hardware load balancers or vice-versa?
Feel free to quote your experience, where you preferred one over the other and, rationale you used to make that decision.
PS: I have read 5 reasons to prefer S/W load balancers over H/W load balancers and didn't find explanations there very propelling.
EDIT: Regarding my use case, I'll be needing lot of load balancers to secure/load-balance tons of apps. Therefore the design decision should be such, as to cope up with exponentially increasing number of apps behind it (Should be easily scalable). I'm not looking for 10 or 50 app load balancer but at tons of thousands of apps behind load balancers solution. Also it would be great if you can specifically point out at features which outweigh in H/W over S/W or vice-versa. For example with H/W load balancer FPGA services one can do SSL offloading and can acheive an order of X performance gain given that one has more than Y number of apps behind it etc.
There isn't going to be a single answer to this question as it will always depend on your application requirements and your compliance obligations. Companies like F5, A10, Citrix offer services that expand well past basic load balancing and offer features lb just cannot touch.
If you're JUST looking for lb services and maybe some SSL bridging or offloading here are some benefits:
Hardware: Offer hardware accelerated SSL offloading and bulk encryption due to the use of FPGA services. This is also dependent on what cipher suites you plan to use. With hardware you're usually placing them in front of 100's of applications or you're using it because they may be certified firewalls and you need additional requirements for compliancy.
Software: If you just need basic LB, HAProxy/Nginx are an easy choice for basic lb services and even some SSL services. Support is mixed if you're not paying for it, having to rely only on community examples.
However, if you have mixed environments and maybe already have 1 vendor in play, that can help decide. All of the hardware vendors offer virtual appliances and have automation tools to help with elastic environments so really it ends up being "Will you only ever need LB services or will you end up having to tack on more later"?
The F5/A10/Citrix ADC's in cloud still offer more features in a single platform than having to spin up segregated services (think firewall/load balancing/Web firewall/global load balancing/fraud prevention/analytics/access management).
Updated 6/21/2017:
Hardware: People are buying hardware solutions not to proxy 1 or 2 applications but 100 or 200, or even 1000 or 2000 applications in their data centers (on site or collocated). For these cases it's about performance and services beyond lb. It includes security needs and app protection that are not baked into HAproxy and Nginx.
ADC Vendors Software Solutions: You have 3 options because F5/A10/Citrix also sell virtual appliances allowing you to run the same software in Azure/AWS/Google or in VMWare.... you get the idea. This becomes unique because you can have hardware in your co-location and virtual appliances in your cloud solution and its the same vendor and the bonus for your admins, the same support escalation point.
HAproxy/Nginx Softare: This goes back to the original statement, if you're talking LB solution only and price is a concern, this is your way to go. The feature sets are more limited than the ADC/Security solutions above, but they do LB justfine. It can become a bit cumbersome managing 100's of apps so you'll have to rely on your dev team a bit more to make sure they're isolating environments OR are REALLY good at automation.
The decision comes down to will you only need load balancers? If yes, then HAproxy/Nginx. If you need more features to load balance AND protect your app, then ADC software solutions are the way to go.
If you need reliable performance and cannot justify dedicating one vm per host to achieve it, then hardware ADC's are the way to go.
For transparency, I work on the DevCentral team at F5 so I would love to say go hardware, but if you don't need it don't do it. But its going to come down to your application requirements.
The follow up question is what is your application and requirements for a load-balancer?
Generally hardware LB's have a fixed performance and hardware acceleration to assist with SSL offload. Software or virtual performance can fluctuate with an increased load and then you can run into bugs with performance, but it's easier to deploy and scale.
Other questions to look into is, will you need to modify or redirect traffic based on content? For example, rewriting or filtering traffic? If yes, then you may need a full proxy LB.
Requirement
I want to secure my production VMs on AWS, these VMs host critical web applications and can see around 500 Mbps traffic during peak hours. I already using mod_security WAF but I am not very happy with it.
Here is what I am thinking:
What if I can use snort in a lightweight configuration to monitor only HTTP traffic (this would be behind SSL termination) and use opensource XSS and SQLi rules to add an additional layer of protection ? The number of rules will be > 100.
By the time traffic hits my VMs it will be unencrypted. Moreover as I am using snort as on the same host, there wont be much of a semantic gap ( WAF has an edge over IPS since it builds richer app layer context and can detect layer 7 attacks more accurately). Is this understanding correct ?
I can spare around 200Mb of memory and can take 10% overhead on CPU performance.
Is snort the best bet here ? I looked at Suricata which seems to be easier on CPU but hard on memory. Please let me know if this makes sense at all. I want to stick to open source solutions.
I'm coding an extension for a customer, one of the requirements is that the extension also works offline because internet services are not that reliable, my customer's business can't stop but can deal with "stale" data, thats a nice tradeoff I guess.
Therefore, I want to code some kind of distributed cache as an extension to synchronize local data among the N nodes that will be connected running the same application and thus synchronize with the real database, hosted on the internet.
In order to achieve that I imagined that I would need to make a network broadcast and listen to incoming broadcasts, then every node that starts to run my application will broadcast it's IP address and become available as a new node for the distributed cache, failover is very important here.
I googled some possibilities I initially thought but none of them will work, I guess. The first was to do it just with HTTP, the second was to use Google Native Client to write C++ code that could run network code and thus do the broadcast, but it has limitations. Right now I'm thinking to use Java Applets but I don't really know if they have some limitations related to networking or if Chrome Extensions has any limitation with Java Applets.
Any ideas on how to do it? Using some of the stuff I suggested or another approach?
You could create an NPAPI extension, which would not be restricted by Chrome at all.