> On May 3, 2017 4:53:31 PM Peter Sjöberg <peters-oclug [ at ] techwiz [ dot ] ca> wrote: > > Wonder how much QoS can do when all the traffic is https. Guess it > > could aim for some specific sites or so but that feels to much like > > fast lane policy. What's wrong with a fast lane? It's your network! Want to prioritize realtime traffic like DNS and VoIP? Power to you! Just don't leave too much of an avenue for DoS open! Aiming for specific sites is kinda hard because now you need to make the *reverse* link between an IP address, and the domain (hurray for virtual hosting, proxying, etc.), or parse the upper protocols. NOT IN THE KERNEL. If you really must do this, see NFQUEUE or TPROXY in iptables-extensions(8) and ip(7). On Wed, May 03, 2017 at 06:15:13PM -0400, James wrote: > It'd be nice if you could do qos for each connection but I don't think > you can. Yes you can. How could there be anything *conceptually* preventing that? Let's take the simplest example of a queueing discipline that provides some sort of fairness: round robin (1). The first and obvious question is round-robin over what? You have to define a set of queues/buckets over which to round-robin, and how to put things in those buckets. There are dozens of packet attributes, many of which are not always present that you can use to decide into which bucket: layer 3 protocol (IPv4, IPv6, etc.), IPv4 ToS/DS, IPv4/6 source/destination, layer 4 protocol (TCP, UDP, SCTP, etc.), layer 4 destination (i.e., TCP/UDP source/destination port), etc. And those are just the ones that *most* people know about. If I use a u32 classifier under Linux, I can put things in buckets based on arbitrary bits (and waaaaay more, see tc-u32(8), tc-connmark(8), etc.), and have as many buckets as performance allows. Regards, Alex Pilon 1: Not a lot. At least use deficit round-robin (DRR) if you're going to do round-robin, otherwise you'll have a serious elephant vs mice problem, i.e., large bursty traffic will unfairly penalize small, otherwise predictable real-time traffic. P.S. The level of quoting in this email **IS** correct. Thanks James.