Re: passing-through TOS/DSCP marking

[Daniel Golle <daniel@makrotopia.org>]

Hi Florent,

On Thu, Jun 17, 2021 at 07:55:09AM +0000, Florent Daigniere wrote:
> On Thu, 2021-06-17 at 01:33 +0200, Toke Høiland-Jørgensen wrote:
> > Daniel Golle <daniel@makrotopia.org> writes:
> > 
> > > Hi Jason,
> > > 
> > > On Wed, Jun 16, 2021 at 06:28:12PM +0200, Jason A. Donenfeld wrote:
> > > > WireGuard does not copy the inner DSCP mark to the outside, aside
> > > > from
> > > > the ECN bits, in order to avoid a data leak.
> > > 
> > > That's a very valid argument.
> > > 
> > > However, from my experience now, Wireguard is not suitable for
> > > VoIP/RTP
> > > data (minimize-delay) being sent through the same tunnel as TCP bulk
> > > (maximize-throughput) traffic in bandwidth constraint and/or high-
> > > latency
> > > environments, as that ruins the VoIP calls to the degree of not
> > > being
> > > understandable. ECN helps quite a bit when it comes to avoid packet
> > > drops
> > > for TCP traffic, but that's not enough to avoid high jitter and
> > > drops for
> > > RTP/UDP traffic at the same time.
> > > 
> > > I thought about ways to improve that and wonder what you would
> > > suggest.
> > > My ideas are:
> > >  * have different tunnels depending on inner DSCP bits and mark them
> > >    accordingly on the outside.
> > >    => we already got multiple tunnels and that would double the
> > > number.
> > > 
> > >  * mark outer packets with DSCP bits based on their size.
> > >    VoIP RTP/UDP packets are typically "medium sized" while TCP
> > > packets
> > >    typically max out the MTU.
> > >    => we would not leak information, but that assumption may not
> > > always
> > >       be true
> > > 
> > >  * patch wireguard kernel code to allow preserving inner DSCP bits.
> > >    => even only having 2 differentl classes of traffic (critical vs.
> > >       bulk) would already help a lot...
> > > 
> > > 
> > > What do you think? Any other ideas?
> > 
> > Can you share a few more details about the network setup? I.e., where
> > is
> > the bottleneck link that requires this special treatment?
> 
> I can tell you about mine. WiFi in a congested environment: "voip on
> mobile phones". WMM/802.11e uses the diffserv markings; most commercial
> APs will do the right thing provided packets are marked appropriately.
> 
> At the time I have sent patches (back in 2019) for both the golang and
> linux implementation that turned it on by default. I believe that
> Russell Strong further improved upon them by adding a knob (20190318 on
> this mailing list).

Thank you very much for the hint!
This patch is exactly what I was looking for:
https://lists.zx2c4.com/pipermail/wireguard/2019-March/004026.html

Unfortunately it has not received a great amount of feedback back then.
I'll try forward-porting and deploying it now, because to me it looks
like the best solution money can buy :)


> 
> Earlier this month I was approached by a NGO that was trying to do voip
> over satlinks in between ships... there too, any solution has to involve
> DSCP markings.

This is quite exactly the scenario I'm working on :)

Also here, we got multiple uplinks (2x VSAT, 1x 3G/4G/5G, 1x auxilary,
e.g. WiFi client during shipyard times). All those uplinks are often
congested and we can't do anything about their buffer bloat and as all of
them rely on a shared medium, the total amount of available bandwidth
varies quite a bit, which makes it hard to setup meaningful shaping. I
did setup cake qdisc on the upstream links with generously estimated
bandwidth settings, and that did not help a lot.
However, all of those proprietary black-boxes do seem to care about the
DSCP markings and that seems to be the way forward.


Thank you!


Daniel


> 
> Florent
> 
>