On Thu, Feb 19, 2015 at 11:18 AM, Ted Lemon <mel...@fugue.com> wrote: > On Feb 19, 2015, at 2:11 PM, Mikael Abrahamsson <swm...@swm.pp.se> wrote: >> I'd imagine it's easier to do AQM on routed ports instead of switched ports >> as well, that's where I can imagine CeroWRT choosing this approach. > > I don't think it is easier to do AQM on routed ports. If you do the easy > version of AQM for switched ports, that's easy; if you do per-port AQM I > think it's equally hard in both cases.
In either case AQM and FQ has to be per port in the switch hardware itself. I have been patiently awaiting for that sort of hardware to arrive. On most consumer routers the cpu forwarding path isnt capable of gbit rates in the first place. If you are doing software bridging (say between wired and wireless), you apply fq_codel to the underlying interfaces, not the bridge, and you are golden, except for dealing with multicast... >The plumbing for the L2 solution would look different than for the L3 >solution, and that might make it trickier, though. > > CeroWRT did this, as far as I understand it, because Dave wanted to shake out > cross-subnet issues, not because he felt it was technically preferable in the > long run, but perhaps I am misrepresenting his position on the topic. You are correct, I primarily chose routing between tons of interfaces precisely to expose what cross-subnet issues existed in the real world, and to make it be soooo painful as to inspire those writing code that overused multicast to find unicast solutions! The core things that break are things we long ago identified - mdns and local service discovery, notably. (I have generally found that every android app lets me plug in an ip address for a given service, so for me it hasnt been a huge problem - except that not having a dynamic ipv6 to name mapping makes dynamic ipv6 unusable in such cases) The net result is a lot of cero people said to hell with that and went back to bridging everything, instead of working harder on mdns-proxy, cidr, etc. This microcosm of induced routing pain was also intended to show how multicast didnt scale at all into larger wifi networks in the the small business, or educational campus, that are bridged to wifi, here the problems induced by multicast are so crippling as to leading to the vast establishment of things like AP isolation, which disconnects everyone from everyone else, on the same AP, which to me, is a terrible solution. I do note that not bridging ethernet and wifi together in cero has led to making wifi quite a bit more pleasant and less jittery on apps like webrtc, at least for me, and there is work in play on improving wifi´s aggregation handling and multicast queue management coming up soon. >> It's good that we're having this discussions since I seem to not be the only >> one thinking that there should be one port per subnet. I do like occasionally having more than one vlan, but in the general case, routing is far more expensive than switching. The no-nat case here shows the impact of a current 44 entry routing table on downloads, in the present linux 3.18 fib lookup system. http://snapon.lab.bufferbloat.net/~d/openwrt-3.18.7/openwrt-wndr3800-3.18.7.svg and also shows the performance difference between ipv6 and ipv4 on this hardware. There has been some GREAT work on improving linux´s fib lookup system of late, but hardware bridging will always outperform software bridging which will always outperform routing, IMHO. Anyway I cant imagine a homeowner wanting more than 2-3 vlans at most, and most, just one. There is no problem scaling an ethernet broadcast domain to 4096 devices. Using up 16 ports on 16 different /64 subnets is kind of crazy, especially since at least one provider (comcast) is only supplying a /60 in the first place. wifi on the other hand, barely scales to 30 active stations. > Indeed, there are two of you! > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
