From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 9305221F890 for ; Sat, 14 Nov 2015 11:17:54 -0800 (PST) Received: from hms-beagle.home.lan ([217.237.68.126]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LZzKf-1agOgM2N9p-00ligY; Sat, 14 Nov 2015 20:17:51 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Sat, 14 Nov 2015 20:17:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <221B4D68-769D-4898-9847-BA96A4EC1B05@gmx.de> References: <93874204-46E0-4878-9F1E-021B68EB1325@gmail.com> <76A52374-F550-4DB6-9E11-91929794126B@gmx.de> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:ZrMKmwPqJBCluU7tM5FpYtvDWmAFrD0+PuW9OVmBZbrLaEvLAxc Jc+BQN5GdLdTcHw99HkD1NV9yYYE07O9CHSJhyG/jFITN42aJky2bqRPL/Fovx5wGEQ4TsC CMdcNrCoPP/LC0lx7L5NLCbCMUkl3GPhw/Kw1KKUSH1ByRJ81mZtqaJ+zIfOBS2SAghDJdJ Vf9RHkycRm6b5POBh08pw== X-UI-Out-Filterresults: notjunk:1;V01:K0:BWfuub5upL4=:cZCbmjM4feZp6FVSrjtVDI 9LzxAkeyIXWZfDWEEu/hCdO0c1LL6RMrFzLzrGL66/nWgt8ymaPVjEHMsUmhGdTzIqecAHV56 yijJMwxC1UtgmxLSImybGLexNuyXm78wAucQaxmIOeQ+3b65j37x+aEGVEN2GMJn5nA7uvyj3 b/qEWx+lyTva1NyP/DV1J7voczDsAJBBrG3XKWaYL3i4SoQKimsiLdkmTfAGJAhAaTuKPc6+C ZSeXl0pq2OotKLZJZAk8E/TzaNd4CepAH/s1P5ZT+JNA3tSew0h9Nl0efCN2ZARpqyEIs3kLD 6lB7Ec8+cdQ6rrRglhRBruJ5TTbp9yl0pWAdGMpuBoqRKqCwzXhnqgI9LlLAs73Bh2eFaGj/R TKx6pOt3+gY7P6mdraha836iM7Oho5Y3VOKKh11rT9nTAupPyDEdQhxAq9WWIbWmLeROesVys a8a20JVHXKcF2KdTbn+Xeiq7OE2cM2Qgnq3vsxcIYluefm2k5+CWj4GF4m+SOAOck+WkiC9C0 wZ4slWvDxMZnVzvRBcYwRacq4Vl1CllgVm4iyrpSYws7Lm5TCiOLdjtXcH+5yJnmv/xU8DLIS DV7dSOe//kfX4IXlyL7jP9LAUv/Z5VU8oGR9tw0v8q7HFXHsa69RihUsCjJIX+q/T6KiSP3VH FsSn3hyRAg9eZrLRx0V31sffQavmm/2E1QG9FwcFtdoEy8yTSio7GIvzaBbPMKtiq9kmeA5q2 D6is/neUvBzrgskrKyWjrWwjs3bn6iNirCxNTfFwcSn8tPj+UNlyor0gr4vv8ZrfKFyXPAMh8 GhsM5Rk Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] ieee vs ietf stds for dscp mappings X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2015 19:18:18 -0000 Hi Jonathan, thanks for the long reply. On Nov 14, 2015, at 17:46 , Jonathan Morton = wrote: >=20 >> On 14 Nov, 2015, at 17:53, Sebastian Moeller wrote: >>=20 >> 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. >=20 > That=92s part of the problem. The various recommendations conflict = with each other and with actual practice. That is the base for my hypothesis that they are not used in = conjunction, as that would not work too well. On the other hand maybe it = works good enough/ better than without DSCP so people might just not = care about the fine print? >=20 > 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=92s = schema in detail. >=20 > 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. >=20 > 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. Well any equipment actually looking at the DSCP will need to = consider whether the network owner approved of that marking. In other = swords it might make a lot of sense to separate the 6b bits into 2 = groups of 3 bits, one group for the current network=92s effective = markings and three for the endpoints to signal their intent. I realize = that this still has the issue that one needs to trust the upstream = enough to not have fudged the intent bits=85 but at least this idea = realizes that the 6 bits have different parties interested in using = them=85 I guess the only solution for the trust thing is a tunneled = connection, then one only needs to trust the sender to accept the = encrypted IP header=92s DSCP markings. >=20 > Dave noted previously that a lot of traffic gets marked as CS1 in = Comcast=92s network. I=92ve 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=92t = bother changing DSCPs, or does something more complex. It might just do proper hygiene and rem app everything to DSCP 0 = as not to leak internal network details outside DNA=92s own network; I = believe this is a functionality cake hold learn (I think Kevin = implemented a branch allowing that=85) Best Regards Sebastian >=20 > - Jonathan Morton >=20