wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: "Toke Høiland-Jørgensen" <toke@toke.dk>
To: Daniel Golle <daniel@makrotopia.org>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: passing-through TOS/DSCP marking
Date: Thu, 17 Jun 2021 01:33:12 +0200	[thread overview]
Message-ID: <87v96dpepz.fsf@toke.dk> (raw)
In-Reply-To: <YMpPnKhUuTHNU1Q0@makrotopia.org>

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? If the
bottleneck router is the same one that does the wireguard encapsulation
(e.g., a home router with a slow uplink), you should be able to just use
flow queueing (fq_codel or sch_cake) in place of your diffserv-based
prioritisation and get most of the benefit: wireguard will save the
packet hash before encapsulation, so any qdisc running on the same box
can actually distinguish flows even on the encapsulated packets...

-Toke

  reply	other threads:[~2021-06-16 23:33 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16 13:24 passing-through TOS/DSCP marking Daniel Golle
2021-06-16 16:28 ` Jason A. Donenfeld
2021-06-16 19:26   ` Daniel Golle
2021-06-16 23:33     ` Toke Høiland-Jørgensen [this message]
2021-06-17  7:55       ` Florent Daigniere
2021-06-17  9:41         ` Daniel Golle
2021-06-17 12:24           ` Toke Høiland-Jørgensen
     [not found]             ` <CAMaqUZ09KRtp01OK3u-Di52X_kH9eT4E-wmnPc6QzjSCd5dEiw@mail.gmail.com>
2021-06-17 20:54               ` Toke Høiland-Jørgensen
2021-06-17 23:04             ` Toke Høiland-Jørgensen
2021-06-18 12:24               ` Jason A. Donenfeld
2021-06-21 12:36                 ` Daniel Golle
2021-06-21 14:27                   ` Toke Høiland-Jørgensen
2021-06-30 17:23                     ` Daniel Golle
2021-06-30 20:55                       ` Toke Høiland-Jørgensen
2021-07-04 14:15                         ` Daniel Golle
2021-07-05 15:21                           ` Toke Høiland-Jørgensen
2021-07-05 16:05                             ` Daniel Golle
2021-07-05 16:59                               ` Toke Høiland-Jørgensen
2021-07-05 17:26                                 ` Daniel Golle
2021-07-05 21:20                                   ` Toke Høiland-Jørgensen
2021-07-06  7:00   ` Florent Daigniere
2021-07-06 20:08     ` Luiz Angelo Daros de Luca

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v96dpepz.fsf@toke.dk \
    --to=toke@toke.dk \
    --cc=Jason@zx2c4.com \
    --cc=daniel@makrotopia.org \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).