On Mon, Oct 7, 2019 at 9:16 AM Job Snijders <j...@instituut.net> wrote: > > Dear Dave, > > On Mon, Oct 7, 2019 at 4:04 PM Dave Taht <dave.t...@gmail.com> wrote: > > If I can get *one* person in this working group to go down to their > > local coffee shop and make ipv6 work by whatever means necessary (and > > also fix their bufferbloat) - I'll consider my participation in this > > thread a success. > > That may be how you measure success yourself, however I measure > differently: I consider your input in this thread insightful and > valuable, regardless of the coffee shop's connectivity.
:blush: I have some feedback on a couple other things that have gone by on these threads that I guess you just encouraged me to write. You might regret encouraging me, but here's something that just poured out. > Influencing the connectivity of any public place (bar, coffee shop, or > mall) who don't consider their internet access service their core > business, can be really tricky. Any anecdotal data gleaned from that > experience is just that, anecdotal. Every journey begins with a single step. *enough* anecdotal experience (and a unified set of questions to ask) gathered this way turns into scientific evidence and a plan for making things better along this portion of the edge. It's less complicated to turn your local coffee shop owner on than it is to convince an enterprise. (besides, it's fun - I work 2 days a week out of coffee shops - and in my (our!) best interest to make the coffee shop's internet work as good as possible. For all I know the gig will turn into money - if only my patreon was about 10x higher (https://www.patreon.com/dtaht) I could stop working on "pets.com" stuff to stay alive - and try to work on more difficult issues more regularly) So like I said, it would be great if more folk fixed their local coffee shop and got first hand experience at low scale with the real issues remaining with ipv6 deployment. I've worked on a few "newer" ipv6 related technologies that might help speed deployment. as well as observed a few things about networks along the edge. Since I'm new around here, for those that don't know - I used to live in Nicaragua, where I first volunteered for the OLPC project. I fell in love with life down there, until my wifi failed in the rainy season due to bufferbloat (if anyone here wants more of that origin story for how cerowrt came to be, see: https://www.youtube.com/watch?v=Wksh2DPHCDI ). There was zero IPv6 deployed there along the edge when I was last there (and given the political situation, it's unlikely I'll go back soon). There was no local place to tunnel, either. The fiber along the highway between nicaragua and coasta rica had been cut years prior and nobody was moving to replace it. Still, from 2006- 2011 we went from adhoc wifi links going over the mountain to a cable and fiber deployment that sort of worked. The fiber deployment was *weird* single channel stuff, and the cable deployment typically was 5Mbit/1mbit when I was last there (2016). The ISPs cheaped out greatly on all the gear, all the gear was not rated for high temp and humidity and failed a lot, and I have pictures of what your typical electrical and network cabling look like down there that will make you shudder.... Anyway... Multiple small coffee shops and hotels down in SJDS have the most debloated internet possible - 'cause I talked folk into turning stuff on (between surfing excursions and boat drinks) they already had. Over the years I used that distance to test in the real world codel's (and BBR's) response to longer RTTs, and most recently sch_cake ( https://arxiv.org/pdf/1804.07617.pdf ) - (The other major place we test long RTTs is on the island of mauritus) Anyway, my mission #1 is to upgrade the middleboxes worldwide, to fix bufferbloat. While we're doing that it would pay to try and deploy newer stuff like ipv6, DNSSEC, mo' ipv4, observe what users outside the english speaking community are doing, and so on. Here's some traceroutes, please let me talk to them: http://blog.cerowrt.org/post/nicaragua/ All the classic ipv6 over ipv4 tunnelling technologies failed. I was able to get stuff over udp4 to be fairly reliable, but not to any standard anyone here is used to. Power often flickers 6+ times a day, and hitting reload on websites massively common - try to nail up a tcp or ssh connection and good luck for more than a few hours. This was kind of the advantage to trying to do ipv6 tunnels as my ssh connections would survive a blink. But who cares about ssh in a web world? Now, based on some of those experiences - I tended to regard reliable power distribution as a key starting point. Education - in spanish - the next one. How much ipv6 training is there in spanish? Getting ipv4 to work at all is a high demand item due to the tourist trade, and things like skype and whatsapp are the big tourist applications, whatsapp and yourube (due to the literacy problem) the big apps for locals. Cell rolled out *amazinging* in 2011-2016. Everybody - in a country of 1000GDP per head - managed to get a phone with internet on it and used the first applications they were handed. (email is *dead*). I have a funny photo of the local milkman with an ox-drawn cart, tapping away on his phone... Anyway.... I've worked on means to make routing native ipv6 over unnumbered interfaces far, far easier with the babel protocol, and worked on securing it and the RFCs for that are final. The *code* doesn't scale well but at least it works over wireless links better than anything else I know. I tend to regard the ipv6 prefix distribution problem over such a mess of RFC1918 as the biggest problem we have in networks such this. Even with tunnels it's very problematic, even static. DHCPv6-pd over relays? don't make me laugh. like this (In fact, I'd really like to be able somehow get more ipv4 prefixes out to the edge on such networks also. It doesn't make any sense to backhaul everything up to managua over tin cans and string if it were possible to bring up a whole town) Anyway, total aside... > > Kind regards, > > Job -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740
