From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1SeYC3-0005ro-IU for garchives@archives.gentoo.org; Tue, 12 Jun 2012 21:00:03 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C04EBE05F9; Tue, 12 Jun 2012 20:59:39 +0000 (UTC) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) by pigeon.gentoo.org (Postfix) with ESMTP id CAC30E0698 for ; Tue, 12 Jun 2012 20:57:11 +0000 (UTC) Received: by bkcjk13 with SMTP id jk13so5720734bkc.40 for ; Tue, 12 Jun 2012 13:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=mYtaf8soqStbvuD0NcoY8Q3amx9UZ33Wuvr6ZcsmmPI=; b=OFX3vW4FBllFQifuDgS/v4DtK1JOQnrSJ9zcRTkRHusfZNLbwA9OjtAGxcUOWcpGAV zTti3NiQqpvvt02y57D0tuj5SKlxSOg9ltY+vrJRRMSPWsBeLWnrKK8qkSvfuAhOc6zj LoUOchM3OayYFZSu5C+EN1JhnGN3q9oZyJO2npmcgoNibkaujlr1UOGPQT0asbBI9JMX 5FycMQZy++I1Ict4dLQU08y/pR8hOzCyl6SNw/tppGY4OT0bA9mVeGNoyu9hw4WMd7YN VCQHdKcT4opS/iJFarZ/TXfHu+U3JlAp5Tmk9DjPAFoZWC1HCuC6WhdqFoRG6lRoBZqf +v7A== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.204.129.87 with SMTP id n23mr12245094bks.19.1339534630869; Tue, 12 Jun 2012 13:57:10 -0700 (PDT) Received: by 10.204.42.207 with HTTP; Tue, 12 Jun 2012 13:57:10 -0700 (PDT) In-Reply-To: References: <5bd4ba758840149a5dabfaf4515eb997.squirrel@www.antarean.org> Date: Tue, 12 Jun 2012 16:57:10 -0400 Message-ID: Subject: Re: [gentoo-user] Traffic shaping - downstream data From: Michael Mol To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 455bb17b-0818-48be-96de-67b0a767d099 X-Archives-Hash: 031c17e2a62114c1fab81336e4ab2353 On Tue, Jun 12, 2012 at 4:43 PM, Datty wrote: > > > On Tue, Jun 12, 2012 at 5:05 PM, Michael Mol wrote: >> >> On Tue, Jun 12, 2012 at 11:06 AM, Michael Mol wrote: >> > On Tue, Jun 12, 2012 at 9:37 AM, Datty wrote: >> >> On Tue, Jun 12, 2012 at 2:21 PM, Michael Mol wrot= e: >> >>> On Jun 12, 2012 8:59 AM, "Datty" wrote: >> > >> > [snip] >> > >> >>> More detail later...but make sure your vpn link is not TCP. UDP, fin= e, >> >>> IP-IP, fine, but not TCP. TCP transport for a VPN tunnel leads to ug= ly >> >>> traffic problems. >> > >> >> Ah it is TCP at the moment. Not something I could change too easily >> >> either. >> >> Is it possible to work around or is it not worth fighting with? >> > >> > If all of these cases are true: >> > >> > * You only have TCP traffic going over that VPN >> > * You don't have any latency-sensitive traffic going over that VPN (no >> > VOIP, no interactive terminal sessions and you won't pull your hair >> > out over 10s or more round-trips slowing down page loads) >> > * You don't have large bulk data transfers going over that VPN (my >> > best example of personal experience here was trying to locally sync my >> > work-related IMAP mailbox) >> > >> > ...then it's not worth fighting with. >> >> I could stand to be more precise and concise: >> If you're going to use a TCP transport for VPN: >> * You need to not mix TCP and UDP traffic >> * You need to not have latency-sensitive traffic. >> >> In practice, you'll almost always have some UDP traffic; that's how >> DNS generally operates. And even where DNS uses TCP, it's still >> latency-sensitive. >> >> So I can be even more concise: >> If you're going to use a TCP transport for VPN, you must avoid having >> TCP traffic over that VPN link. >> >> -- >> :wq > > > Thank you for that very thorough=C2=A0explanation, I had no idea there wa= s a > problem with using TCP, I figured the error correction would help it be m= ore > stable than just throwing data at it and hoping it got there. Somehow I'v= e > avoided the majority of the issues you've mentioned up to now, but then > again generally my connection is very slow so maybe I'm just not feeling = the > effects. My ping however is around 40ms higher over the VPN link so I'm > guessing that may be a sign. > > I'll set up a second vpn tunnel using UDP to test it out, my resistance t= o > changing the main one is purely down to the fact that I have around 30 > clients, probably half of which would reach for antiseptic if I mentioned > TCP and I don't fancy having to drive 200+ miles to each of them to chang= e > it for them. > > I'll give it a shot tomorrow and report back on how it gets on. Regarding > the tc rules I mentioned, do they look alright? I'm not 100% on how it al= l > goes together still and would appreciate a prod in the right direction. > > Thanks again I'd suggest setting up that second VPN link for parallel use, get all the clients up on that one (can you remote admin?), and then take down the old one once the TCP link is no longer actively used. You should be able to do it pretty seamlessly. Regarding the tc rules...no idea off the top of my head. I think when I first saw them I had more questions about topology, but I don't have time to grok it again today. --=20 :wq