Deprecated DSCP support

[Greg Choules]

Hi Wolfgang.
Firstly let me say that I have never been a fan of QoS. So I'm slightly
biased against the whole thing in the first place.

But regarding your comment "It’s not easy for the network to guess the
requirements of an application," I would disagree. Traffic classification
and setting of DSCP values is something that edge routers have been capable
of for decades. I would even argue that this is the place you *want* to do
it, rather than trusting what the application itself says it wants.

If you must do the whole QoS thing at all, use something like a policy-map
(other manufacturers are available), match all port 53, set DSCP to an
appropriate value for *your* network and prioritise/police as appropriate
in the core.

Cheers, Greg

On Thu, 29 Feb 2024 at 09:00, Wolfgang Riedel via bind-users <
bind-users at lists.isc.org> wrote:

> Hi Folks,
>
> OK let me help you a bit as it’s really essential for DNS traffic which
> need to be go through in all situations!!!
>
> Within the OS networking stack as also within the network there is always
> a prioritisation of packets within the queues to serialise the packets of
> an application to go on the wire. This prioritisation is being done based
> on DSCP within a L3 domain and on COS when in a L2 domain.
>
> It’s not easy for the network to guess the requirements of an application,
> therefore best case the application is setting the DSCP itself and the
> network is just trusting the DSCP or if smart enough the checking and in
> case of violation doing reclassification.
>
> In my case it’s dscp 24 in named.conf options but the value may be
> different based on deployment scenarios and therefore needs to be a
> configureable option.
>
> If you don't set it, it will default to 0 and all other traffic will get
> higher priority. Saying if you do an ftp download with large frames, your
> DNS request which will be running in parallel will not be making it through
> and either get delayed or typically drooped.
>
> Maybe have a look at the following classification scheme:
>
> [image: 640px-IETF_Logo.svg.png]
>
> RFC 4594-Based 12-Class QoS Model
> <https://www.f1-consult.com/qos/rfc4594/>
> f1-consult.com <https://www.f1-consult.com/qos/rfc4594/>
> <https://www.f1-consult.com/qos/rfc4594/>
>
> —
> Hope that helps,
> Wolfgang
> __________________________________________________________________________
> ____________________
> Wolfgang Riedel | Distinguished Engineer | CCIE #13804 | VCP #42559
>
>
> On 28. Feb 2024, at 22:01, Petr Menšík <pemensik at redhat.com> wrote:
>
> We may want to help fixing DSCP features, but I personally do not know any
> usage, where this feature would be used and what for exactly. Recent bind9
> uses libuv to back its network core, instead of custom networking core
> maintained by ISC. But I haven't found any trace of DSCP support at libuv
> docs [1]. I haven't found a way to set at least type of service on UDP [2].
>
> I think that would be the first place to support DSCP values for
> connections or sockets. Then, once libuv can use it, its support could be
> added back into named.
>
> It would help though if you were more verbose about why iptables cannot
> replace it and what is use-case, when it is useful. Without simple
> alternatives present. If you would describe it, it might motivate more
> people to work on DSCP support. I haven't seen important reason, why it
> needs to be done by the daemon itself. Perhaps we can find alternative way
> to set DSCP tags for you, if you are more verbose about how you use it?
>
> Regards,
> Petr
>
> 1.
> https://docs.libuv.org/en/v1.x/search.html?q=dscp&check_keywords=yes&area=default
> 2. https://docs.libuv.org/en/v1.x/udp.html
>
> On 28. 02. 24 13:50, Balazs Hinel (Nokia) via bind-users wrote:
>
> Hi,
> I am working on a product in Nokia, and we currently use BIND provided by
> Rocky Linux 8 with security patches. Recently the requirement came that we
> should upgrade to at least 9.16. During the testing of this version we
> realized that a feature we used, DSCP, has stopped working. Reading about
> the topic, we found the article about it non-operational in 9.16, and
> removal in 9.18.
>  We also saw the email on this mailing list, stating that "so far, nobody
> has noticed" it is missing. Well, we noticed it just now, and I would like
> to state that our product and most probably other telecom equipments using
> BIND would miss it greatly. As I read in that mail, there was an
> alternative plan which would re-implement this functionality. If it is
> feasible, please consider doing it. The alternative options, e.g. setting
> it via iptables cannot work in our use-case.
>  Best regards,
> Balazs Hinel
>
>
> --
> Petr Menšík
> Software Engineer, RHEL
> Red Hat, http://www.redhat.com/
> PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support
> subscriptions. Contact us at https://www.isc.org/contact/ for more
> information.
>
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240229/2841484e/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 640px-IETF_Logo.svg.png
Type: image/png
Size: 23934 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240229/2841484e/attachment-0001.png>