From: Jonathan Morton <chromatix99@gmail.com>
To: Daniel Sterling <sterling.daniel@gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] cake + ipv6
Date: Wed, 23 Sep 2020 21:13:29 +0300 [thread overview]
Message-ID: <3A782CD0-01F1-40FA-9DFD-B969BD11A566@gmail.com> (raw)
In-Reply-To: <CAJZMiuc-SZc9UD_nNFtyHNiG7v1F6EtF=XNsTzXGGhSzEGDdsQ@mail.gmail.com>
> On 23 Sep, 2020, at 8:36 pm, Daniel Sterling <sterling.daniel@gmail.com> wrote:
>
> I ran some updates on the xbox and watched iftop. I found that the
> xbox does the following:
>
> * uses up to four http (TCP port 80) connections at once to download data
> * connects (seemingly randomly) to both ipv4 and ipv6 update hosts
>
> That means at any given time, the xbox could be downloading solely via
> ipv4, solely via ipv6, or a with mix of the two.
>
> I believe this means when it's using both v4 and v6, it's getting
> double its "share" of the bandwidth since cake can't tell that the v4
> and v6 traffic is coming from the same LAN host -- is that correct?
It fits my mental model, yes, though obviously the ideal would be to recognise that the xbox is a singular machine. Are you seeing a larger disparity than that? If so, is it even larger than four connections would justify without host-fairness?
> I'm using the default "triple-isolate" parameter. I can try switching
> to dual-src/dest host or even plain srchost / dsthost isolation. In
> theory that should limit traffic more per download host, even if cake
> can't determine the LAN host that's doing the downloading, right?
Triple-isolate is designed to function reasonably well when the user can't be sure which side of the network is the LAN! The "dual" modes provide Cake with that information explicitly, so may be more reliable in corner cases.
For your topology, eth0 (LAN egress) should get dual-dsthost, and eth1 (WAN egress) should get dual-srchost.
- Jonathan Morton
next prev parent reply other threads:[~2020-09-23 18:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-18 1:52 Daniel Sterling
2020-08-18 2:28 ` Jonathan Morton
2020-08-18 2:54 ` Kenneth Porter
[not found] ` <D7DF629BCBA6767D1E78A973@172.27.17.193>
2020-08-18 3:44 ` Daniel Sterling
2020-08-18 4:15 ` Jonathan Morton
2020-08-18 6:41 ` Sebastian Moeller
2020-08-18 14:17 ` Y
2020-08-18 21:55 ` Michael Richardson
2020-09-23 17:36 ` Daniel Sterling
2020-09-23 18:13 ` Jonathan Morton [this message]
2020-09-24 1:07 ` Daniel Sterling
2020-09-28 6:22 ` Daniel Sterling
2020-09-28 15:14 ` Toke Høiland-Jørgensen
2020-10-01 5:09 ` Daniel Sterling
2020-10-01 11:59 ` Toke Høiland-Jørgensen
2020-11-18 0:00 ` [Bloat] openwrt e1000e (was: Re: cake + ipv6) Daniel Sterling
2020-11-20 23:25 ` [Bloat] finally got the proper cake experience (was: Re: openwrt e1000e (was: Re: cake + ipv6)) Daniel Sterling
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/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A782CD0-01F1-40FA-9DFD-B969BD11A566@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=mcr+ietf@sandelman.ca \
--cc=sterling.daniel@gmail.com \
/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