From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) (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 3B9D5200346; Tue, 6 Dec 2011 19:58:48 -0800 (PST) Received: by iaen33 with SMTP id n33so354483iae.16 for ; Tue, 06 Dec 2011 19:58:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=s6Sekar03Hsa+Xr5dg1K00nLKmVgWgVKd1Uyo3uA6d8=; b=fN695hxkU73Zd4WKKmyT3GzU8LwcsrnmHVWiJtK3FqDRiiZn9vchjAkeaWeSC/t60M GwtaQNOiu4dqTVMUf+kz0Xp5MbaFn6bIrHyTiPJnz7EqBlXBcxG/EA1A05ZreHNCFri8 JkvK9Q0N2bbderN7hzYBhV7VJ+JG+S+hFhpTs= MIME-Version: 1.0 Received: by 10.50.173.74 with SMTP id bi10mr19631060igc.4.1323230327445; Tue, 06 Dec 2011 19:58:47 -0800 (PST) Received: by 10.231.204.83 with HTTP; Tue, 6 Dec 2011 19:58:47 -0800 (PST) Date: Wed, 7 Dec 2011 04:58:47 +0100 Message-ID: From: Dave Taht To: david@lang.hm Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cerowrt@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Extensive IPv6 support can be dropped from cerowrt rc8 [#317] 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: Wed, 07 Dec 2011 03:58:48 -0000 On Tue, Dec 6, 2011 at 8:33 PM, wrote: > Again, what are you trying to address? there are a lot of issues with IPv= 6, > do you want to be working to solve those, or do you want to focus on > bufferbloat. In the early days... We found that ECN and TOS (diffserv) were not being handled correctly in the linux stack under ipv6. There were routing and encapsulation problems, as well. All that stuff is fixed upstream now. I'm happy. Nor, applications that wanted to use prioritization understood that they needed to use IPV6_TCLASS to do that on IPv6 sockets, not IP_TOS. That's fixed now also in openssh and dropbear, babel, and AHCP. And all that's upstream, too. I'm happier. :) Hopefully other application writers will see how easy it is to do (see bug http://www.bufferbloat.net/issues/249 ) - and gradually incorporate one liner fixes like that into their products. I think, but am not sure, a fix is in the works for making IPv6 mapped sockets do more of the right thing in these cases as well. This reminds me, IPv6 + diffserv is *not* being handled at all STILL in the wireless component of the stack. If you do voip over IPv6, as an example it's being tossed into the hardware BE queue, not the VO queue. I really need to get around to pushing that patch up. To fork off into the diffserv problem a bit harder: It is certainly silly to have the one end-to-end technology that really benefits from 'EF' being set AND from running over IPv6 to be so de-prioritized. The easy part of that patch is merely getting the IPv6 + diffserv part to w= ork, the hard part is getting something more comprehensive in place to do diffserv at leat 95% *right*, as opposed to the half-assed sorta-tos-like implementation we have now. I'd like to see someone take implementing a rollup of the diffserv standard into the linux kernel as a project, as well as finding a clean way to map it into 802.1q and 802.11e. For example, the less than complete implementation on wireless doesn't do the right thing with the 'IMM' bit, tossing interact= ive packets (like, for example, ssh) also into the BE hardware queue rather than someplace saner like VI. I have some patches towards implementing diffserv sanely, based on the drafts here and here - https://github.com/dtaht/Diffserv/issues/5#issuecomment-2133541 http://www.bufferbloat.net/projects/bloat/wiki/Diffserv_RFC (actually, I tossed the iptables method entirely and decided tc was closer to the right thing) but have not got around to finishing them. I'm not the right guy to do so, actually, as it would require buy-in from netdev, the netfilter guys, and linux-wireless. (my diffserv attempt was basically triggered by my observation of the VO qu= eue not being used for ipv6, and grew into a time-sucking rathole) Anyway, so long as whatever approach taken towards diffserv did take ipv6 into account, this component of the project can be handled on 'normal', not embedded systems, done well, and done by someone(s) else. > > if openWRT supports IPv6 you should not remove it, but don't go out of yo= ur > way to provide anything more than openwrt includes unless it directly > supports your goal. In my opinion, getting IPv6 to work well requires a level of investment and involvement well beyond that of the last major project that took it on (japan's wide project), government and industry-wide funding, and a focus on the problems induced by actual day to day usage. While all the above accomplishments thus far *help* put ipv6 on a more level playing field with ipv4, and indicate the value of 'a' project that tries hard to treat the two protocols equally, this cerowrt project does not necessarily need to continue stressing ipv6 at all on the non-existent budget we have. We can fix many bufferbloat-induced problems and get ipv6 working better (now that the above fixes are in place), for 'free'. Continued testing of course, would be helpful and no doubt continually improve ipv6's behavior, but it's a lot of additional effort that can be better expended on stuff that is more crucial to the main goals. --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 FR Tel: 0638645374 http://www.bufferbloat.net