From: Dave Taht <dave.taht@gmail.com>
To: Hal Murray <hmurray@megapathdsl.net>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] bbr on slashdot
Date: Sat, 2 Nov 2019 16:44:26 -0700 [thread overview]
Message-ID: <CAA93jw4=WVGONA6rHrzrPXonVqdv2CkuKxU0252Kt_x-vNht4g@mail.gmail.com> (raw)
In-Reply-To: <20191102233833.79936406074@ip-64-139-1-69.sjc.megapath.net>
Hi hal. long time no see.
On Sat, Nov 2, 2019 at 4:38 PM Hal Murray <hmurray@megapathdsl.net> wrote:
>
>
> Sebastian Moeller said:
> > Interestingly, the naive expectation in the vice text is equal sharing
> > between all concurrent flows, if only we had a system that could actually
> > help achieving this kind of set-up that is fair to each flow...
>
> Is there consensus on what a flow is? Or what the unit of traffic that
> fairness measures should be?
>
> It seems to me that it depends on where you are located.
>
> Consider upstream traffic:
>
> If I'm a workstation or server, I probably want to give equal weight to each
> connection.
>
> If I'm an exit router at a residence, I probably want to give equal weight to
> each IP Address. If not, pigs can game the system by making multiple
> connections. But if I have a server, maybe I want to reserve or limit the
> bandwidth it gets - reserve to keep the workstation/laptop traffic from
> killing the server and limit so the workstation/laptop people can get some
> work done when the server is busy.
>
> If I'm an ISP customer facing router, I probably want to give equal weight to
> each customer, probably scaled by how much bandwidth they are paying for.
>
> I don't know how to handle backbone routers. You probably want to treat each
> customer as a flow, again scaled by how much bandwidth they are paying for.
> But an IP level packet doesn't tell you anything about which customer it came
> from.
>
> If this is old news, please point me at a good writeup.
I *think* we handled the majority of these use cases in the design of cake.
https://arxiv.org/pdf/1804.07617.pdf
somewhat missing from these is that we also want *really good multiplexing*.
>
>
>
> --
> These are my opinions. I hate spam.
>
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
--
Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-831-205-9740
next prev parent reply other threads:[~2019-11-02 23:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-02 23:38 Hal Murray
2019-11-02 23:44 ` Dave Taht [this message]
2019-11-03 11:14 ` Sebastian Moeller
-- strict thread matches above, loose matches on Subject: below --
2019-11-01 18:19 Dave Taht
2019-11-01 21:14 ` Sebastian Moeller
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='CAA93jw4=WVGONA6rHrzrPXonVqdv2CkuKxU0252Kt_x-vNht4g@mail.gmail.com' \
--to=dave.taht@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=hmurray@megapathdsl.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