From: Sebastian Moeller <moeller0@gmx.de>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] ieee vs ietf stds for dscp mappings
Date: Sat, 14 Nov 2015 16:53:46 +0100 [thread overview]
Message-ID: <76A52374-F550-4DB6-9E11-91929794126B@gmx.de> (raw)
In-Reply-To: <93874204-46E0-4878-9F1E-021B68EB1325@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2187 bytes --]
Is anybody actually using any of that? The set of differences between the schemes as RFCd for the different technologies makes me believe nobody is ever using more than one of those domains. In my ignorance (as it is well known people completely out of their depth often feel they really understand complex issues, and their simplistic solutions are really great and thoughtful; I am no exception to that rule) I think the best thing to do would be define a reasonable set of 3 bits for our own use, and map these following one underlaying rationale to how many priority tiers we want to use. I would argue for leaving all legacy mappings behind… I believe the idea, I picked up in one of the email conversations on this list? (it certain is not my original idea, even though I forgot where I picked it up) to preserve the incoming markings (as good as possible in 3 bits) and restore them once/if the packet leaves our dscp domain again seems like the decent thing to do...
On the wifi-side my limited understanding of the access rules tell me, that allowing clients to pick their qos marking can and will starve the AP of TxOps, so unless the AP can enforce a unified tier for all clients the AP should, in my humble opinion, actually pick its own marking (and medium access probability) adaptively, depending on what the clients use, in a nice BE environment stick to BE but if the clients start sending too many packets in the two higher classes (dynamically measured threshold might be required) the AP should up its game and switch its own packets to the same class. My rationale is that the AP is going to have a better vantage point of the competing clients and hence should be in a better position to guarantee some sort of fairness, than any one client. Since this seems so simple, there probably is a very good technical reason why this can not work, that I am just unable to see.
Best Regards
Sebastian
On Nov 14, 2015, at 14:55 , Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 14 Nov, 2015, at 14:43, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> Just to keep confusing matters
>
> Yeah, Diffserv is a complete and utter mess, isn’t it?
>
[-- Attachment #2: Untitled.pdf --]
[-- Type: application/pdf, Size: 39667 bytes --]
[-- Attachment #3: Type: text/plain, Size: 172 bytes --]
>
> - Jonathan Morton
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
next prev parent reply other threads:[~2015-11-14 15:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-14 12:42 Dave Taht
2015-11-14 12:43 ` Dave Taht
2015-11-14 13:55 ` Jonathan Morton
2015-11-14 14:09 ` Dave Taht
2015-11-14 15:53 ` Sebastian Moeller [this message]
2015-11-14 16:46 ` Jonathan Morton
2015-11-14 19:17 ` Sebastian Moeller
2015-11-15 14:52 ` Toke Høiland-Jørgensen
2015-11-15 15:35 ` Sebastian Moeller
2015-11-15 21:20 ` Stephen Hemminger
2015-11-15 21:39 ` Jonathan Morton
2015-11-15 21:40 ` 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/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=76A52374-F550-4DB6-9E11-91929794126B@gmx.de \
--to=moeller0@gmx.de \
--cc=cake@lists.bufferbloat.net \
--cc=chromatix99@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