From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ww0-f41.google.com (mail-ww0-f41.google.com [74.125.82.41]) (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 D28FB200512 for ; Fri, 17 Feb 2012 06:22:57 -0800 (PST) Received: by wgbdt11 with SMTP id dt11so1335471wgb.4 for ; Fri, 17 Feb 2012 06:22:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YEOjA3v5XBsAR6PgSCCqybhXWbtBR+9mrbUKhHM2rp0=; b=UkX5+0e7PcwjOc5klOcyApfnP2lMxhwFdI8UuGBm32xUEQB9mtABrUTtfVTnZfwMWo TUrk6LP/JZQPiCcUdKNEpnpPYg2X6yzE5eUDbgRfgcNvE/MNc5WDfu4+JXIzAn1TNrRK 1a5SS17sKt54i1QWMaPCJF4KTPcGkh9mCrvRk= MIME-Version: 1.0 Received: by 10.180.90.225 with SMTP id bz1mr4080124wib.5.1329488575385; Fri, 17 Feb 2012 06:22:55 -0800 (PST) Received: by 10.223.160.139 with HTTP; Fri, 17 Feb 2012 06:22:55 -0800 (PST) In-Reply-To: <4F3B13B5.8080703@callenish.com> References: <4F3B13B5.8080703@callenish.com> Date: Fri, 17 Feb 2012 14:22:55 +0000 Message-ID: From: Dave Taht To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] Testing Queue models X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 14:22:58 -0000 On Wed, Feb 15, 2012 at 2:08 AM, Bruce Atherton wrote= : > > > On 2/1/2012 12:46 PM, Dave Taht wrote: >> >> I don't have a whole lot of hope for classification. In fact, I'm kind o= f >> upset that the move away from flash means we are seeing more video strea= ms >> on port 80, rather than on the macromedia port... > > > It may be worse than that in the future. Now that Websockets is RFC6455 t= he > nature of traffic on port 80 may change a lot. Roy Fielding was so concer= ned > about it that he asked that a security note be added to the draft spec. What we conventionally think about as the need for firewalling and threat models is increasingly irrelevant, particularly with the advent of new - and standardized, even! - tunneling models like this, as well as devices that live on 3g and wireless at the same time, etc. > No idea what that will mean for your efforts here. Running the entire internet through port 80 and 443, and further, tunneling new applications through that, rather than using specialized and well defined protocols seems like the wrong thing. I have a rant on this topic that amusingly dates to around the time I'd got involved in the bufferbloat effort... http://nex-6.taht.net/posts/Beating_the_speed_of_light_on_the_web/ It's something of a consequence of nat, and may well be a wedge to try and make ipv6 'more right'... On my very backlogged 'round-to-it' list has been writing an xtables module for multi-protocol matching, as the current methods for matching protocols (at least in linux) only support a single match, and as you add protocols becomes tedious, error prone, and slow. iptables -I INPUT -p tcp -j ALLOW iptables -I INPUT -p udp -j ALLOW iptables -I INPUT -p 41 -j ALLOW etc. Better would be something that did a lookup against a 256bit-map ip6tables -I INPUT -m protocols --protocols icmp,tcp,udp,igmp,rdp,dccp,rsvp,gre,esp,ah,ospf,ipip,pim,l2p,isis,sctp,udpl= ite,manet,hip,shim6,wesp -J ALLOW In the hope that this would improve end-to-end connectivity, performance, and availability of new stuff in the general case as ipv6 is rolled out. Regrettably I haven't got around to writing that bit, nor something similar for diffserv.... > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net