From: John Sager <john@sager.me.uk>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] Enforcing video quality question
Date: Sat, 20 Feb 2021 15:09:50 +0000 [thread overview]
Message-ID: <44401139-5a31-5129-f546-e598e202e6e3@sager.me.uk> (raw)
In-Reply-To: <87im6nhs52.fsf@toke.dk>
On 20/02/2021 11:53, Toke Høiland-Jørgensen wrote:
> John Sager <john@sager.me.uk> writes:
>
>> You will need to specify the hosts explicitly, unless you can live with them
>> all sharing one bandwidth class. In that case if you have more than one
>> using bandwidth they would share the bandwidth in that class equally. I
>> assume from your original post that you want each host to be limited in
>> bandwidth to a specific value, but to do that you need a class for each host
>> in the ingress HTB.
>
> Just do enough classes that you can cover the whole IP space? At least
> for IPv4 that's trivial; for IPv6 you'll probably need to hash and hope
> that there are not too many collisions...
Thinking about that, one could set up, say 16 classes for 16 marks and
generate the marks using the HMARK target. That could hash on src,dst and
include the ports if necessary. Then the connections would distribute across
the HTB classes. However one video connection would generate multiple flows
(DNS, metadata, etc before & perhaps during the video flow) so simultaneous
video sessions from several users would likely interfere with each other.
My current solution marks on source IP address or MAC address so all the
traffic for one host goes into one class.
John
>
>> What you probably need is a scheduler that has a limit per flow up to
>> an overall ceiling beyond which it shares equally. I'm not aware that
>> any of the schedulers do anything like that.
>
> If you use FQ-CoDel as the leaf qdisc in HTB you'll get flow scheduling
> to each host. There won't be a per-flow *limit*, but you'll get nice
> scheduling of all flows going towards each host.
>
> -Toke
>
next prev parent reply other threads:[~2021-02-20 15:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-18 17:40 Peter Lepeska
2021-02-18 19:10 ` Toke Høiland-Jørgensen
2021-02-18 19:13 ` Peter Lepeska
2021-02-18 19:28 ` Toke Høiland-Jørgensen
2021-02-18 19:43 ` Peter Lepeska
2021-02-18 19:55 ` N0man Tech
2021-02-18 22:05 ` John Yates
2021-02-19 12:16 ` John Sager
2021-02-19 15:02 ` Peter Lepeska
2021-02-19 19:04 ` John Sager
2021-02-19 20:33 ` Peter Lepeska
2021-02-19 23:06 ` John Sager
2021-02-19 23:26 ` Jeremy Marks
2021-02-20 11:53 ` Toke Høiland-Jørgensen
2021-02-20 15:09 ` John Sager [this message]
2021-02-20 11:54 ` Toke Høiland-Jørgensen
2021-02-23 11:15 ` John Sager
2021-02-23 20:37 ` Peter Lepeska
2021-02-23 20:52 ` Jeremy Marks
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44401139-5a31-5129-f546-e598e202e6e3@sager.me.uk \
--to=john@sager.me.uk \
--cc=cake@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox