From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6554421F1CE; Tue, 14 May 2013 03:24:11 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so613065ief.40 for ; Tue, 14 May 2013 03:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VzucFvka2tiM5yh7x2yEkkqzuEq4PuXdqhdFwgoUqUo=; b=q6s7JcHUj0FEsWn+53lQZvBp64xFGg6TMieJ5va1EaQJAi8OlcAjHPapaNO6OLd4S8 jyqgOUBhkoLfX4ioX8GXED+0b5YD7gnODiz7wkJ6CqvKYwawpGzf97DnTJtLoE6RQkv4 QV34xrhKkFuZHM0y95Xyx5F4/THAybknk/UnLqmZ09mwowgU6+QoGvGZ5lCtLbfPZH2D iRq6XqCoYkuwR2aw7EwhbJj3tAt/pJGIk98dlsXFCuQc7UE64H9vqk+5K48j2D/eCWa+ ZIlMu9ub2FmKJ7uOBTw8v75DEIf1Ofw35mhzyVtjCtdg/gs3AbAKm1JzInUwOpShoWBe eGug== MIME-Version: 1.0 X-Received: by 10.50.36.169 with SMTP id r9mr1484449igj.96.1368527050519; Tue, 14 May 2013 03:24:10 -0700 (PDT) Received: by 10.64.9.114 with HTTP; Tue, 14 May 2013 03:24:10 -0700 (PDT) In-Reply-To: References: <51817A6F.1080006@superduper.net> <86AA48E0-B5CD-4A94-AF2B-D75178E8C660@gmail.com> <5181CD56.9050501@superduper.net> <71A0D0CD-9095-4AA5-93C3-FF55CC495788@gmail.com> <1368498364.1479.5.camel@ganymede.home> Date: Tue, 14 May 2013 03:24:10 -0700 Message-ID: From: Dave Taht To: Tristan Seligmann Content-Type: multipart/alternative; boundary=14dae934032bb63d6c04dcab08ba Cc: Dan Siemon , codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net, bloat@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] [Bloat] [Codel] Latest codel, fq_codel, and pie sim study from cablelabs now available X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 10:24:11 -0000 --14dae934032bb63d6c04dcab08ba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, May 13, 2013 at 9:56 PM, Tristan Seligmann wrote: > On Tue, May 14, 2013 at 4:26 AM, Dan Siemon wrote: > >> It's pretty easy to configure the Transmission Bittorrent client to mark >> packets. >> > It is not clear to me that transmission correctly marks uTP traffic, particularly on IPv6. grep the current sources for "TCLASS"? > > Unfortunately this only helps with outgoing traffic. Marking on inbound > traffic is at the mercy of the torrent peer and your ISP (in my case, my > ISP seems to overwrite the TOS/DS field indiscriminately, not that you > would want to trust the marking for inbound traffic anyway), and matching > by port is also not feasible as outgoing connections involve a random por= t > on my side, and an arbitrary port on the peer's side. > It is very evident that incoming traffic needs to be re-marked at the gateway, as a huge percentage of traffic I see at one of my sites is marked background that shouldn't be. (or there's a bug in my script) Inappropriately marking traffic as background has side effects on stuff inside the gateway, particularly on wifi, as it gets tossed into the hw background queue, which has different scheduling characteristics than best effort. As for dealing with incoming vs outgoing traffic, it might be possible to use connection tracking to successfully re-mark traffic on incoming to match the outgoing. > -- > mithrandi, i Ainil en-Balandor, a faer Ambar > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --14dae934032bb63d6c04dcab08ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, May 13, 2013 at 9:56 PM, Tristan= Seligmann <mithrandi@mithrandi.net> wrote:
On Tue, May 14, 2013 at 4:26 AM, Dan Siemon <dan@coverfire.c= om> wrote:
It's pretty easy to configure the Transmission Bittorrent client to mar= k
packets.

It i= s not clear to me that transmission correctly marks uTP traffic, particular= ly on IPv6. grep the current sources for "TCLASS"?
=A0
=

=A0Unfortunately this only helps with outgoing = traffic. Marking on inbound=20 traffic is at the mercy of the torrent peer and your ISP (in my case, my ISP seems to overwrite the TOS/DS field indiscriminately, not that you=20 would want to trust the marking for inbound traffic anyway), and=20 matching by port is also not feasible as outgoing connections involve a=20 random port on my side, and an arbitrary port on the peer's side.
=

It is very evident that incoming tr= affic needs to be re-marked at the gateway, as a huge percentage of traffic= I see at one of my sites is marked background that shouldn't be. (or t= here's a bug in my script)

Inappropriately marking traffic as background has side effects on stuff= inside the gateway, particularly on wifi, as it gets tossed into the hw ba= ckground queue, which has different scheduling characteristics than best ef= fort.

As for dealing with incoming vs outgoing traffic, it might be possible = to use connection tracking to successfully re-mark traffic on incoming to m= atch the outgoing.

=A0
--
mithrandi, i Ainil en-Balandor, a faer Ambar

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat




--
Dave T=E4ht

= Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html=20 --14dae934032bb63d6c04dcab08ba--