General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Michael Richardson <mcr@sandelman.ca>
To: Daniel Sterling <sterling.daniel@gmail.com>
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] is extremely consistent low-latency for e.g. xbox possible on SoHo networks w/o manual configuration?
Date: Fri, 14 Feb 2020 15:18:19 +0100	[thread overview]
Message-ID: <19192.1581689899@dooku> (raw)
In-Reply-To: <CAJZMiufvYa0L8Pqb67FmeyGRDojoaOC4O8U2gmi32Fh4Umfy4A@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]


Daniel Sterling <sterling.daniel@gmail.com> wrote:
    > I am looking for input / discussion on how to achieve:
    > * on a "regular" SoHo network

    > * first and foremost, to the exclusion of all other goals, consistent
    > low-latency for non-bulk streams from particular endpoints; usually
    > those streams are easily identified and differentiated from all other
    > streams based on UDP/TCP port number,

    > * and assuming the identified and prioritized streams behave
    > themselves and stay non-bulk, decent throughput for all other traffic.


    > That is to say, some endpoints are more important than others; and
    > moreover some apps on some endpoints are most important.

Distinguishing between apps is difficult in IPv4.
IPv6 lets you naturally have many IP addresses, so it could be easier, but
apps need to be taught to use "their" source address.  Or OSes need to force
them, or "containers".

In the specific case of a single network, I'd just do static DHCPv4
allocation and change the parameters on the qos scripts.

In general, I'd want RFC8520 to announce the type of the device, and suggest
a particular class of service.   In the old days, we'd be talking RSVP to
signal desired Diffserv behaviour ("DiffEdge"), but that specification did
not, unfortunately, gain market momentum.

    > I put a linux laptop between CPE (WAN) and LAN. AT&T fiber in my case,
    > 100+ mbit up and down.

It's not a terrible thing to use a laptop, but at 100Mb/s, an Omnia Turris or
equivalenet running latest OpenWRT may be more foolproof. (I'm always the fool)

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [ 
	

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  parent reply	other threads:[~2020-02-14 14:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-12  4:55 Daniel Sterling
2020-02-12 11:41 ` Toke Høiland-Jørgensen
2020-02-12 15:51 ` Jonathan Morton
2020-02-14 14:18 ` Michael Richardson [this message]
2020-02-20  1:02   ` Daniel Sterling
2020-02-20 10:23     ` Toke Høiland-Jørgensen

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=19192.1581689899@dooku \
    --to=mcr@sandelman.ca \
    --cc=bloat@lists.bufferbloat.net \
    --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