From: Jonathan Morton <chromatix99@gmail.com>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: cake@lists.bufferbloat.net
Subject: Re: [Cake] ieee vs ietf stds for dscp mappings
Date: Sat, 14 Nov 2015 18:46:55 +0200 [thread overview]
Message-ID: <E5825F37-87FD-4729-AD30-F60042FC3650@gmail.com> (raw)
In-Reply-To: <76A52374-F550-4DB6-9E11-91929794126B@gmx.de>
> On 14 Nov, 2015, at 17:53, Sebastian Moeller <moeller0@gmx.de> wrote:
>
> 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.
That’s part of the problem. The various recommendations conflict with each other and with actual practice.
Note in particular the different treatments just of CS0 (default, and defined as Best Effort) and CS1 (defined as Background Traffic) - RFC 7561 actually gets them backwards! The Szigeti-Baker draft is relatively sane and comprehensive, even though it differs from Cake’s schema in detail.
The core of the problem is that Diffserv was originally specified without a complete, working implementation of its PHBs (Per Hop Behaviours). AFAIK, no such implementation exists to date - certainly no public one. So there are ad-hoc, locally-defined approximations all over the place, and my chart illustrates some of that.
As well as the PHBs being poorly defined, it has become general practice for *networks* to set the DSCPs on traffic passing through them, rather than applications setting them at the endpoints. This makes it difficult for applications to express their traffic characteristics and transport needs in general. However, I think this practice has arisen because applications have not bothered to set their own DSCPs, due to their having no effect in most networks.
Dave noted previously that a lot of traffic gets marked as CS1 in Comcast’s network. I’ve recently noticed the same about the Elisa/Saunalahti network over here, having got myself a 4G-capable receiver that came with a prepaid 1-month Saunalahti SIM. DNA, my usual network, does something different - not sure whether it just doesn’t bother changing DSCPs, or does something more complex.
- Jonathan Morton
next prev parent reply other threads:[~2015-11-14 16:47 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
2015-11-14 16:46 ` Jonathan Morton [this message]
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=E5825F37-87FD-4729-AD30-F60042FC3650@gmail.com \
--to=chromatix99@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=moeller0@gmx.de \
/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