This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg] Happy Eyeballs bias
- Previous message (by thread): [ipv6-wg] Happy Eyeballs bias
- Next message (by thread): [ipv6-wg] Happy Eyeballs bias
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Mikael Abrahamsson
swmike at swm.pp.se
Wed Oct 26 17:04:18 CEST 2016
On Wed, 26 Oct 2016, Sander Steffann wrote: > HE head start = 300 + (months after 2017-01-01) * 30 I don't believe in this. Trying to deploy something by severely degrading the customer experience in the fail case is worse than just failing it completely. It would be better to keep it at 300 ms (still significant penalty), but instead recommend the OS vendor to install some kind of heuristic to flag for the user somehow that their IPv6 connectivity is degraded, and offer to fault find it... or let's invent some kind of telemetry where these kinds of breakages can be reported to the OS vendor so they can contact the ISP and alert them to the breakage? Also, we still have the problem with PMTU blackhole detection and mitigation. Why isn't this turned on more? -- Mikael Abrahamsson email: swmike at swm.pp.se
- Previous message (by thread): [ipv6-wg] Happy Eyeballs bias
- Next message (by thread): [ipv6-wg] Happy Eyeballs bias
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]