<p><br>
On Feb 28, 2011 10:41 PM, "Andrew Yourtchenko" <<a href="mailto:ayourtch@gmail.com">ayourtch@gmail.com</a>> wrote:<br>
><br>
> Daniel,<br>
><br>
> On Tue, Mar 1, 2011 at 1:34 AM, Daniel Roesen <<a href="mailto:dr@cluenet.de">dr@cluenet.de</a>> wrote:<br>
> > On Tue, Mar 01, 2011 at 12:07:36AM +0000, Bjoern A. Zeeb wrote:<br>
> >> And, would you have noticed the IPv6 related bug if happy-eyeballs was<br>
> >> already implemented or would legacy IP have worked well enough for you<br>
> >> to not notice (read as - what's better?, getting the bug fixed or not<br>
> >> noticing and harming IPv6 for longer)?<br>
> ><br>
> > IPv6 is not customer-driven, but provider driven. So #1 priority must be<br>
> > that "things keep working" as painless as possible.<br>
> ><br>
> > But you're right in the sense that with Happy Eyeballs we need methods<br>
> > to measure problems being masked by HE. How, is one of the things<br>
> > which seem to be missing in the Happy Eyeballs discussion.<br>
><br>
> Totally agree. Like I told to Bjoern when we met in @fosdem a few<br>
> weeks ago - from the pure engineering point of view I think a good<br>
> thing that could happen is IPv4 would suddenly vanish from the face of<br>
> earth for 3-4 months. Then we notice all the problems and can fix them<br>
> (very fast ;-) (Un)fortunately this is not possible - as it would be a<br>
> major catastrophy from the user experience point of view.<br>
><br>
> Happy Eyeballs is a bit on the other side of the spectrum - by working<br>
> hard to make the UX as seamless as possible indeed it masks these<br>
> kinds of problems - so with it the chances are high that these<br>
> problems will not be noticed. Actually, even more so since the<br>
> opportunistic connection establishment that you mentioned in the first<br>
> mail might not even happy if the single protocol consistently wins (so<br>
> it is not 100% true about the increase in load).<br>
><br>
> We plan a bar bof @Prague, I will definitely bring this topic up there<br>
> too - meantime if you have ideas, feel free to write them up for the<br>
> discussion.<br>
><br>
> Side remark: I noticed this trend overall - the more robust you have a<br>
> protocol to external influences (soft failures instead of hard<br>
> failures), the "nicer" is the user experience, and the more hell is in<br>
> debugging of this protocol for the support/dev folks when the<br>
> experience slowly degrades to the point of being unacceptable. It's a<br>
> tough choice.<br>
></p>
<p>This also creates the ugly situation where customer calls help desk saying website x is down, support person tries to get to website x, and it works. Help desk says, nope "works for me" and the broken ipv6 access or dare I say ipv4 access is broken to the none-HE user but works for the HE user. If the none he-user cannot easily convince others that there is a problem, that is bad. <br>
</p>
<p>This is a support nightmare as HE masks the issue and will not be uniformly deployed -- ever.</p>
<p>This is a classic dilemma. Masking the problem ostensibly makes it go away, but at the same time exacerbates the ability to resolve it. It is kind of like beer :) and beer is good, especially when I been troubleshooting connectivity issues all day and my customers keeping telling me websites are down<br>
... but not all of them ... they all but works for me ....</p>
<p>Cb<br>
> cheers,<br>
> andrew<br>
</p>