On Tue, Aug 25, 2015 at 9:43 AM, Ted Lemon <[email protected]> wrote: > On Aug 25, 2015, at 11:46 AM, Alia Atlas <[email protected]> wrote: > > ECMP or downstream paths is not a research project; it is common used > technology. When the traffic streams desired are larger than can fit across > a single path, it becomes critical. > > > ECMP in a homenet environment, self-configuring and reliable, is a research > project. > > Figuring out how to handle interfering vs. non-interfering paths is, I > think, orthogonal to ECMP. The multiple links > that might interfere can easily be used for different destinations. While > interesting, that seems like a problem that can needs > solving already. Is that piece of the problem a research project? Figuring > out what links interfere? Is this something that would need > a centralized view of the home network?
There is also the quite common powerline to ethernet bridges. I have seen these everywhere I have been in france - the network comes in at one edge of the apartment, the tv is at the other. http://www.cnet.com/topics/networking/best-networking-devices/power-line-adapters/ Given a choice between using wifi as extensively as we do - or using powerline technology, I'd lean towards powerline - except that it too, can suck badly, and in the context of this conversation, ECMP between regular ethernet and a bridged, slow, flaky device like this would also suck. > > This is not a problem that a typical end user needs solved. You do not > need ECMP for 4k Netflix. You do not need ECMP to talk to your IoT > devices. You don’t even need ECMP to talk to your homenet file server, in > the currently unlikely event that it’s not in the cloud (that is, in a rack > in a data center outside the home). ECMP might be _nice_ for the unlikely > in-home file server case, but it is not _necessary_. If you think it is, > it’s probably because you are used to low-performance home routers with > bufferbloat, I note that the de-facto standard for qos+aqm+fq to beat bufferbloat, in openwrt, is fq_codel based, presently. I generally have not had enough gumption to insert language into the homenet documents with a MUST for smart queue management... but it would help uptake in the industry if it were, indeed, mandatory. As one example of an existing problem, many, many existing qos + aqm + fq systems work correctly with ipv4 only, but blow up when faced with ipv6. (this is a problem in openwrt's default qos scripts, fixed in the sqm-scripts, and there is a lot of code out there, like wondershaper, needing to be updated for ipv6) Another example of that problem is that it would be nice to have a standard for fetching "what is my uplink/downlink rate" from isps. upnp has some support for propagating this info, but it is underused and rarely configured properly. > a problem ECMP would not address, and likely would make worse. > We’ve all experienced the home router that, when you try to do a massive > file transfer between two devices, suddenly stops routing anything else > until the transfer is finished. This is not a problem that ECMP would fix. +10 > What I consider to be a research project are: > > - Figuring out that links interfere > - Figuring out what set of links are candidates for ECMP for a particular > pair of endpoints > - Handling unannounced topology changes > > To me this is a classic case of premature optimization. Of course > ultimately we’d like this to work. But it’s not even remotely something > that we care about _right now_. If we ship homenet devices that do not do > ECMP, nobody will even notice. > > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet > -- Dave Täht endo is a terrible disease: http://www.gofundme.com/SummerVsEndo _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
