set TOS/DSCP IP header bits for routers to prioritize packages

[bjacke]

To signalize edge routers to prioritize Jamulus UDP traffic, it would be good if Jamulus would set the TOS header bits accordingly. https://doc.qt.io/qt-5/qabstractsocket.html describes TypeOfServiceOption which could probably used for that. A values of 0x10 (IPTOS_LOWDELAY) is an often used value, which is known to be very compatible with different kinds of routers without causing problems.
That would help many people get better latency even if they are not able to configure QoS manually on their routers.

[gene96817]

A very good idea. However many (most?) ISPs (in the USA) ignore these bits.

[bjacke]

It's imporant for routers before the packages arrive the internet. Many home router honor TOF bits and send the packages out earlier, even if othe bulk data is in the send queue 18.02.2021 17:53:14 gene96817 <[email protected]>:

…

A very good idea. However many (most?) ISPs (in the USA) ignore these bits. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub[#1016 (comment)], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AAP2C7FEXNCVZVTO3XQ5VHLS7VAXLANCNFSM4X2OOTGA]. [data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAEIAAABCCAYAAADjVADoAAAAAXNSR0IArs4c6QAAAARzQklUCAgICHwIZIgAAAAnSURBVHic7cEBDQAAAMKg909tDwcUAAAAAAAAAAAAAAAAAAAAAPBjRFIAASHKmKkAAAAASUVORK5CYII=###24x24:true###][Verfolgungsbild][https://github.com/notifications/beacon/AAP2C7GRCKYFESLMA7WV7YLS7VAXLA5CNFSM4X2OOTGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOF2KIG2A.gif]

[gene96817]

Yes, individuals can configure their personal network to give Jamulus packets priority over competing traffic from other members of their household. I would not give this idea to anyone that needed assistance installing Jamulus.

[ghost]

This functionality should be added to the Linux version of Jamulus... and Apple (BSD ) if possible.
IPTOS in Linux sockets programming is obviously Not obsolete.
Otherwise, one will have to configure their router or firewall to set these bits in IP packets.
Maybe someone (MSFT ?) could write a Windows(tm) driver to add IPTOS funtionality

[hoffie]

I like this idea. I've been running my Jamulus servers (and even clients) while adding TOS flags using iptables. Although I haven't done any objective tests, it seems that ping times are reduced.

Having this directly in Jamulus would simplify setups and make this accessible to more people and platforms.

@bjacke Do you know about possible negative side effects, such as routers blocking such packets entirely?

which is known to be very compatible with different kinds of routers without causing problems

Any pointers regarding that maybe?

[bjacke]

IPTOS_LOWDELAY (0x10) is working very well and I'm not aware of broken routers that block those packets openssh has been using IPTOS_LOWDELAY for a long time, then they changed that to af21 because they liked that more for some reason. That change however resulted in a number of boxes to drop those packages then. This is why Debian for example patched their ssh client back to use IPTOS_LOWDELAY insted of af21. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923880
To make a long story short, the TOS value of 0x10 is quite common and known to be working stable.

[pljones]

The first question: can it be done with Qt without writing platform-specific code?

If the answer to that is "No", then alternative solutions need to be considerably harder to implement that making platform-specific changes to Jamulus (which are to be avoided). In addition, the benefit needs to be measurable and deterministic, so that it can be verified that the change is working.

(I'm definitely not saying "Don't do it" - just we don't want code that can't be tested as doing what we say it does. So whoever does this also needs to provide reproducible test cases demonstrating it the improvement.)

[gilgongo]

Does this idea need some discussion before arriving at an implementable spec?

@bjacke @hoffie @gene96817

can it be done with Qt without writing platform-specific code?

I'll take that as a "yes" :-)

(The reason for this is that we're trying to get Issues into a state where we can start tagging and bagging them for a road map, milestones, etc. So unless we have a reasonably clear spec for something, please discuss ideas first, then raise the necessary tickets/ do PRs once we have an agreed plan of action - thanks!)

[ghost]

Here is code that works in Linux. It may even work, as is, with the rest of the platforms... or at least hopefully compile and silently not make a difference. Test it please:

socket.cpp.diff.txt

wireshark shows:
Type of service: 0x10 (Minimize delay)

[hoffie]

Here is code that works in Linux. It may even work, as is, with the rest of the platforms... or at least hopefully compile and silently not make a difference. Test it please:

socket.cpp.diff.txt

wireshark shows:
Type of service: 0x10 (Minimize delay)

Cool, thanks for pushing this!

This currently seems to be using the native API. Would you be willing to push this feature forward and try a Qt-based implementation and create a PR?

From a first glance it looks like Qt would provide the required features (although Windows still doesn't seem to be supported):
QAbstractSocket::TypeOfServiceOption

There's also a QAbstractSocket::LowDelayOption which might be worth investigating (independent from ToS), although I'm not entirely sure if it might only to TCP, based on the docs.

[ghost]

When @bjacke brought this topic up in the context of the Qt documentation, I (and others) assumed the sockets were a Qt implementation. However, when you see what is in /jamulus/src/socket.cpp you discover it is not. This is good because this socket code is pretty much the same across all the platforms... Just look at the Jamulus code that has always been there. All I did was add 3 lines of code (one line is a blank comment for space). I hope one of the main developers will simply add a line or two of code here if/when they are satisfied it is worthwhile. I'm optimistic that Windows should work from what I've seen on the internet (Windows has a setsockopt() function too).

[bjacke]

When @bjacke brought this topic up in the context of the Qt documentation, I (and others) assumed the sockets were a Qt implementation.

sorry if the link to the Qt docs was misleading. I also think that the standard setsockopt() call should be enough actually.
@hoffie: the LowDelayOption is indeed just for TCP.

[bjacke]

Here's an extended version, which also sets SO_PRIORITY, where possible. Linux uses this value to order the networking queues locally.

0001-set-TOS-bit-and-SO_PRIORITY-if-possible.patch.txt

[ghost]

man 7 ip ... Says the following in the IPTOS section:
"Linux sends IPTOS_LOWDELAY datagrams first by default, but the exact behavior depends on the configured queueing discipline."
May this be good enough?

[ghost]

I gave your patch a closer look, and noticed the use of IPPROTO_IPV6 and IPPROTO_IP.

IP_TOS should be tested with IPPROTO_IP, using the main branch (or Jamulus 3.6.2).
Otherwise, other stuff may get in the way.

[bjacke]

the patch is done on my personal branch, which has MR 1017 applied, feel
free to apapt the context and ignore the IPPROTO_IPV6 stuff, the patch itself just adds TOS/SO_PRIORITY

[bjacke]

It depends on the selected device queueing discipline on the Linux machine. For routers the TOS field is more important, for the client or the server machine, the SO_PRIORITY might help to prioritize the Jamulus packets. Mumble, which is also doing low latency voice, does it the same way, it sets both TOS and SO_PRIORITY.

[ghost]

When I read documentation in man for ip and socket, it appears that Linux does more than mark the packet header bits, it expedites the marked packets it receives (and sends). My concern is that SO_PRIORITY may ruin the default packet queueing associated with IPTOS_LOWDELAY. Note that Linux 'is' a router because it is a networking machine. I think it is better to change as little as is necessary.

[bjacke]

I disagree that SO_PRIORITY may ruin the default packet queueing associated with IPTOS_LOWDELAY

I also disagree on the second part about Linux: strictly speaking any computer is kind of o
router, Linux is not different from any other OS here. but when we talk
about router in this discussion, we are talking about edge routers,
which are handing the packages from a local network to the internet. As
mentioned before, for edge routers the TOS bits are important. For
client and server machines, both TOS and also SO_PRIORITY may help,
depending on the queueing algorithm that's in plcae. I doubt that
setting both does any harm.

[bjacke]

I can't build on Windows, but https://docs.microsoft.com/en-us/windows/win32/winsock/ipproto-ip-socket-options states that IP_TOS should not be used, even if it it's defined (not obviously not used) there since Windows 8 / Server 2012.
Someone who is able to build on Windows, might want to check out https://github.com/mumble-voip/mumble/blob/master/src/Connection.cpp to see how it should be made the Windows way.

[ghost]

I read quite a bit of differing opinions on Windows and saw that different versions act differently (eg. Windows CE has no support But Windows XP supports UDP and Windows server 2012 and recent Windows supports even more) MSFT also wants to limit system functionality for hackers and crackers because of weak security. Thus, they discourage the use of useful functionality. I was hoping you could build for Windows server 2012 and newer with IPTOS_LOWDELAY (Not SO_PRIORITY as it may cause the problem). Furthermore, I think it should be possible to build this for XP service pack 2 (also 3)

[ghost]

I've spent some time experimenting with the TOS/DSCP IP header bits.
Here are some of my observations:

• I found bug Wrong include file in /jamulus/src/util.h #1091 because it may cause compile problems in Windows for setsockopt() in Jamulus.
• IPPROTO_IP, IP_TOS, IPTOS_LOWDELAY was tested slightly worse than doing nothing with setsockopt()
• Thus, Type of service: 0x00 is better than Type of service: 0x10
• However, Type of service: 0x68 is better than Type of service: 0x00
• It doesn't seem right that Differentiated Services: 0x68 and Type of service: 0x68 and can be set with:

•  int tos = 0x68; setsockopt ( UdpSocket, IPPROTO_IP, IP_TOS, &tos, sizeof(tos) );
  

• So I set DSCP and TOS with a TOS command !!!
• I also chose 0x68 because it works similarly in DSCP and TOS (and is faster than doing nothing)

****************** Wireshark showing the same ip header bit field as DSCP and also as TOS *****************
Differentiated Services Field: 0x68 (DSCP 0x1A: Assured Forwarding 31; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
0110 10.. = Differentiated Services Codepoint: Assured Forwarding 31 (0x1A)
.... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)

Type of service: 0x68 (Maximize throughput)
011. .... = Precedence: flash (3)
...0 .... = Delay: Normal
.... 1... = Throughput: High
.... .0.. = Reliability: Normal
.... ..0. = Cost: Normal

Please apply this patch for Jamulus 3.7.0 to spite the conventionalists with something that works.
socket.cpp.diff.txt

[bjacke]

• for the Windows port, see the link I send earier to the way mumble solves this
• for the TOS/DCSP bits, see the Debian bug report for ssh I posted and you should make sure that the value you decide for is not causing similar issues.

[dcorson-ticino-com]

Now I get this error: (it's actually pointing to "&tos")
D:\Documents\JamDev\JamUI-02\src\socket.cpp:45: error: cannot convert 'int*' to 'const char*'
..\JamUI-02\src\socket.cpp: In member function 'void CSocket::Init(quint16)':
..\JamUI-02\src\socket.cpp:45:49: error: cannot convert 'int*' to 'const char*'
setsockopt ( UdpSocket, IPPROTO_IP, IP_TOS, &tos, sizeof(tos) );
^~~~

[ghost]

Try
const char tos = 0x68; // DSCP AF31: Assured Forwarding 31 hacked into IP_TOS
in /src/socket.cpp Instead of the following (int tos = 0x68;)

int tos = 0x68; // DSCP AF31: Assured Forwarding 31 hacked into IP_TOS
setsockopt ( UdpSocket, IPPROTO_IP, IP_TOS, &tos, sizeof(tos) );

[dcorson-ticino-com]

OK, now it compiles, but the ping times I see are exactly the same as without the change. I am comparing ping times in the range of 10 to 50ms and see no difference.
With the change, however, the response of the central servers is slower. The Classic server, which always the slowest and in general needs a couple of seconds to respond, takes about 15 seconds for a response.
I will test some more tomorrow.

[bjacke]

ToS and QoS is not making things generally faster, if you have no major other traffic on your internet connection your packages will be sent out as early as possible anyway. If you have other outgoing traffic at your internet connection though AND if your router supports QoS AND honors the ToS bit that was finally added to Jamulus, then your router is able to send out the Jamulus traffic with higher priority, and then you will be able to see better ping times.

[ghost]

Excellent! A few points:

• It would be nice to see if Windows is sending AF31 packets (Wireshark can be used).
• I'm looking at the Overall Delay, not the Ping time. Please compare results several times.
• More DCSP options can be tested if DSCP AF31 is not the best for you.
• Note that AF31 is being sent only client->server because the servers are not updated yet.

[pljones]

@bjacke @DavidSavinkoff @dcorson-ticino-com - thanks for progressing this, looks promising. Is anyone able to provide this as a pull request? Note that we'll likely not take it into 3.7.0 - due to that being in code freeze. If everything looks good, though, it seems simple enough to take forward quickly after that.

[ghost]

I will have to figure out how to make a PR for bug #1091, then make a PR for this.
If it is more expedient, @pljones, you can do what is necessary to make this happen.
There may be a little more testing.
The latest code for Windows (I'll test it with Linux soon) is:
socket.cpp.diff.2.txt

[pljones]

There's no rush.

[dcorson-ticino-com]

On a new morning I see absolutely no difference between with the patch and without the patch on Win10.
Here is a Wireshark dump of a packet (with patch) if that helps.
To this server in France I have a ping of 18ms and overall delay of 31ms with or without patch.
Let me know if there is anything else I can try.
Don

No. Time Source Destination Protocol Length Frame Info
4 0.001966 192.168.1.21 51.158.106.80 UDP 116 ✓ 22175 → 22124 Len=74

Frame 4: 116 bytes on wire (928 bits), 116 bytes captured (928 bits) on interface \Device\NPF_{245DB840-67E5-4BE0-A522-4FCDF423D0CB}, id 0
Interface id: 0 (\Device\NPF_{245DB840-67E5-4BE0-A522-4FCDF423D0CB})
Interface name: \Device\NPF_{245DB840-67E5-4BE0-A522-4FCDF423D0CB}
Interface description: Ethernet
Encapsulation type: Ethernet (1)
Arrival Time: Feb 27, 2021 11:21:03.813059000 W. Europe Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1614421263.813059000 seconds
[Time delta from previous captured frame: 0.000333000 seconds]
[Time delta from previous displayed frame: 0.000333000 seconds]
[Time since reference or first frame: 0.001966000 seconds]
Frame Number: 4
Frame Length: 116 bytes (928 bits)
Capture Length: 116 bytes (928 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:udp:data]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: LCFCHeFe_39:24:2a (f8:75:a4:39:24:2a), Dst: AVMAudio_d6:46:80 (5c:49:79:d6:46:80)
Destination: AVMAudio_d6:46:80 (5c:49:79:d6:46:80)
Address: AVMAudio_d6:46:80 (5c:49:79:d6:46:80)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Source: LCFCHeFe_39:24:2a (f8:75:a4:39:24:2a)
Address: LCFCHeFe_39:24:2a (f8:75:a4:39:24:2a)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.21, Dst: 51.158.106.80
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 102
Identification: 0x2709 (9993)
Flags: 0x00
0... .... = Reserved bit: Not set
.0.. .... = Don't fragment: Not set
..0. .... = More fragments: Not set
Fragment Offset: 0
Time to Live: 128
Protocol: UDP (17)
Header Checksum: 0x0000 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.1.21
Destination Address: 51.158.106.80
User Datagram Protocol, Src Port: 22175, Dst Port: 22124
Source Port: 22175
Destination Port: 22124
Length: 82
Checksum: 0x600f [unverified]
[Checksum Status: Unverified]
[Stream index: 0]
[Timestamps]
[Time since first frame: 0.001966000 seconds]
[Time since previous frame: 0.000333000 seconds]
UDP payload (74 bytes)
Data (74 bytes)

0000 04 7e f6 a1 d6 59 fa 09 a7 1e 04 ce 05 7d d3 10 .~...Y.......}..
0010 9d d2 e0 1b 8d b1 8d 71 d2 d5 0f 08 16 de d5 b0 .......q........
0020 d6 ec 27 53 f8 c0 8b 21 aa 60 06 2c e7 61 ba 63 ..'S...!.`.,.a.c
0030 a2 db 0b ae a7 ba 71 07 f6 e8 33 f1 2d 92 6e 4f ......q...3.-.nO
0040 c9 6d 98 92 76 00 6d 2d 89 f2 .m..v.m-..

[ghost]

Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.21, Dst: 51.158.106.80
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)

I can see here that your computer sent a packet to a jamulus server in Paris,
( Src: 192.168.1.21, Dst: 51.158.106.80 )
and that your computer did Not set Differentiated Services Field: 0x68.
( Differentiated Services Field: 0x00 )

Thus, Windows (using this code) compiles and runs, but does not set the bits.
(Note that this code sets the bits in Linux. Windows may set the bits with different code)

[bjacke]

I would really trust the way the mumble developers implemented it for Windows in https://github.com/mumble-voip/mumble/blob/master/src/Connection.cpp

[ghost]

Mumble probably alters the Windows Registry to get this done, as it appears Windows will not allow an application to do it in code.

[ghost]

Prior to Windows Vista / Server 2008, Windows allowed software developers to set the
Quality of Service (QoS) tags on traffic.
With the release of Vista / Server 2008, Microsoft began to overwrite any DSCP values
that were set by applications and set them to 0, basically it didn’t trust software to set
those values.
You can set the DSCP bits in Windows by following the instructions here:
https://www.voiceelements.com/docs/programmable-voice/how-do-i/setup-qos-settings-in-windows/
(the example uses 46. use 31 instead)
Note that you do not need the patch to make this work.

[pljones]

Weird, so rather than let the application developer set the required value, they let the end user set some random value? Oh well, I'm sure Microsoft Knows Best.

[dcorson-ticino-com]

Well I tried using the group policy just now. It does set the bits for the DSCP, I see the DSCP 31 now.
But the ping and overall delay times are strictly the same as without those bits set.
I tested on servers to Paris, Frankfurt, Moscow and New York.

[ghost]

Maybe you could try more values to see which are better, worse, or the same.
The following link has a chart of values:
https://www.tucny.com/Home/dscp-tos

[bjacke]

I know I repeat myself: You should look at the mumble code I quoted before. The way mumble implements setting the ToS bits inside the application for Windows works properly just verified this with Windows 10.

[ghost]

@dcorson-ticino-com got the DSCP AF31 bits to work for Jamulus on Windows by changing the Windows Registry.
It would be good to know if Mumble changed the Resgistry, please check on your computer.
Note that I'm an armchair engineer here; without a Windows computer.
If you can compile Jamulus on your Windows computer, maybe you could try some Mumble code in Jamulus.

[dcorson-ticino-com]

Mumble does what you say for Linux and calls a method called QOSAddSocketToFlow for Windows.
I have no idea what this does, but it doesn't sound like changing the registry.
I am not motivated to go further now as with the group edit I had Win10 sending packets with af31 according to Wireshark and it changed strictly nothing in the times Jamulus reported to several servers around the world.

[dakhubgit]

I think DSCP AF41 would be appropriate (multimedia conferencing with low packet loss) rather than DSCP AF31 (multimedia streaming with low packet loss).

[ghost]

AF41 may seem to be a logical choice, but it is an underperformer (worse than DSCP 0 for me).
AF41 is also not the only logical choice.
I think Jamulus users will want choice, or something no worse than DSCP 0

Here are values you will find being used by Jamulus servers (sniffed):
(DSCP 0), AF11, CS2, AF21, AF31, CS6, a TOS Bleached Voice-Admit=0x14, and two unexplained values.
of these values AF31 works for me.

[ghost]

I think the discussion set TOS/DSCP IP header bits for routers to prioritize packages was very productive, and a good future reference. QOSAddSocketToFlow for Windows looks very interesting for Windows programmers, have fun with it.

[ghost]

socket.cpp.diff.3.txt

Looking at RFC4594, there is a Real-Time Interactive service class
(DSCP CS4 0x80) that suits Jamulus well for several reasons:

• CS4 0x80 is inconspicuous, and should not attract negative attention.
• Is a 'one liner' of Jamulus code.
• Addresses buffer bloat, and is exactly old TOS compatible.
• Potential for network improvement anywhere between client and server.
• Potential for Low-Loss, Very-Low-Delay, Low-Jitter.
  (lower Jamulus jitter == lower Jamulus delay)
• No downside as compared to the current Jamulus:
  If an old misbehaving ++(non DSCP, TOS Bleaching) router zeros the 3
  most significant bits of 0x80, the result is 0x00 == current Jamulus
  (which is TOS and DSCP best effort priority).
  If a DSCP router changes the priority, it is likely to be >= (DSCP 0)
  (Current Jamulus default).
• (CS4) is a tested improvement over (DSCP 0) in my case.

I propose that CS4 be the Jamulus default for reasons stated above.
This change is fully compatible with older Jamulus versions.
Nobody should have computer issues with this change, unless they are
already marking Jamulus packets with a firewall. They may have to update
their firewall rules to match on CS4.

++ see:
Exploring-DSCP-modification-pathologies-in-the-Internet.pdf

.. If one runs Jamulus as Administrator, it appears that Windows(tm) will set the
IP header TOS field bits. This code should work 'as is' in Windows in this case.

Windows bug patch needed:
https://github.com/orgs/jamulussoftware/projects/2#card-55909395

Wrong include file in /jamulus/src/util.h
Within the /jamulus/src/util.h file:
'# include <ws2ipdef.h>'
Should be replaced with:
'# include <ws2tcpip.h>'
"The Ws2def.h, Ws2ipdef.h, and Wsipv6ok.h header files should never be used directly."

[ghost]

Hi David,
I made your change in my dev version and see no difference. Win10 sends 0x00 both as user and admin.
Of course that means I see no improvements in the ping times. :(

I dug up this picture (removed) on the internet. If you do what the picture suggests, and run as admin, you should be able to see CS4 marked packets. Does this mark the packets? -- NO

Advanced QoS Settings do not work. (picture removed)
Prior to Windows Vista / Server 2008, Windows allowed software developers to set the
Quality of Service (QoS) tags on traffic.
With the release of Vista / Server 2008, Microsoft began to overwrite any DSCP values
that were set by applications and set them to 0, basically it didn’t trust software to set
those values.

You must make a QoS policy to mark the packets for Jamulus because of the aforementioned.

[dcorson-ticino-com]

Hi David,
That is exactly what I did here; #1072 (reply in thread)
I could see the CS4 with Wireshark, but it made exactly no change at all in the ping or overall delay times.
D

[bjacke]

you will not see a difference if your internet connection is not busy with sending lots of other outgoing traffic. Even with a busy network connection you will only see an improvement if your router supports evaluating the ToS/DSCP bits and does priorize that traffic accordingly.So it's not weird if you see no difference in ping times.

[dcorson-ticino-com]

I guess it is useless that I try this out then with 1Gig fiber to the house.

[ghost]

In actual practice, with several musicians connected, the Jamulus experience will be >= to what it is now once every client and server is using CS4 instead of DSCP 0. Maybe just one musician will occasionaly get slightly less jitter and the rest may benefit without even noticing.

[dakhubgit]

In "parallel reinvention of the wheel" context, I am trying out dakhubgit@d206159 for today's rehearsal (on the server and my own client: as the only Linux user apart from the server, I have no way to test with the other users' Jamulus clients for now).

I have no idea who interprets those bits if at all, but the hope would be that it would help with how the computing center hosting our server decides to schedule traffic. Steep hope, I know...

[dakhubgit]

Well, I am not fond of the "select DSCP values" idea overall since the main point of DSCP is to announce what one needs bandwidth and latency for in order to distribute resources according to needs. Once the user gets to select your value, everybody tries what settings earns the highest totals for him, making the system collapse. There are strategies for trying to deal with that approach to make sure you don't get to pick all of low-latency, high-reliability, high-throughput at the cost of others, but they are likely somewhat fragile. It would likely also make sense to reserve the low-latency requests to the actual audio streams, but then I don't expect a lot of the other traffic to have significant bandwidth impact.

[ghost]

An alternative solution would be to have a command line switch for the server (the administrator), and the client attempts to comply with server. (Actually this is the only way to do this, otherwise the server will be forced to do whatever silly stuff different clients want).

[bjacke]

this is not correct. The server-site edge router might evaluate DSCP bit diffently from the client-site edge router. In any case the one site's choice of DSCP bits does not influence the other site's behaviour.

[gene96817]

@dakhubgit I completely agree. Over the years, the only working use of DSCP (and predescessor systems) requires an IT group that has complete control over the routers, the servers, and the users using the network. Without a central authority, the system cannot handle multipe top priorities.

(I can't fix the formatting of this entry... mystified.)

[ghost]

@bjacke I was assuming that both client and server would use the same DSCP value.
What is your opinion of how to use DSCP values in Jamulus?

Note that this is a free-for-all with wireless users (use extreme DSCP) and gamers (google it).
Try this while observing with Wireshark:
ping -Q 0x00 n.n.n.n
ping -Q 0x80 n.n.n.n
ping -Q 0xFF n.n.n.n
Where n.n.n.n is an IPV4 addr.
Notice that the DSCP value makes the round trip.

[bjacke]

also note that DSCP bits influence the outgoing traffic, there is nothig "silly" that a client can do to force the server to do something differently reguarding his DSCP preference.

[ghost]

What I was tying to express here was: If the server were to reply with the same DSCP as the client, it would have to deal with many different DSCP values.

[ghost]

Well, I am not fond of the "select DSCP values" idea overall since the main point of DSCP is to announce what one needs bandwidth and latency for in order to distribute resources according to needs. Once the user gets to select your value, everybody tries what settings earns the highest totals for him, making the system collapse. There are strategies for trying to deal with that approach to make sure you don't get to pick all of low-latency, high-reliability, high-throughput at the cost of others, but they are likely somewhat fragile. It would likely also make sense to reserve the low-latency requests to the actual audio streams, but then I don't expect a lot of the other traffic to have significant bandwidth impact.

@dakhubgit I completely agree. Over the years, the only working use of DSCP (and predescessor systems) requires an IT group that has complete control over the routers, the servers, and the users using the network. Without a central authority, the system cannot handle multipe top priorities.

(I can't fix the formatting of this entry... mystified.)

These users use DSCP more correctly than what is written in textbooks:
https://www.gargoyle-router.com/phpbb/viewtopic.php?t=12126
Because the guys that made DSCP have many deprecated RFC's. Whereas others have something to play with.

[bjacke]

I'm getting exchaused about the quite long discussions about this topic while at the same time the topic is not really understood by some of the people.

I recommend to make the DSCP value configurable via a command line option (only) but both for server and client.

[ghost]

Yesssss!

[ghost]

It is here.
DSCP Quality of Service #1310