default TOS marking to 0x04 (LE)

[kjbracey2]

RFC 8622 has added a new "Lower Effort" codepoint to supersede 0x20 (CS1), avoiding the potential problem with CS1 being interpreted as higher precedence than default.

Use of LE rather than CS1 is now recommended:

Existing implementations SHOULD transition to use the unambiguous LE codepoint '000001' whenever possible.

[kjbracey2]

CC @chromi, who set it to 0x20 initially, prior to RFC 8622.

[chromi]

Thanks for looping me in on this.

Firstly, as a technical review, the choice of 0x04 for the TOS byte appears to be correct (this sets the left-justified Diffserv field to 000001 and leaves the right-justified ECN field at 00). Good - getting this wrong is a distressingly common mistake, and tends to result in incorrect ECN fields being seen by AQMs as well as incorrect DSCPs being seen by DS-aware routers. I'm pleased to see people getting it right first time.

I do need to sound a note of caution as to whether this is the right time to implement this change. The LE codepoint is relatively new, and I believe there are still relevant devices that don't implement it, but do implement a useful interpretation of CS1. This means that some users may find that this change removes classification of libtorrent traffic into a scavenging queue, which would adversely impact other traffic sharing that particular bottleneck. I'll lay out some arguments, so that you can make an informed decision.

I think there are three or four places where the Diffserv field might usually be interpreted for a typical user's traffic:

1: At either end of the last-mile ISP subscriber link. I don't think most ISPs interpret Diffserv at their end of this link (for download traffic), but CPE routers increasingly do for upload traffic. At least some CPE routers do implement the LE codepoint - specifically those that use the CAKE qdisc to mitigate bufferbloat, and have incorporated this upstream patch which adds LE support. There are of course other methods to do this, which vendors might choose instead. However, CPE vendors are notorious in general for lagging far behind the bleeding edge of Linux kernels. You might want to check the out-of-box configuration of a representative sample of CPE routers, both new and not-so-new.

2: WiFi access points and client stations have a four-category classification into BK (bulk), BE (best effort), VI (video) and VO (voice), each of which has different MAC-grant parameters to implement a shared-medium prioritisation scheme. The typical implementation of this classification examines only the first three bits of the TOS byte in IP headers, such that BE receives octal digits 0 and 3, BK receives 1 and 2, VI receives 4 and 5, VO gets 6 and 7. CS1 is thus chosen specifically to fall into BK with leading octal 1. Changing traffic to carry LE would cause it to carry a leading 0, putting it in BE. The mapping table would need to be specifically changed in the sending WiFi device to put LE traffic into BK, and it is not only at the CPE device that this must be done, but in the client as well. Again, I suggest examining a representative sample of devices and operating systems.

3: Ethernet interfaces sometimes implement a similar four-category classification to WiFi, but using a mapping table that examines only the first two bits of the TOS byte. I believe these would please both CS1 and LE traffic into the BE queue. This is not a problem, as such Ethernet interfaces are typically Gigabit class and probably aren't the overall bottleneck on the path, except for paths entirely across the LAN.

4: Routers within the ISP backhaul network may use Diffserv information to manage traffic during overloads - which for many consumer ISPs are endemic during peak hours, on a roughly diurnal cycle. Indicating libtorrent traffic using a recognised "scavenging" DSCP is helpful to ISPs in this context, because swarm protocols place a disproportionate load on a network due to the large number of flows involved (with, crucially, congestion controls working independently of each other). In practice, ISPs also often use internal notions of Diffserv based on their own criteria, and both ignore and erase DSCPs applied externally to their own network. We can't directly do anything about the latter case. It's reasonable to assume, however, that ISPs read new RFCs more readily than CPE vendors or application developers, and it may only take the gentle nudge of actually starting to use a new DSCP to convince them to add support for it, if they haven't already.

Best of luck…

[kjbracey2]

One nugget from my quick tests:

1. My Windows 7 box doesn't set TOS on outgoing libtorrent packets anyway. Apparently Windows has/had some weirdness in its TOS socket options. Works on Linux, at least.
2. Incoming traffic showed a mix of DF, AF11, CS1 and LE. There are at least some peers out there already using LE (or someone is setting it for them).

[arvidn]

to make this work on windows, it seems I would need to use the IP_DSCP_TRAFFIC_TYPE option, which is a higher level option than the raw tos-byte.

Does anyone have a suggestion on how to do this?

I could recognize certain ToS-byte settings and map them to the traffic type constants.

[kjbracey2]

Just set it to the TOS value shifted right 2. You only want to be setting the 6 DSCP bits anyway.

Edit: That's assuming that option takes natural DSCP values rather than being a weird Windows enum. Can't find details to confirm. I guess you wouldn't have asked if it was that easy.

Really, you should be clearing the bottom 2 bits when passing values to the standard socket options, or in the libtorrent option setter. If someone configured something there, and the OS obeyed, you could get weird network effects.

The bottom 2 bits are now used for Explicit Congestion Notification, and a transport that doesn't support that should not set them.

(An ECN-capable OS should override those bits on a TCP socket, but it could still let you control them on a UDP socket. A non-ECN OS would probably let you do whatever you like).

It does still make (some) sense for setsockopt to let them be set by user space - you could have a userspace-based transport that supports ECN. But torrent doesn't, so it should leave them as zero.

[kjbracey2]

Oh, and note that the table here suggests that Windows 7 didn't support IP_TOS, but later versions do.

https://docs.microsoft.com/en-us/windows/win32/winsock/ipproto-ip-socket-options

It may be you don't need to do anything for IPv4 if you don't care about Win7.

But IPV6_TCLASS is not shown at all on the IPv6 pages. So maybe you do to make IPv6 work?

[arvidn]

does this look reasonable? #6647

[xavier2k6]

@arvidn do the docs at https://www.libtorrent.org/reference-Settings.html#peer_tos also need to be updated to reflect this change in default setting?

[kjbracey2]

I believe the relevant text there is autogenerated from the source, and that was updated in this PR (although I didn't do a format check).

[arvidn]

that's right. the html is generated from the source comments. the web site will be updated with the next release