On Nov 13, 2012, at 2:24 AM, Brian E Carpenter <[email protected]> wrote: > even if it's the equivalent > of the beeping from a smoke detector whose battery is fading.
To which the typical response is to throw the damned thing through the window out of rage after it's been beeping for a couple of hours. No, there are several viable solutions to this problem that don't involve beeping. Beeping is not the right solution. I would just like to point out, regarding the bufferbloat problem, that there are two classes of outcome if we hack around this problem instead of beeping. The first class of outcome is that something works less well than it otherwise would have. This is the bufferbloat problem. If you have bufferbloat because you set up a bridge where ideally you shouldn't have, this is bad, and the customer will experience less than ideal outcomes. But fundamentally, their network will function, particularly when loads are light. And so this becomes a problem that they will either live with, or try to solve, but it is not an emergency. It is a bad outcome, and the villain is clear: it's the ISP who gave out a /64. FAQs on the net can cast the blame appropriately, and the home gateway can provide diagnostics that explain why the situation is suboptimal. Contrast this with NAPTv6. In this case, the network is _broken_. End to end doesn't work. If you are not connected directly to the border gateway, certain protocols simply will not work. The result of this will be a general expectation on the part of applications vendors that end-to-end isn't something that can be counted upon. And so we will have got nothing for all our effort in deploying IPv6. We'll be back to NAT-inspired walled gardens. Let's at least set our sights on the better outcome: the one that preserves end to end. Yes, it's not ideal. But the blame will be cast on the correct villain, the end-user will at least have a chance of a good outcome, and it won't needlessly break end-to-end. _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
