Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Jonathan Morton <chromatix99@gmail.com>
To: Mikael Abrahamsson <swmike@swm.pp.se>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Cerowrt-devel Digest, Vol 44, Issue 24
Date: Mon, 20 Jul 2015 10:51:58 +0300	[thread overview]
Message-ID: <7A5017C0-A403-46CD-AAF5-E89F4B4789B0@gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1507200913040.11810@uplift.swm.pp.se>


> On 20 Jul, 2015, at 10:17, Mikael Abrahamsson <swmike@swm.pp.se> wrote:
> 
> On Sun, 19 Jul 2015, Jonathan Morton wrote:
> 
>> In the current version, a bandwidth threshold is used instead. If the traffic in the class remains below the threshold, then they get the (non strict) priority requested. If it strays above, the priority is demoted below other classes instead. In the absence of competing traffic, any class can use the full available bandwidth, but there's always room for other classes to start up.
> 
> I had an idea of using DSCP 000xx0 and have a BE+, BE and BE-. BE+ would be scheduled to send packets twice as often as BE, and BE- would be 1/10th of (BE+ BE).
> 
> I keep getting pushback from the DSCP authors that he BE- idea wouldn't be a problem (and they agree that it makes sense for a scavenger class), but that my idea of BE+ should be something else, for instance AFxy. I don't believe anything that isn't 000xxx will ever get widely deployed for Internet use, and there should be no strict priority but just a slight preference for scheduling packets with the BE+ code point, exactly to make DDOS less of an impact.
> 
> What is your opinion on this concept?

I could add support for, say, DSCP 000110 mapping to the Background class with one line of code in Cake; that would give it the same treatment as CS1 currently gets.  The legacy TOS codepoints 000001 and 000100 (Low Delay and High Reliability) already map to the Video class; I’ve deliberately left 000010 (High Throughput) in the Best Effort class.

In effect, that would give very similar behaviour to what you suggest.  Assuming the link is saturated with all three classes of traffic, three-quarters of the bandwidth would be dedicated to the Video class, three-quarters of the remainder would be Best Effort, and just one-sixteenth would be Background.

Additionally, there is already *some* traffic routinely using CS6 (eg. NTP) and EF codepoints, which I think are relatively well-established as “low throughput, low latency” indicators.  Those both go in the Voice class in Cake, which is thresholded at one-quarter of the link.  If all four classes are saturating the link, that would just reduce the Video class’s share to one-half instead of three-quarters, leaving the remaining two classes alone.

More generally, using unconditional strict priority for anything is a Very Bad Idea - as noted, it’s just too easy to abuse.

 - Jonathan Morton


  reply	other threads:[~2015-07-20  7:52 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.3.1437246001.9264.cerowrt-devel@lists.bufferbloat.net>
2015-07-19 16:23 ` Mike O'Dell
2015-07-19 19:24   ` Jonathan Morton
2015-07-20  7:17     ` Mikael Abrahamsson
2015-07-20  7:51       ` Jonathan Morton [this message]
2015-07-21 17:47     ` Mike O'Dell

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/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7A5017C0-A403-46CD-AAF5-E89F4B4789B0@gmail.com \
    --to=chromatix99@gmail.com \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=swmike@swm.pp.se \
    /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