I'm currently working on a traffic shaping solution for ISP-level companies, and came to an interesting (kindof philosophical) problem.
Looking about the number of endpoints the system should handle (which is around ~20k) I got a little worried what would happen when I'd need to policy/shape traffic of more users. As I am currently using HFSC shaping tree (see tc-hfsc, mostly the same-but-cooler thing as better-known HTB) for whole network, I'd need to use more ClassIDs (obviously at least one for each user on the network). The problem which I found was that TC ClassID's are kindof limited – they are 16-bit numbers, which gives me a possible maximum of 64k users shaped by this solution.
Similarly, if I want to manage TC filters efficiently (e.g. not using the 'flush all technique'), I need to be able to delete or modify individual filter entries. (I'm using something similar to hash table from LARTC [1]). Again, the only method that seems to be working with this is to number all the filters using individual priorities (tc filter add dev … prio 1). There's no other parameter that could be used for this purpose, and, regretably, prio is 16-bit-only as well.
My question is following: Does there exist some good method for enlarging the available "identifier space", such as 32-bit clsid's for 'tc class' command, and 32-bit priorities (or any other modification handles) for 'tc filter' command?
Thanks very much,
-mk
(btw I hope this will not go to "64k users should be enough for everyone" scenario…)
Best Answer
i think that you should not put 64k users with upstream and downstream classes and filters for each of them on the same interface. You can repeat the handlers for each interface you have, so add more interfaces. You will need a incredible work/server/NIC to have this things. If the server crashes, you will have 64k users offline (and it will crash easily with that amount of traffic). Don't forget that EACH packet that goes through your network card will be checked and classified by a filter and sent to a class to be queued. This is a lot of work for a NIC of an ISP gateway with 64k customers. Mainly with all the video stream that we have nowadays (which is hard to queue properly).