Re: 100G-LR1 (DR/FR)
On Tue, 4 Apr 2023, Jared Mauch wrote: We are willing to do 100G-LR1 if someone asks these days. It lets us be able to roll it up into 400G optics on our side as appropriate. I hope the industry moves to 100G-LR1, as doing 2x100GBASE-LR4 in a 400G port is quite meh when it comes to faceplate capacity. Unfortunately 100GBASE-LR4 will be with us for a long long time. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: SOHO IPv6 switches
On Tue, 18 Jan 2022, Sean Donelan wrote: What's the goto SOHO-class switch for IPv6? Zyxel/Netgear/TP-Link all have switches in the 100-200USD range that can do some basic stuff (filter on ethertype, some DHCPv6/RA inspection, SNMP polling via IPv6 etc). I was surprised by what I found (and this was 5-8 years ago), but I never went all-in on testing all of this, but looking at the feature set it actually seemed like they tried to support BCP38/SAVI, so I imagine some of these switches are actually used by ISPs as ETTH equipment. https://www.tp-link.com/us/business-networking/managed-switch/tl-sg3428/v2/ "IPv6 functions such as Dual IPv4/IPv6 Stack, MLD Snooping, IPv6 ACL, DHCPv6 Snooping..." -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: IPv6 and CDN's
On Tue, 26 Oct 2021, David Conrad wrote: Ah. Cogent. I suspect IPv6 peering policies. Somebody should bake a cake. According to https://twitter.com/Benjojo12/status/1452673637606166536 Cogent<->Google IPv6 now works. A cake is in order, but perhaps a celebratory one!? -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Never push the Big Red Button (New York City subway failure)
On Fri, 10 Sep 2021, Sean Donelan wrote: 1. The “Emergency Power Off” button did not have a protective cover at the time of the shutdown or the following WSP investigation. Aka "molly-guard". https://en.wiktionary.org/wiki/molly-guard -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Muni broadband sucks (was: New minimum speed for US broadband connections)
On Fri, 4 Jun 2021, Masataka Ohta wrote: As cabling cost is mostly independent of the number of cores in a cable, as long as enough number of cores for single star are provided, which means core cost is mostly cabling cost divided by number of subscribers, single star does not cost so much. Then, PON, needing large closures for splitters and lengthy drop cables from the closures, costs a lot cancelling small cost of using dedicated cores of single star. On the other hand, if PON is assumed and the number of cores in a cable is small, core cost for single star will be large and only one PON operator with the largest share (shortest drop cable from closures to, e.g. 8 customers) can survive, resulting in monopoly. My experience is that people can prove either active-e or pon is the cheapest by changing the in-parameters of the calculation. There are valid concerns/advantages with both and there is no one-size-fits-all. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Muni broadband sucks (was: New minimum speed for US broadband connections)
On Thu, 3 Jun 2021, Mark Tinka wrote: I'll let Mikael confirm, but last time I checked, Stokab was mostly (if not all) Active-E. Sweden is mostly Active-e. There is some PON nowadays though. Stokab typically only rents out dark fiber, so they don't have any of it. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Muni broadband sucks (was: New minimum speed for US broadband connections)
On Thu, 3 Jun 2021, Masataka Ohta wrote: Mark Tinka wrote: Which is the Stokab model. Does it use single star? The city should provide base infrastructure, lease it to operators atthe same price, and get out of the way. End of. With single star topology, that's fine. https://stokab.se/download/18.310b3d5c174c5513aec263/1601471204836/Framtidens%20kommunikationsn%C3%A4t%20LOWRES.pdf It's in swede-crypt, but it boils down to single strand of fiber from a central area node, to the basement, one for each apartment. However, the building owner has to arrange for the cabling within the building. It's single star, and typically the "node" it's all connected to will serve thousands of apartments. So an ISP will colocate in this "node" and can then rent fibers to provide FTTH services, at a fixed monthly cost (last I heard it was in the ~10USD a month range). Stokab isn't alone in this model, they're not the most successful, there are better examples of this. Sweden is also home to a lot of worse examples, all from "muni networks" that will be L2 transport providers, that will have L3 networks, to the ones who are L2/L3 but also sell services themselves. It's a zoo. There is muni broadband that sucks and there is muni broadband that is great. Without defining what kind of muni broadband we're talking about it's impossible to have a productive discussion. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: OT: Re: Younger generations preferring social media(esque) interactions.
On Mon, 22 Mar 2021, Grant Taylor via NANOG wrote: If it's the latter, does that mean that you have to constantly keep changing /where/ messages are sent to in order to keep up with the latest and greatest or at least most popular (in your audience) flavor of the day / week / month / year social media site? All good questions. I've been using IRC+email for 25+ years now and from what I can see, IRC has been replaced by slack/discord etc, and email has been replaced by Reddit or Github Issues discussions etc. I was on a project where the mailing list was shut down and all further discussions were pushed to github instead. I personally think the "web forum" format is inferior but that might be a way to reach out as well... -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: Famous operational issues
On Tue, 16 Feb 2021, John Kristoff wrote: Friends, I'd like to start a thread about the most famous and widespread Internet operational issues, outages or implementation incompatibilities you have seen. Which examples would make up your top three? https://blogs.oracle.com/internetintelligence/longer-is-not-always-better -- Mikael Abrahamssonemail: swm...@swm.pp.se
RE: Texas internet connectivity declining due to blackouts
On Mon, 15 Feb 2021, Sean Donelan wrote: Strange the massive shortages and failures are only in one state. The extreme cold weather extends northwards across many states, which aren't reporting rolling blackouts. https://www.texastribune.org/2011/02/08/texplainer-why-does-texas-have-its-own-power-grid/ Going at it alone can be beneficial sometimes, sometimes it's not. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Sat, 26 Dec 2020, Baldur Norddahl wrote: I demonstrated that it is about buffers by showing the same download from a server that paces the traffic indeed gets the full 930 Mbps with exactly the same settings, including starting window size, and the same path (Copenhagen to Stockholm). You demonstrated that it's about which TCP algorithm they use, probably. They all respond very differently to increase in RTT vs loss. https://arxiv.org/pdf/1903.03852.pdf Generally the Internet doesn't need more buffers, it needs less. If you have only FIFO available, configure it to tail-drop at 10ms or so, to help your customers with what they really care about, interactive performance. I debloat my 1000/1000 with bidir 900/900 FQ_CODEL to avoid my downloads affecting my interactive performance. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Sat, 26 Dec 2020, Baldur Norddahl wrote: It is true there have been TCP improvements but you can very easily verify for yourself that it is very hard to get anywhere near 1 Gbps of actual transfer speed to destinations just 10 ms away. Try the nlnog ring network like this: gigabit@gigabit01:~$ iperf -c netnod01.ring.nlnog.net Client connecting to netnod01.ring.nlnog.net, TCP port 5001 TCP window size: 85.0 KByte (default) [ 3] local 185.24.168.23 port 50632 connected with 185.42.136.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 452 MBytes 379 Mbits/sec Why would you just use 85KB of TCP window size? That's not the problem of buffering (or lack thereof) along the path, that just not enough TCP window size for long-RTT high speed transfers. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Sat, 26 Dec 2020, Baldur Norddahl wrote: That is why. The RTT to the source can not be larger than the minimum buffer size in the transport path. Otherwise the speed will start decreasing. This is no longer correct. There has been lots of TCP innovation since this was true. Please stop repeating it. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Sat, 26 Dec 2020, Mark Tinka wrote: My experience with customers who've bought 1Gbps FTTH service is that on a good day, they may see 500Mbps. On average, they'll live somewhere between 180Mbps - 350Mbps, with a random spot-check. It's alright for providers who offer this to let their NOC's handle the problem, because most users are connected to the Internet wirelessly, using devices that do not require more than a couple of Mbps of bandwidth at a time. Wired devices such as gaming consoles won't tell you anything more than how long it will take a download to complete. So you are not probably going to work out whether the PS5 is running at 1Gbps or 230Mbps, as long as your psyche is happy with the service you are buying from your provider. Steam and Microsoft will say download speed. I regularily see 100MB/s or more. Perhaps there are some issues at other parts of the network that limits their speeds? I'm in Stockholm, Sweden, with plenty of local CDNs located just 1-3ms away from me. Here the "truth" is that if you game, you need to have a wired connection to your gaming computer. All gamers "know" this. I don't have experience with PS5 and perhaps what you're saying is true for that customer base. I'd say it's not true for Xbox or Steam customers as they see speed prominently displayed on the screen. https://support.xbox.com/en-US/help/games-apps/troubleshooting/troubleshoot-slow-game-or-app-downloads-on-xbox-one "Go to My games & apps > Manage > Queue and note the download speed shown on the game or app that’s being installed. " -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Sat, 26 Dec 2020, Mark Tinka wrote: No one argued that Sony could build a half-decent console. Wired via Ethernet, that's unlikely to be the bottleneck. Considering my PC often saturates my 1000/1000 Internet access when downloading, I don't see why the 1GE NIC on PS5 wouldn't be the bottleneck if it's sitting on higher speed Internet access. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: [External] Re: 10g residential CPE
On Fri, 25 Dec 2020, Chris Adams wrote: Queueing doesn't get me my next game in time to play it tonight. I've always seen general queueing as a work-around for "not enough bandwidth and can't add more"... but when more is available, why not just use more? I de-bloat my 1000/1000 with FQ_CODEL. It's worthwhile because even 1000/1000 can see RTT spikes of tens of milliseconds otherwise. Bandwidth doesn't solve queuing and queuing doesn't solve bandwidth. They're both needed. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Fri, 25 Dec 2020, Mikael Abrahamsson wrote: On Thu, 24 Dec 2020, Ben Cannon wrote: Anyone else doing it? Do you like your gear? Haven't tested it myself, but the 10GE residential provider here in Sweden is using some kind of Huawei HGW that typically is used for XGPON but has had its WAN MAC swapped out for 10GBASE-LR use. https://www.sweclockers.com/nyhet/26446-bahnhof-och-huawei-slapper-10-gbit-router-for-hemanvandare You can run it through google translate. Do note that this "news" is from October 2018. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: 10g residential CPE
On Thu, 24 Dec 2020, Ben Cannon wrote: Anyone else doing it? Do you like your gear? Haven't tested it myself, but the 10GE residential provider here in Sweden is using some kind of Huawei HGW that typically is used for XGPON but has had its WAN MAC swapped out for 10GBASE-LR use. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: favourite YANG data-store?
On Wed, 17 Jun 2020, adamv0...@netconsultings.com wrote: Hi folks, Was just wondering what are you folks using as production YANG data store and what do you like about the particular one you're using? Or maybe folks using OANP what is your YANG DS of choice? Plan on using it as in memory DS primarily for service, network YANG modules, (in addition to the usual use case of device modules), - so quite a lot of data as you can imagine storing data for higher abstraction layers Service & Network. Been looking at ODL and Confd thus far. http://www.sysrepo.org/ -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: RIPE NCC Executive Board election
On Wed, 13 May 2020, Elad Cohen wrote: LOL funny seeing you changing your mind by 180 degrees when someone you know in the community writing to you the exact same thing. "In addition, the sockets API should be extended to support IPxl with a new socket domain PF_IPXL which is identical to PF_INET in every respect save that the IP addresses are 8 bytes long instead of 4." Do you realise that this means you're requiring changing *every* socket-speaking application in the world? It's taken us decades to get applications to use the new struct to support IPv6+IPv4, resetting the timer back to 0 and starting over does not help deployment. It just kicks it another 20 years down the line. You're just inventing yet another incompatible standard and you have to touch everything, DHCP, DNS all applications etc. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: CGNAT Solutions
On Wed, 29 Apr 2020, Robert Blayzor wrote: So as a happy medium of about 2048 ports per subscriber, that's roughly a 32:1 NAT/IP over-subscription ? Yes, around that. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: CGNAT Solutions
On Wed, 29 Apr 2020, Robert Blayzor wrote: One would think a 1000 ports would be enough, but if you have a dozen devices at home all browsing and doing various things, and with IOT, etc, maybe not? https://www.juniper.net/documentation/en_US/junos/topics/concept/nat-best-practices.html There are some numbers in there for instance talking about 1024 ports per subscriber as a good number. In presentations I have seen over time, people typically talk about 512-4096 as being a good number for the bulk port allocation size. -- Mikael Abrahamssonemail: swm...@swm.pp.se
Re: ECN
On Wed, 13 Nov 2019, Baldur Norddahl wrote: In any case, is it not recommended that users of anycast proxy packets that arrive at the wrong place? To avoid this kind of issue. In typical anycast deployments there is no feasible way to figure out where the "right place" is. It would be very interesting if your could share what equipment you're using that is doing ECMP hashing based on ECN bits. That vendor needs to fix that or people should avoid their devices. -- Mikael Abrahamssonemail: swm...@swm.pp.se
