I'm setting up a proof of concept to throttle ingress traffic at terminal end (client):
eth0 -> ifb0 -> htb -> filter by ip -> htb rate -> fq_codel+ecn
I have 2 source ips for specific program I want to throttle. The program in question opens a bunch of tcp connections (downloads, thus ingress throttle), and I would like to both limit total ingress bandwidth it uses (done) and have fair scheduling between connections to same ip address (this question).
In the end there's 1 bucket with rate attached and 1 fq_codel
instance.
I have it working, but I have some questions:
Per internet research flow id is "hash of 5-tuple", question is, what elements of a packet are parts of the 5-tuple? Are both source and destination ports included?
FQ_Codel uses a stochastic model to classify incoming packets into different flows and is used to provide a fair share of the bandwidth to all the flows using the queue. Each such flow is managed by the CoDel queuing discipline. Reordering within a flow is avoided since Codel internally uses a FIFO queue.
FQ-CoDel is a general, efficient, nearly parameterless queue management approach combining flow queueing with CoDel. It is a powerful tool for solving bufferbloat [BLOAT] and has already been turned on by default in a number of Linux distributions.
It seems both source and destination ports are included, at least by default:
http://lxr.free-electrons.com/source/net/core/flow_dissector.c#L655
655 /**
656 * __skb_get_hash: calculate a flow hash
657 * @skb: sk_buff to calculate flow hash from
658 *
659 * This function calculates a flow hash based on src/dst addresses
660 * and src/dst port numbers. Sets hash in skb to non-zero hash value
661 * on success, zero indicates no valid hash. Also, sets l4_hash in skb
662 * if hash is a canonical 4-tuple hash over transport ports.
663 */
664 void __skb_get_hash(struct sk_buff *skb)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With