On Aug 25, 2015, at 1:02 PM, Alia Atlas <[email protected] <mailto:[email protected]>> wrote: > On Tue, Aug 25, 2015 at 12:43 PM, Ted Lemon <[email protected] > <mailto:[email protected]>> wrote: > On Aug 25, 2015, at 11:46 AM, Alia Atlas <[email protected] > <mailto:[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? > > 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, 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. > > It depends on link speeds in part. My point was merely that this is a > default in link-state routing. It is self-configuring, of course. I was > asking to understand the requirements.
It depends on a lot of things. Link speeds are certainly one thing. Link reliability is another. Whether the router has a good congestion algorithm. How fast the router is (can it actually receive packets at the link speed? can it transmit them at the link speed?). > What I consider to be a research project are: > > - Figuring out that links interfere > > Is this merely the trade-off between using multiple links? I normally assume > that some traffic is carried > across all links. I am not sure why the concept of using multiple paths is > radically different than the basic > problem or why you feel it explodes the complexity? As a practical matter, I wouldn’t actually expect to see multiple paths other than over WiFi, because in order to get multiple paths otherwise, the user has to plug in two cables between the same device, and they aren’t likely to realize that that would give them more bandwidth (and indeed, depending on the bandwidth of the CPU, it might not). So if there are multiple paths, they might be kind of wacky, likely aren’t intentional, and there’s no reason to anticipate that they will perform well. > - Figuring out what set of links are candidates for ECMP for a particular > pair of endpoints > > In most routing protocols, this is trivial and done. I do believe that there > is work to be done for Babel in > this space, if it is needed. I’m a bit naive about ECMP, but I _think_ that the "cost" in ECMP is just a metric. Will that metric be able to represent the real state of the link well enough that it can be automatically used? > - Handling unannounced topology changes > > ?? Isn't that what a routing protocol does - detects and distributes the > topology change? Er, yes, fair point. My imagined worry, which may be bogus, is that a flow will get put on a link that was accidentally configured, and then broken when the user fixes the "mistake," but I will admit that that’s a relatively minor concern, particularly if it can be recovered before the connection dies. > 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. > > Ted, I asked a question about a feature that is considered critical in every > routing environment that I am familiar with. > I find it frustrating that looking ahead to significantly more complex home > networking topologies and link types, which may be > many years out still, is unexceptional, but asking about a feature that > allows better use is described as premature optimization. > I am asking about a routing requirement. I may be naive about this. You seem to think that this will work, and several other people have treated it as plausible. But I just don’t see much hope that it will actually get used, and so if it’s any trouble at all to get it to work reliably, it shouldn’t be a phase 1 requirement. I do not mean to suggest that it should never be something that homenets do.
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
