Re: NANOG list errors
On Tue, 17 Jul 2018 23:24:51 -0500, Andy Ringsmuth said: > Fellow list members, > The last several days, Iâve been receiving mail forwarding loop errors for > the list. Iâll receive them several hours after sending a message. Iâll > paste > the latest two of them below, separated by % symbols. > Anyone able to sort this out and fix? Protip: mail forwarding loops almost always require seeing all the Received: headers to correctly diagnose.. I had one of these show up earlier. I'm willing to send to offline to somebody who can act on it. pgpXQm1MX5hJl.pgp Description: PGP signature
NANOG list errors
Fellow list members, The last several days, I’ve been receiving mail forwarding loop errors for the list. I’ll receive them several hours after sending a message. I’ll paste the latest two of them below, separated by % symbols. Anyone able to sort this out and fix? %%% This is the mail system at host mail.nanog.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : mail forwarding loop for nanog@nanog.org Reporting-MTA: dns; mail.nanog.org X-Postfix-Queue-ID: 2B72F160040 X-Postfix-Sender: rfc822; a...@newslink.com Arrival-Date: Wed, 18 Jul 2018 03:41:57 + (UTC) Final-Recipient: rfc822; nanog@nanog.org Original-Recipient: rfc822;nanog@nanog.org Action: failed Status: 5.4.6 Diagnostic-Code: X-Postfix; mail forwarding loop for nanog@nanog.org From: Andy Ringsmuth Subject: Re: Proving Gig Speed Date: July 17, 2018 at 9:53:01 AM CDT To: NANOG list > On Jul 17, 2018, at 9:41 AM, Mike Hammett wrote: > > 10G to the home will be pointless as more and more people move away from > Ethernet to WiFi where the noise floor for most installs prevents anyone from > reaching 802.11n speeds, much less whatever alphabet soup comes later. > > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com Well, in a few years when we’re all watching 4D 32K Netflix on our 16-foot screens with 5 million DPI, it’ll make all the difference in the world, right? Tongue-in-cheek obviously. Andy Ringsmuth a...@newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397(402) 304-0083 cellular %% This is the mail system at host mail.nanog.org. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system : mail forwarding loop for nanog@nanog.org Reporting-MTA: dns; mail.nanog.org X-Postfix-Queue-ID: 2F2AA160040 X-Postfix-Sender: rfc822; a...@newslink.com Arrival-Date: Wed, 18 Jul 2018 03:46:02 + (UTC) Final-Recipient: rfc822; nanog@nanog.org Original-Recipient: rfc822;nanog@nanog.org Action: failed Status: 5.4.6 Diagnostic-Code: X-Postfix; mail forwarding loop for nanog@nanog.org From: Andy Ringsmuth Subject: Re: Proving Gig Speed Date: July 17, 2018 at 11:12:22 AM CDT To: NANOG list > On Jul 17, 2018, at 10:44 AM, Mark Tinka wrote: > > > > On 17/Jul/18 16:41, Mike Hammett wrote: > >> 10G to the home will be pointless as more and more people move away >> from Ethernet to WiFi where the noise floor for most installs prevents >> anyone from reaching 802.11n speeds, much less whatever alphabet soup >> comes later. > > Doesn't stop customers from buying it if it's cheap and available, which > doesn't stop them from proving they are getting 10Gbps as advertised. > > Mark. I suppose in reality it’s no different than any other utility. My home has 200 amp electrical service. Will I ever use 200 amps at one time? Highly highly unlikely. But if my electrical utility wanted to advertise “200 amp service in all homes we supply!” they sure could. Would an electrician be able to test it? I’m sure there is a way somehow. If me and everyone on my street tried to use 200 amps all at the same time, could the infrastructure handle it? Doubtful. But do I on occasion saturate my home fiber 300 mbit synchronous connection? Every now and then yes, but rarely. Although if I’m paying for 300 and not getting it, my ISP will be hearing from me. If my electrical utility told me “hey, you can upgrade to 500 amp service for no additional charge” would I do it? Sure, what the heck. If my water utility said “guess what? You can upgrade to a 2-inch water line at no additional charge!” would I do it? Probably yeah, why not? Would I ever use all that capacity on $random_utility at one time? Of course not. But nice to know it’s there if I ever need it. Andy Ringsmuth a...@newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397(402) 304-0083 cellular && Andy Ringsmuth a...@newslink.com 5609 Harding Dr. Lincoln, NE 68521 (402) 304-0083 cellular
Blizzard, Battle.net connectivity issues
Could I get an off list reply from blizzard engineers. Your email system is blocking our emails as spam, and I'm trying to resolve some geolocation issues that disallow our mutual customers to access your services. Thank you Michael Crapse Wi-Fiber, Inc.
Re: Proving Gig Speed
On Wed, 18 Jul 2018 at 00:47, Alan Buxey wrote: > another prediction would be that your internet connection (and most devices > in house) connected by 5G - maybe with some local > WiFi - 802.11ax - if theres still spectrum left after the LTE groups have > taken it all for aforementioned 5G purposes... Already fairly common in Finland to have just LTE dongle for Internet, especially for younger people. DNA quotes average consumption of 8GB per subscriber per month. You can get unlimited for 20eur/month, it's much faster than DSL with lower latency. And if your home DSL is down, it may affect just you, so MTTR can be days, where as on mobile MTTR even without calling anyone is minutes or hour. Even more strange, providers, particularly one of them, is printing money. It's not immediately obvious to me why this the same fundamentals do not seem to work elsewhere. In Cyprus I can't buy more than 6GB contract and connectivity is spotty even in urban centres, which echoes my experience in US and central EU. -- ++ytti
Re: Proving Gig Speed
hi, another prediction would be that your internet connection (and most devices in house) connected by 5G - maybe with some local WiFi - 802.11ax - if theres still spectrum left after the LTE groups have taken it all for aforementioned 5G purposes... legacy devices, still around for another decade or more can have some 2.4GHz connectivity - that ISM band is troublesome to repurpose thanks to all the medical and video senders etc. big old wild west there... alan
Re: Proving Gig Speed
--- mark.ti...@seacom.mu wrote: From: Mark Tinka As Trump said..." -- That should be added to Godwin's Law! >:-/ https://en.wikipedia.org/wiki/Godwin's_law scott
Looking for Facebook NOC
Hi, Our network in Asia Pacific region was always allocated to Ashburn / Lonodn CDN. I'll be very grateful if there's someone from Facebook NOC could give us a hand to troubleshoot this off list. Best Regards, Siyuan Miao
RE: deploying RPKI based Origin Validation
> Job Snijders wrote : >I calculated this here few days ago > http://instituut.net/~job/rpki-report-2018.07.12.txt > Markus Weber from KPN is generating a daily report here and drew similar > conclusions: https://as286.net/data/ana-invalids.txt Markus scrapes all > routes from the AS 286 PEs and marks the routes for which no valid or > unknown alternative exists as "altpfx=NONE". If I understand this correctly, I have a suggestion : update these files at a regular interval (15/20 min) and make them available for download with a fixed name (not containing the date). Even better : have a route server that announces these prefixes with a :666 community so people could use it as a blackhole. This would not remove the invalid prefixes from one's router, but at leat would prevent traffic from/to these prefixes. In other words : a route server of prefixes that are RPKI invalid with no alternative that people could use without having an RPKI setup. This would even work with people who have chosen do accept a default route from their upstream. I understand this is not ideal; blacklisting a prefix that is RPKI invalid may actually help the hijacker, but blacklisting a prefix that is RPKI invalid AND that has no alternative could be useful ? Should be considered a bogon. Regards, Michel. TSI Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not the intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you!...
Re: deploying RPKI based Origin Validation
I don't want to over-state it, but 'number of prefices' slways feels to me like a potential mis-measure. Not that you don't want to know it, but % of announced space for a given origin-as feels like it might be closer to the story, because there can be so many different ways to announce it as dis- and super aggregates. -G On Tue, Jul 17, 2018 at 1:55 PM, Job Snijders wrote: > On Tue, Jul 17, 2018 at 01:27:09PM +0200, Mark Tinka wrote: >> > Markus Weber from KPN is generating a daily report here and drew >> > similar conclusions: https://as286.net/data/ana-invalids.txt Markus >> > scrapes all routes from the AS 286 PEs and marks the routes for >> > which no valid or unknown alternative exists as "altpfx=NONE". >> >> Thanks. Protein. >> >> So the numbers are not that far off from when I last checked this back >> in 2016, i.e., less than 1% of the total IPv4 routing table. >> >> Do you have numbers for IPv6, out of interest? > > There are ~ 330 IPv6 invalids in the DFZ, and for 70 of those no > alternative covering prefix exists. > > Kind regards, > > Job
Re: Proving Gig Speed
> From: "James Bensley" > Also I recommend you test to a server on you network near to your > peering & transit edge. This way users can test up to the point where > you would have over the "The Internet" and have no further control. > Testing to a server off-net (like off-net Ookla tells me nothing in my > opinion). ... On 17 July 2018 at 15:36, Mike Hammett wrote: > It tells you how good your peering is. ;-) Or transit :) Cheers, James.
Re: Proving Gig Speed
On 17 July 2018 at 17:18, Mike Hammett wrote: > I don't think you understand the gravity of the in-home interference issue. > Unfortunately, neither does the IEEE. > > It doesn't need to be in lock-step, but if a significant number of homes have > issues getting over 100 megabit wirelessly, I'm not sure we need to be > concerned about 10 gigabit to the home. Maybe leaky feeder cables will become the norm, running along the walls/ceilings of all new build homes? But assuming a wired connection within the premises for a moment, and that we get 1Gbps over that wired connection, because we all have FTTH: For the question of "does it make any difference (1Gbps/10Gbps instead of 100Mbps)": If I download a 4K movie to watch it should take an order of magnitude less time at 1Gbps than 100Mbps. Or even when streaming, my player will fetch a video chunk/segment that is typically in the 3-10 seconds range, I would fetch each chunk much quicker, and so my ISPs connection spends more time idle, which means their backbone carries a higher volume of traffic for a smaller period of time. There is some benefit to be had in the balance of a user consuming X Mbps across the backbone for Y seconds or X^2 Mbps but for Y/10 seconds. It expect it would affect oversubscription and content ratios. Cheers, James.
Re: Proving Gig Speed
On Tue, 17 Jul 2018 13:44:07 -0400, b...@theworld.com said: > Do they need 10gb? Or do they need multiple 1gb (e.g.) channels which > might be cheaper and easier to provision? Doesn't DOCSIS channel bonding already do that? pgp9iFUM4Ez85.pgp Description: PGP signature
Re: deploying RPKI based Origin Validation
On Tue, Jul 17, 2018 at 01:27:09PM +0200, Mark Tinka wrote: > > Markus Weber from KPN is generating a daily report here and drew > > similar conclusions: https://as286.net/data/ana-invalids.txt Markus > > scrapes all routes from the AS 286 PEs and marks the routes for > > which no valid or unknown alternative exists as "altpfx=NONE". > > Thanks. Protein. > > So the numbers are not that far off from when I last checked this back > in 2016, i.e., less than 1% of the total IPv4 routing table. > > Do you have numbers for IPv6, out of interest? There are ~ 330 IPv6 invalids in the DFZ, and for 70 of those no alternative covering prefix exists. Kind regards, Job
Re: Proving Gig Speed
SoIP surely will sure require trigabits. Mike On 7/17/18 8:38 AM, Saku Ytti wrote: On Tue, 17 Jul 2018 at 17:45, Mike Hammett wrote: 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. I admire your confidence, when historically we've had poor success in these type of predictions. I seriously doubt we're now living in special time in history where we find the limit of consumer bandwidth demand, while I have no idea what would drive it or how it would be implemented, I'm betting against myself having all the information about future.
Re: Proving Gig Speed
On 17 July 2018 at 12:50, Mark Tinka wrote: > But to answer your questions - for some customers, we insist on JDSU > testing for large capacities, but only if it's worth the effort. > > Mark. Hi Mark, Our field engineers have 1G testers, but even at 1G they are costly (in 2018!), so none have 10Gbps or higher testers and we also only do this for those that demand it (i.e. no 20Mbps EFM customer ever asks for a JSDU/EXO test, because iPerf can easily max out such a link, only those that pay for say 1G over 1G get it). Hardware testers are the best in my opinion right now but it annoys me that this is the current state of affairs, in 2018, even for 1Gbps! Cheers, James.
Re: Proving Gig Speed
Re: 10gb TTH Just a thought: Do they need 10gb? Or do they need multiple 1gb (e.g.) channels which might be cheaper and easier to provision? -- -Barry Shein Software Tool & Die| b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD The World: Since 1989 | A Public Information Utility | *oo*
Re: Proving Gig Speed
On 17 July 2018 at 09:54, Saku Ytti wrote: > On Tue, 17 Jul 2018 at 10:53, James Bensley wrote: > >> Virtually any modern day laptop with a 1G NIC will saturate a 1G link >> using UDP traffic in iPerf with ease. I crummy i3 netbook with 1G NIC >> can do it on one core/thread. > > I guess if you use large packets this might be true. But personally, > if I'm testing network, I'm interested in latency, jitter, packet, bps > _AND_ pps goals as well, not just bps goal. Hi Saku, Yeah I fully agree with what you are saying however, the OPs question sounds like he "only" needed to prove bandwidth. With 1500 byte frames I've run it up to nearly 10Gbps before (it was between VMs in two different DCs that were having slow transfers and the hyper-visors had 10G NICs, so I dare say, on bare metal with large frames it will do 10Gbps). > And I've never seen clean > 1Gbps on iperf with small packets. It just cannot be done, even if > iPerf was written half decently and it used recvmmsg, it still > wouldn't be anywhere near. > Clean 1Gbps with small packets in user space is actually very much > doable today, just you can't use UDP socket, you must use AF_PACKET on > Linux or BPF on OSX and you can write portable 1Gbps UDP > sender/receiver. > I'm very surprised we don't have iperf like program for netengs which > does this and reports latency, jitter, packet loss with binary search > for highest lossless pps/bps rates. I absolutely agree there is a gap in the open source market for this exact application. A tool that sends traffic between Tx and Rx (or bidirectionally) at a specified frame size and frame rate, which can max out 10Gbps at 64 byte frames if required (I say 10Gbps instead of 1Gbps because 10Gbps as an access circuit speed is being increasingly common), and throughout the test it should report RTT and one way latency, jitter and packet loss etc. and then output the results in a format that is easy to parse. It should also have a JSON API and be able to run in a "daemon" mode like an iPerf server that is always on ready for people to test to/from. > I started to write one with Anton Aksola in Rust (using libpnet[0]), > and implemented quite flexible protocol (server/client, client can ask > server exactly what kind of packet to construct/expect, what rate to > send/receive over JSON based protocol), so you could also use it to > ask it to DDoS your routers control-plane in lab etc. And actually got > it working, OSX+Linux ~wirarate (still needs higher end laptop to do > 1.5Mpps on single core and we didn't implement multicore support). But > as both of us are trash in Rust (and every other applicable language > in this domain), we kind of dropped the project once we had sufficient > POC running on our laptops. > Someone who actually can code, could easily implement such program in > a weekend. I'm happy to share the trash we've done if someone intends > to check this box in open source world. May use it for inspiration, or > just straight up add polish and enough CLI to make it usable as-is. I went through a similar process. AF_PACKET is definitely what you need to use if you want to use user-space in Linux (don't know about MAC, only use Linux). I wrote a basic multi-threaded load generator and load sinker (Tx and Rx) in C using various Kernel methods (send(), sendmsg(), sendmmsg(), and PACKET_MMAP) with AF_PACKET to compare them all: https://github.com/jwbensley/EtherateMT The problem is that C is a great language to write high performance stuff, it's a shit language to create a JSON API in. I have two back to back lab servers at work with 10G links between them, low end 2.1Ghz Xeons, I get 1Mpps per core, 8 cores-1 for OS means I max out at 7Mpps :( I know that XDP is coming to Linux user space so we'll see where that goes, as it promises the magic performance levels we want. Also TPACKETv4 is coming for AF_PACKET in Linux which should also get us to that magic level of performance in user land (it is effectively Kernel bypass). I'll add this to EtherateMT when I get some time to check it's performance: https://lwn.net/Articles/737947/ So EtherateMT works OK as a proof of concept, but nothing more. It requires 100% CPU utilisation to send/receive at such high pps rates, there is no CPU time for stats collection or fancy rtt/latency/jitter etc. That can only be done (right now) with something like DPDK, because it we only need one or two cores for Tx/Rx and then we have free cores for stats collections/generations etc. I looked into MoonGen, it creates Lua bindings for DPDK which means you can rapidly develop DPDK based tools without knowing much about DPDK. It had some RFC2544 Lua scripts for DPDK and I started to re-write them as they were old and didn't work with the latest version of MoonGen: https://github.com/jwbensley/MoonGen-Scripts The throughput script works OK-ish (10Gbps on one core no problems): https://github.com/jwbensley/MoonGen-Scripts/blob/master/throughput.lua Luea would allow
Re: Proving Gig Speed
I don't think you understand the gravity of the in-home interference issue. Unfortunately, neither does the IEEE. It doesn't need to be in lock-step, but if a significant number of homes have issues getting over 100 megabit wirelessly, I'm not sure we need to be concerned about 10 gigabit to the home. I am well aware of the wireless world and Ubiquiti. I've been using Ubiquiti (among other brands) for over 10 years and have been a hardware beta tester for several of them. The 640 kb of RAM statements, computers in home statements, 56 kbps days statements... are all tangential at best. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Joe Greco" To: "Mike Hammett" Cc: nanog@nanog.org Sent: Tuesday, July 17, 2018 11:11:29 AM Subject: Re: Proving Gig Speed On Tue, Jul 17, 2018 at 10:47:45AM -0500, Mike Hammett wrote: > We already supply far, far greater than the actual consumer usage (versus > want or demand). > > Consumers are moving away from wired connections in the home for wireless > connections (for obvious mobility and ease of setup where there isn't > existing wired infrastructure). > > Consumers are moving away from power desktops and laptops to phones, tablets, > and purpose-built appliances. > > My in-laws have a Comcast service that's >100 megabit/s. The 2.4 and 5 GHz > noise floors are so high (-50 to -75 dB, depending on channel and location > within the house) that unless you're in the same room, you're not getting > more than 10 megabit/s on wireless. On a wire, Comcast delivers full data > rate. Speed tests from wire to wireless mirror the wireless to Internet > performance. > > If it can't be delivered within the home, delivering it to the home is > pointless. And yet if we had had those attitudes back in the days of 56kbps, ... Your argument is flawed because it implies that this is not an issue that can be addressed. Populating a house with more than a single crap-grade built-into-the-CPE radio is certainly possible, and tech people have been using gear such as Ubiquiti to do so for years now, but more recently mesh systems have become readily available as well and are even sold at Best Buy and other electronics stores. There is no need for ISP speeds to be in exact lock-step with wifi speeds. Advances in one will drive advances in the other. Eventually. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Proving Gig Speed
> On Jul 17, 2018, at 10:44 AM, Mark Tinka wrote: > > > > On 17/Jul/18 16:41, Mike Hammett wrote: > >> 10G to the home will be pointless as more and more people move away >> from Ethernet to WiFi where the noise floor for most installs prevents >> anyone from reaching 802.11n speeds, much less whatever alphabet soup >> comes later. > > Doesn't stop customers from buying it if it's cheap and available, which > doesn't stop them from proving they are getting 10Gbps as advertised. > > Mark. I suppose in reality it’s no different than any other utility. My home has 200 amp electrical service. Will I ever use 200 amps at one time? Highly highly unlikely. But if my electrical utility wanted to advertise “200 amp service in all homes we supply!” they sure could. Would an electrician be able to test it? I’m sure there is a way somehow. If me and everyone on my street tried to use 200 amps all at the same time, could the infrastructure handle it? Doubtful. But do I on occasion saturate my home fiber 300 mbit synchronous connection? Every now and then yes, but rarely. Although if I’m paying for 300 and not getting it, my ISP will be hearing from me. If my electrical utility told me “hey, you can upgrade to 500 amp service for no additional charge” would I do it? Sure, what the heck. If my water utility said “guess what? You can upgrade to a 2-inch water line at no additional charge!” would I do it? Probably yeah, why not? Would I ever use all that capacity on $random_utility at one time? Of course not. But nice to know it’s there if I ever need it. Andy Ringsmuth a...@newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397(402) 304-0083 cellular
Re: Proving Gig Speed
The problem cited is the last 100', not the last mile. For ISPs using 60 GHz for the last mile, a wire is ran from the outdoor antenna to the indoor router. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Mark Tinka" To: "Daniel Ankers" , "Mike Hammett" , "NANOG list" Sent: Tuesday, July 17, 2018 10:58:22 AM Subject: Re: Proving Gig Speed On 17/Jul/18 17:46, Daniel Ankers wrote: That's unless 802.11ad/.11ay gain in popularity. 60GHz offers lots of bandwidth and isn't particularly good at getting through brick walls, which might offer some relief to the noise floor problem. So if 60GHz can't get through brick walls, how does the home connect to the ISP PoP? Mark.
Re: Proving Gig Speed
60 GHz isn't particularly good at getting through a wet dream. I use it outdoors with highly directional antenna (42 dBi of gain) and it's only going to be useful in the home for same-room communication. The only chance it has to be more than that are high-count beam forming antennas to take advantage of very precise reflections. Dozens if not hundreds of elements for that directivity. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Daniel Ankers" To: "Mike Hammett" , "NANOG list" Sent: Tuesday, July 17, 2018 10:46:10 AM Subject: Re: Proving Gig Speed On 17 July 2018 at 15:41, Mike Hammett < na...@ics-il.net > wrote: 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. That's unless 802.11ad/.11ay gain in popularity. 60GHz offers lots of bandwidth and isn't particularly good at getting through brick walls, which might offer some relief to the noise floor problem. Dan
Re: Proving Gig Speed
On 17/Jul/18 17:46, Daniel Ankers wrote: > That's unless 802.11ad/.11ay gain in popularity. 60GHz offers lots of > bandwidth and isn't particularly good at getting through brick walls, which > might offer some relief to the noise floor problem. So if 60GHz can't get through brick walls, how does the home connect to the ISP PoP? Mark.
Re: Proving Gig Speed
Most ISPs I know build their own last mile. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Mark Tinka" To: "Mike Hammett" Cc: "North American Network Operators' Group" Sent: Tuesday, July 17, 2018 10:45:48 AM Subject: Re: Proving Gig Speed On 17/Jul/18 16:42, Mike Hammett wrote: Build your own last mile... Hmmh, don't know why everyone doesn't just do that. or order that 10% more? As Trump said, "All I can do is ask the question..." Mark.
Re: Proving Gig Speed
We already supply far, far greater than the actual consumer usage (versus want or demand). Consumers are moving away from wired connections in the home for wireless connections (for obvious mobility and ease of setup where there isn't existing wired infrastructure). Consumers are moving away from power desktops and laptops to phones, tablets, and purpose-built appliances. My in-laws have a Comcast service that's >100 megabit/s. The 2.4 and 5 GHz noise floors are so high (-50 to -75 dB, depending on channel and location within the house) that unless you're in the same room, you're not getting more than 10 megabit/s on wireless. On a wire, Comcast delivers full data rate. Speed tests from wire to wireless mirror the wireless to Internet performance. If it can't be delivered within the home, delivering it to the home is pointless. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Saku Ytti" To: "Mike Hammett" Cc: "Mark Tinka" , nanog@nanog.org Sent: Tuesday, July 17, 2018 10:38:52 AM Subject: Re: Proving Gig Speed On Tue, 17 Jul 2018 at 17:45, Mike Hammett wrote: > 10G to the home will be pointless as more and more people move away from > Ethernet to WiFi where the noise floor for most installs prevents anyone from > reaching 802.11n speeds, much less whatever alphabet soup comes later. I admire your confidence, when historically we've had poor success in these type of predictions. I seriously doubt we're now living in special time in history where we find the limit of consumer bandwidth demand, while I have no idea what would drive it or how it would be implemented, I'm betting against myself having all the information about future. -- ++ytti
Re: Proving Gig Speed
On 17/Jul/18 17:38, Saku Ytti wrote: > I admire your confidence, when historically we've had poor success in > these type of predictions. I seriously doubt we're now living in > special time in history where we find the limit of consumer bandwidth > demand, while I have no idea what would drive it or how it would be > implemented, I'm betting against myself having all the information > about future. +1. Mark.
Re: Proving Gig Speed
On 17 July 2018 at 15:41, Mike Hammett wrote: > 10G to the home will be pointless as more and more people move away from > Ethernet to WiFi where the noise floor for most installs prevents anyone > from reaching 802.11n speeds, much less whatever alphabet soup comes later. > > That's unless 802.11ad/.11ay gain in popularity. 60GHz offers lots of bandwidth and isn't particularly good at getting through brick walls, which might offer some relief to the noise floor problem. Dan
Re: Proving Gig Speed
On 17/Jul/18 16:42, Mike Hammett wrote: > Build your own last mile... Hmmh, don't know why everyone doesn't just do that. > or order that 10% more? As Trump said, "All I can do is ask the question..." Mark.
Re: Proving Gig Speed
On 17/Jul/18 16:41, Mike Hammett wrote: > 10G to the home will be pointless as more and more people move away > from Ethernet to WiFi where the noise floor for most installs prevents > anyone from reaching 802.11n speeds, much less whatever alphabet soup > comes later. Doesn't stop customers from buying it if it's cheap and available, which doesn't stop them from proving they are getting 10Gbps as advertised. Mark.
Re: Proving Gig Speed
On Tue, 17 Jul 2018 at 17:45, Mike Hammett wrote: > 10G to the home will be pointless as more and more people move away from > Ethernet to WiFi where the noise floor for most installs prevents anyone from > reaching 802.11n speeds, much less whatever alphabet soup comes later. I admire your confidence, when historically we've had poor success in these type of predictions. I seriously doubt we're now living in special time in history where we find the limit of consumer bandwidth demand, while I have no idea what would drive it or how it would be implemented, I'm betting against myself having all the information about future. -- ++ytti
Re: Proving Gig Speed
Unrelated. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Brant Ian Stevens" To: nanog@nanog.org Sent: Tuesday, July 17, 2018 9:47:35 AM Subject: Re: Proving Gig Speed "There is no reason for any individual to have a computer in his home." "640K ought to be enough for anybody." On 7/17/18 10:41 AM, Mike Hammett wrote: > 10G to the home will be pointless as more and more people move away from > Ethernet to WiFi where the noise floor for most installs prevents anyone from > reaching 802.11n speeds, much less whatever alphabet soup comes later. > > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > - Original Message - > > From: "Mark Tinka" > To: "K. Scott Helms" > Cc: "NANOG list" > Sent: Tuesday, July 17, 2018 7:11:35 AM > Subject: Re: Proving Gig Speed > > > > On 17/Jul/18 14:07, K. Scott Helms wrote: > >> That's absolutely true, but I don't see any real alternatives in some >> cases. I've actually built automated testing into some of the CPE >> we've deployed and that works pretty well for some models but other >> devices don't seem to be able to fill a ~500 mbps link. > So what are you going to do when 10Gbps FTTH into the home becomes the norm? > > Perhaps laptops and servers of the time won't even see this as a > rounding error :-\... > > Mark. >
Re: (perhaps off topic, but) Microwave Towers
Also worth mentioning that AT&T Canada originated with the Canadian Pacific Railway... CP Railway and Unitel --> AT&T Canada --> Allstream --> MTS-Allstream --> Zayo I have a GIS dataset with about 90% of the most important hilltop and mountaintop tower sites in WA, BC, OR and ID. There is a ton of stuff out there and operational. On Mon, Jul 16, 2018 at 9:01 AM, Mike Hammett wrote: > No idea where you were at, but lots of big companies have done microwave > and lots of new companies do microwave. > > https://en.wikipedia.org/wiki/MCI_Communications > > MCI was founded as Microwave Communications, Inc. on October 3, 1963 with > John D. Goeken being named the company's first president. The initial > business plan was for the company to build a series of microwave relay > stations between Chicago, Illinois and St. Louis, Missouri. The relay > stations would then be used to interface with limited-range two-way radios > used by truckers along U.S. Route 66 or by barges on the Illinois Waterway. > > > https://en.wikipedia.org/wiki/Sprint_Corporation > > Southern Pacific maintained an extensive microwave communications system > along its rights-of-way that the railroad used for internal communications. > > > AT&T had a bunch and I think a couple sites are still active: > http://long-lines.net/ > > Western Union had a microwave network as well. > > > > > Lots of companies build microwave for internal communications. Rail and > utility companies are big here. > > All of the cell companies do some microwave in their more rural areas. > > Lots of independent ISPs use microwave to build their entire network. > > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com > > - Original Message - > > From: "Miles Fidelman" > To: nanog@nanog.org > Sent: Saturday, July 14, 2018 9:54:25 AM > Subject: (perhaps off topic, but) Microwave Towers > > Hi Folks, > > I find myself driving down Route 66. On our way through Arizona, I was > surprised by what look like a lot of old-style microwave links. They > pretty much follow the East-West rail line - where I'd expect there's a > lot of fiber buried. > > Struck me as somewhat interesting. > > It also struck me that folks here might have some comments. > > Miles Fidelman > > -- > In theory, there is no difference between theory and practice. > In practice, there is. Yogi Berra > > >
Re: Proving Gig Speed
> On Jul 17, 2018, at 9:41 AM, Mike Hammett wrote: > > 10G to the home will be pointless as more and more people move away from > Ethernet to WiFi where the noise floor for most installs prevents anyone from > reaching 802.11n speeds, much less whatever alphabet soup comes later. > > > > > - > Mike Hammett > Intelligent Computing Solutions > http://www.ics-il.com > > Midwest-IX > http://www.midwest-ix.com Well, in a few years when we’re all watching 4D 32K Netflix on our 16-foot screens with 5 million DPI, it’ll make all the difference in the world, right? Tongue-in-cheek obviously. Andy Ringsmuth a...@newslink.com News Link – Manager Technology, Travel & Facilities 2201 Winthrop Rd., Lincoln, NE 68502-4158 (402) 475-6397(402) 304-0083 cellular
Re: Proving Gig Speed
"There is no reason for any individual to have a computer in his home." "640K ought to be enough for anybody." On 7/17/18 10:41 AM, Mike Hammett wrote: 10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Mark Tinka" To: "K. Scott Helms" Cc: "NANOG list" Sent: Tuesday, July 17, 2018 7:11:35 AM Subject: Re: Proving Gig Speed On 17/Jul/18 14:07, K. Scott Helms wrote: That's absolutely true, but I don't see any real alternatives in some cases. I've actually built automated testing into some of the CPE we've deployed and that works pretty well for some models but other devices don't seem to be able to fill a ~500 mbps link. So what are you going to do when 10Gbps FTTH into the home becomes the norm? Perhaps laptops and servers of the time won't even see this as a rounding error :-\... Mark.
Re: Proving Gig Speed
Build your own last mile or order that 10% more? - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Mark Tinka" To: "Matt Hoppes" Cc: "North American Network Operators' Group" Sent: Tuesday, July 17, 2018 7:12:39 AM Subject: Re: Proving Gig Speed On 17/Jul/18 14:07, Matt Hoppes wrote: > Which is why we over provision by 10%. After a bunch of customers, it starts to add ($$) up. And what do you do if you don't own the last mile, and your Layer 2 service provider sticks to the letter? Mark.
Re: Proving Gig Speed
10G to the home will be pointless as more and more people move away from Ethernet to WiFi where the noise floor for most installs prevents anyone from reaching 802.11n speeds, much less whatever alphabet soup comes later. - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "Mark Tinka" To: "K. Scott Helms" Cc: "NANOG list" Sent: Tuesday, July 17, 2018 7:11:35 AM Subject: Re: Proving Gig Speed On 17/Jul/18 14:07, K. Scott Helms wrote: > > That's absolutely true, but I don't see any real alternatives in some > cases. I've actually built automated testing into some of the CPE > we've deployed and that works pretty well for some models but other > devices don't seem to be able to fill a ~500 mbps link. So what are you going to do when 10Gbps FTTH into the home becomes the norm? Perhaps laptops and servers of the time won't even see this as a rounding error :-\... Mark.
Re: Proving Gig Speed
It tells you how good your peering is. ;-) - Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com - Original Message - From: "James Bensley" To: "North American Network Operators' Group" Sent: Tuesday, July 17, 2018 2:49:58 AM Subject: Re: Proving Gig Speed On 16 July 2018 at 18:58, Chris Gross wrote: Hi Chris, > I'm curious what people here have found as a good standard for providing > solid speedtest results to customers. All our techs have Dell laptops of > various models, but we always hit 100% CPU when doing a Ookla speedtest for a > server we have on site. So then if you have a customer paying for 600M or > 1000M symmetric, they get mad and demand you prove it's full speed. At that > point we have to roll out different people with JDSU's to test and prove it's > functional where a Ookla result would substitute fine if we didn't have > crummy laptops possibly. Even though from what I can see on some google > results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of > course that never actually uses more than 50M sustained paying for a > residential connection, so running a circuit test on each turn up is uncalled > for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop > that can actually do symmetric gig, a rugged small inexpensive device we can > roll with instead to prove, or any other weird solution involving ritual > sacrifice that isn't too offensive to the eyes? I would say, don't use a browser based speed test - how fast is your browser? Answer: It can vary wildly! Also there are SO many variables when testing TCP you MUST test using UDP if you want to just test the network path. Every OS will behave differently with TCP, also with UDP but the variance is a lot lower. Also I recommend you test to a server on you network near to your peering & transit edge. This way users can test up to the point where you would have over the "The Internet" and have no further control. Testing to a server off-net (like off-net Ookla tells me nothing in my opinion). Virtually any modern day laptop with a 1G NIC will saturate a 1G link using UDP traffic in iPerf with ease. I crummy i3 netbook with 1G NIC can do it on one core/thread. We have several iPerf servers dotted around the network and our engineers can test to those at any time and it works well for us. Cheers, James.
Re: (perhaps off topic, but) Microwave Towers
As Mike points out, there are a lot of us doing fixed-wireless / microwave now. We have our own industry. See: http://wispa.org/ -- Keefe John CEO Ethoplex Direct: 262.345.5200 Ethoplex Business Internet http://www.ethoplex.com/ Signal Residential Internet http://www.signalisp.com/ https://www.linkedin.com/in/keefejohn/ On Mon, Jul 16, 2018 at 11:56 AM, Michael Crapse wrote: > Microwave radios are the things that break the mold of the incorrect > assumption that just because it doesn't make sense to put up more wires to > a house you can't have more than one provider. Considering that we've > deployed a few wireless systems with less latency, jitter, and downtime > than the local incumbent DOCSIS provider. In fact the greatest benefit to > wireless microwave systems is the fact that they do not need to follow the > right of way. Where wireline and fiberoptics must go through more hubs to > get from side of town to the other, wireless is a point to point system > with latencies+jitter sub 400 microseconds. > > No matter how great the incumbent fiber/dsl/coaxial network becomes, there > will always be new microwave links going up. For their biggest strengths > there's no replacement. > Now, their weaknesses may be many, and may be apparent, their stengths just > outweigh those. > > On 16 July 2018 at 10:01, Mike Hammett wrote: > > > No idea where you were at, but lots of big companies have done microwave > > and lots of new companies do microwave. > > > > https://en.wikipedia.org/wiki/MCI_Communications > > > > MCI was founded as Microwave Communications, Inc. on October 3, 1963 with > > John D. Goeken being named the company's first president. The initial > > business plan was for the company to build a series of microwave relay > > stations between Chicago, Illinois and St. Louis, Missouri. The relay > > stations would then be used to interface with limited-range two-way > radios > > used by truckers along U.S. Route 66 or by barges on the Illinois > Waterway. > > > > > > https://en.wikipedia.org/wiki/Sprint_Corporation > > > > Southern Pacific maintained an extensive microwave communications system > > along its rights-of-way that the railroad used for internal > communications. > > > > > > AT&T had a bunch and I think a couple sites are still active: > > http://long-lines.net/ > > > > Western Union had a microwave network as well. > > > > > > > > > > Lots of companies build microwave for internal communications. Rail and > > utility companies are big here. > > > > All of the cell companies do some microwave in their more rural areas. > > > > Lots of independent ISPs use microwave to build their entire network. > > > > > > > > > > - > > Mike Hammett > > Intelligent Computing Solutions > > http://www.ics-il.com > > > > Midwest-IX > > http://www.midwest-ix.com > > > > - Original Message - > > > > From: "Miles Fidelman" > > To: nanog@nanog.org > > Sent: Saturday, July 14, 2018 9:54:25 AM > > Subject: (perhaps off topic, but) Microwave Towers > > > > Hi Folks, > > > > I find myself driving down Route 66. On our way through Arizona, I was > > surprised by what look like a lot of old-style microwave links. They > > pretty much follow the East-West rail line - where I'd expect there's a > > lot of fiber buried. > > > > Struck me as somewhat interesting. > > > > It also struck me that folks here might have some comments. > > > > Miles Fidelman > > > > -- > > In theory, there is no difference between theory and practice. > > In practice, there is. Yogi Berra > > > > > > > -- Keefe John CEO Ethoplex Direct: 262.345.5200 Ethoplex Business Internet http://www.ethoplex.com/ Signal Residential Internet http://www.signalisp.com/ https://www.linkedin.com/in/keefejohn/
Re: deploying RPKI based Origin Validation
Hi Job, All, It is definitely great to see progress on the deployment side! I realize that there may be some gaps in the network operator toolchain, and this may be something i'd like to contribute to. For network operators to better understand the impact of BGP hijacks in terms of revenue or volumes of traffic that went missing, it makes perfect sense if network monitoring tools are aware of which BGP announcements are invalid or not. I will look into adding support for the RTR protocol (RFC 6810, RFC 8210) to pmacct ( https://github.com/pmacct/pmacct , http://pmacct.net/ ) and expose the validation state through an extra field (when collecting routing tables) and primitive (when accounting traffic and correlating it with BGP data). Updating the telemetry tools to be fully aware of RPKI validation states should come in handy! Paolo On Thu, Jul 12, 2018 at 05:50:29PM +, Job Snijders wrote: > Hi all, > > I wanted to share with you that a ton of activity is taking place in the > Dutch networker community to deploy RPKI based BGP Origin Validation. > The mantra is "invalid == reject" on all EBGP sessions. > > What's of note here is that we're now seeing the first commercial ISPs > doing Origin Validation. This is a significant step forward compared to > what we observed so far (it seemed OV was mostly limited to academic > institutions & toy networks). But six months ago Amsio > (https://www.amsio.com/en/) > made the jump, and today Fusix deployed (https://fusix.nl/deploying-rpki/). > > We've also seen an uptake of Origin Validation at Internet Exchange > route servers: AMS-IX and FranceIX have already deployed. I've read that > RPKI OV is under consideration at a number of other exchanges. > > Other cool news is that Cloudflare launched a Certificate Transparency > initiative to help keep everyone honest. Announcement at: > https://twitter.com/grittygrease/status/1017224762542587907 > Certificate Transparency is a fascinating tool, really a necessity to > build confidence in any PKI systems. > > Anyone here working to deploy RPKI based Origin Validation in their > network and reject invalid announcements? Anything of note to share? > > Kind regards, > > Job
Re: Proving Gig Speed
I use my Lenovo Thinkpad with or any "decent" client machine and run iperf to prove the connectivity. Of course, client switch quality or firewall can be an issue. On 07/16/2018 01:58 PM, Chris Gross wrote: I'm curious what people here have found as a good standard for providing solid speedtest results to customers. All our techs have Dell laptops of various models, but we always hit 100% CPU when doing a Ookla speedtest for a server we have on site. So then if you have a customer paying for 600M or 1000M symmetric, they get mad and demand you prove it's full speed. At that point we have to roll out different people with JDSU's to test and prove it's functional where a Ookla result would substitute fine if we didn't have crummy laptops possibly. Even though from what I can see on some google results, we exceed the standards several providers call for. Most of these complaints come from the typical "power" internet user of course that never actually uses more than 50M sustained paying for a residential connection, so running a circuit test on each turn up is uncalled for. Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop that can actually do symmetric gig, a rugged small inexpensive device we can roll with instead to prove, or any other weird solution involving ritual sacrifice that isn't too offensive to the eyes? -- Morgan A. Miskell CaroNet Data Centers 704-643-8330 x206 The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited.
Re: Proving Gig Speed
+1 to Jared. I’ve seen people not account for this when sizing CoS as well on Juniper. -Eddie > On Jul 16, 2018, at 11:08 AM, Jared Mauch wrote: > >> On Mon, Jul 16, 2018 at 01:02:28PM -0500, Dan White wrote: >> We've found that running windows in safe mode produces better results with >> Ookla. And MACs usually do better as well. We've gotten >900mb/s with those >> two approaches. > >I've seen engineers even forget to account for differing behaviors > of vendors, eg: Juniper doesn't display the layer-2 header counters > >This means a 920Mb/s link may actually be 100% once you add back in > ethernet framing. Remind folks that they are seeing the TCP/UDP throughput > and there is ethernet + IP headers involved. > >- Jared >
Re: Proving Gig Speed
On 17/Jul/18 14:18, Matt Hoppes wrote: > Get a better middle mile. That’s why we use Comcast for much of our middle > mile. Comcast don't operate in Africa. Some countries don't have (m)any options. Mark.
Re: Bogon prefix c0f:f618::/32 announced via Cogent
On Mon, Jul 16, 2018 at 05:20:12PM +0200, Stephane Bortzmeyer wrote: > On Sat, Jul 14, 2018 at 08:18:25AM +0800, > Siyuan Miao wrote > a message of 27 lines which said: > > > c0f:f618::/32 originated from AS327814 is announcing via Cogent for several > > weeks. > > Apparently withdrawn 2018-07-14 around 16:00:00 UTC. Your mail to NANOG was > effective :-) I see it right now...
Re: Bogon prefix c0f:f618::/32 announced via Cogent
Looks like a typo of 2c0f:f618: A V DestinationP Prf Metric 1 Metric 2 Next hopAS path* ? 2c0f:f618::/32 B 170150 69040 174 327814 ? unverified >fe80::f5c0:800:2 On Sat, Jul 14, 2018 at 08:18:25AM +0800, Siyuan Miao wrote: > Hi, > > c0f:f618::/32 originated from AS327814 is announcing via Cogent for several > weeks. > > I've tried to contact Cogent and AS327814 but didn't receive any reply. > > Tue Jul 10 17:52:48.602 UTC > BGP routing table entry for c0f:f618::/32 > Versions: > Process bRIB/RIB SendTblVer > Speaker 7640326976403269 > Local Label: 61339 > Last Modified: Jul 3 13:31:40.815 for 1w0d > Paths: (1 available, best #1) > Advertised to peers (in unique update groups): > 38.5.0.99 > Path #1: Received by speaker 0 > Advertised to peers (in unique update groups): > 38.5.0.99 > 327814 > 2001:550:0:1000::261c:166 (metric 119060) from > 2001:550:0:1000::261c:153 (38.28.1.102) > Origin incomplete, localpref 130, valid, internal, best, group-best > Received Path ID 0, Local Path ID 0, version 76403269 > Community: 174:11100 174:20999 174:21101 174:22012 > Originator: 38.28.1.102, Cluster list: 38.28.1.83, 38.28.1.67, > 38.28.1.92
Re: Proving Gig Speed
Get a better middle mile. That’s why we use Comcast for much of our middle mile. > On Jul 17, 2018, at 08:12, Mark Tinka wrote: > > > > On 17/Jul/18 14:07, Matt Hoppes wrote: > >> Which is why we over provision by 10%. > > After a bunch of customers, it starts to add ($$) up. > > And what do you do if you don't own the last mile, and your Layer 2 service > provider sticks to the letter? > > Mark.
Re: Proving Gig Speed
On 17/Jul/18 14:07, Matt Hoppes wrote: > Which is why we over provision by 10%. After a bunch of customers, it starts to add ($$) up. And what do you do if you don't own the last mile, and your Layer 2 service provider sticks to the letter? Mark.
Re: Proving Gig Speed
On 17/Jul/18 14:07, K. Scott Helms wrote: > > That's absolutely true, but I don't see any real alternatives in some > cases. I've actually built automated testing into some of the CPE > we've deployed and that works pretty well for some models but other > devices don't seem to be able to fill a ~500 mbps link. So what are you going to do when 10Gbps FTTH into the home becomes the norm? Perhaps laptops and servers of the time won't even see this as a rounding error :-\... Mark.
Re: Proving Gig Speed
On 17/Jul/18 09:49, James Bensley wrote: > > Also I recommend you test to a server on you network near to your > peering & transit edge. This way users can test up to the point where > you would have over the "The Internet" and have no further control. > Testing to a server off-net (like off-net Ookla tells me nothing in my > opinion). In our market, users don't care about the server that is 1ms away. They want to test the one which is 170ms, because that is where the gaming network sits. And heaven forbid that 170ms server does not return their full 1Gbps subscription report, never mind the state of its affairs, or who's running (if anyone even remembered it's there). Mark.
Re: Proving Gig Speed
Which is why we over provision by 10%. > On Jul 17, 2018, at 07:51, Mark Tinka wrote: > > > >> On 16/Jul/18 20:08, Jared Mauch wrote: >> >>This means a 920Mb/s link may actually be 100% once you add back in >> ethernet framing. Remind folks that they are seeing the TCP/UDP throughput >> and there is ethernet + IP headers involved. > > But you sold me 1Gbps. Stop stiffing me my 80Mbps :-)... > > Mark.
Re: Proving Gig Speed
That's absolutely true, but I don't see any real alternatives in some cases. I've actually built automated testing into some of the CPE we've deployed and that works pretty well for some models but other devices don't seem to be able to fill a ~500 mbps link. On Tue, Jul 17, 2018 at 8:03 AM Mark Tinka wrote: > > > On 16/Jul/18 22:31, Carlos Alcantar wrote: > > > It's a complete rabbit hole... > > Couldn't have said it better myself! > > Mark. >
Re: Proving Gig Speed
On 16/Jul/18 23:19, Michael Thomas wrote: > > > As we get more and more stuff on our home networks, the probability > for crappy software, infected devices, piggy updates, etc multiplies. > I'm sure this isn't news to $CORPRO network managers, but at home we > quite literally have nothing to help us figure out and remedy these > kinds of problems. Or if it turns out to *not* be our problem, that we > have some reassurance when we decide to call the support desk and be > put through IVR maze hell only to find out it was a local problem > after all. Well, at least you had the foresight not to "speed test" your way you into keeping your popcorn fresh :-). Mark.
Re: Proving Gig Speed
On 16/Jul/18 22:34, Jon Meek wrote: > My practice is to use iperf with packet capture on both sides. The packet > capture can then be analyzed for accurate per-second, or less, throughput, > re-transmit rates, etc. This was implemented in a corporate network in > several ways including dedicated servers (that also did other monitoring), > and bootable CDs or USB sticks that a user in a small office could run on a > standard desktop. Many interesting issues were discovered with this > technique, and a fair number of perceived issues were debunked. If you are doing this for yourself, as a network engineer, this is great. But simple Joe at home doesn't care about all this fancy analysis. Does he get a pretty picture saying "Yay", or "Nay", that's all? Mark.
Re: Proving Gig Speed
On 16/Jul/18 22:31, Carlos Alcantar wrote: > It's a complete rabbit hole... Couldn't have said it better myself! Mark.
Re: Proving Gig Speed
On 16/Jul/18 20:17, Matt Erculiani wrote: > We use Iperf3 for customers that complain about throughput, it's > relatively low overhead compared to the Ookla HTML5 client. Same > scenario as you, we have the tech hook up their laptop to the > customer's drop and perform testing. I suspect your antivirus may be > attempting to perform real-time inspection on the http(s) traffic, > which would crush the little laptop CPU for sure. But iPerf doesn't paint pretty pictures at the end of the test that I can brag to my friends with :-)... Mark.
Re: Proving Gig Speed
On 16/Jul/18 20:08, Jared Mauch wrote: > This means a 920Mb/s link may actually be 100% once you add back in > ethernet framing. Remind folks that they are seeing the TCP/UDP throughput > and there is ethernet + IP headers involved. But you sold me 1Gbps. Stop stiffing me my 80Mbps :-)... Mark.
Re: Proving Gig Speed
On 16/Jul/18 19:58, Chris Gross wrote: > I'm curious what people here have found as a good standard for providing > solid speedtest results to customers. All our techs have Dell laptops of > various models, but we always hit 100% CPU when doing a Ookla speedtest for a > server we have on site. So then if you have a customer paying for 600M or > 1000M symmetric, they get mad and demand you prove it's full speed. At that > point we have to roll out different people with JDSU's to test and prove it's > functional where a Ookla result would substitute fine if we didn't have > crummy laptops possibly. Even though from what I can see on some google > results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of > course that never actually uses more than 50M sustained paying for a > residential connection, so running a circuit test on each turn up is uncalled > for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop > that can actually do symmetric gig, a rugged small inexpensive device we can > roll with instead to prove, or any other weird solution involving ritual > sacrifice that isn't too offensive to the eyes? (Ookla) speed tests, in general, are a fundamental problem we grapple with in only one of our markets, where previous ISP trust was eroded by the incumbent. So we are all paying the price for that 20 years on, i.e., the solution to every network problem is a speed test. If a Skype call drops, that's a speed test. If an e-mail attachment doesn't work properly, that's a speed tests. Wi-fi signal is bad, that's a speed test. If Office 365 self-destructs, that's a speed test. If 8.8.8.8 goes coo-koo, that's a speed test. You get the idea... I always ask speed test proponents - "How do you speed test a 100Gbps Internet service delivery :-\?" Server-side limitations notwithstanding, as you rightly point out, the client machine is also a potential point of contention (all pun intended). We recently dealt with a customer that had our NOC running around for 2 months about speed test results, only to realize that the customer was using a USB-to-Ethernet converter for his laptop to run the tests the whole time, which topped out at ±7Mbps, on their 100Mbps service. With a proper laptop that had an on-board Ethernet port being truck-rolled with an engineer to the site showing the difference, the case is now closed. But can you imagine the amount of noise that had been generated over the past 8 weeks? Find me a hole where the floor is pasted with "speed tests go here" so deep that even I can't see it, and I will throw the whole concept so far down it won't stand the chance of ever being converted to oil. But to answer your questions - for some customers, we insist on JDSU testing for large capacities, but only if it's worth the effort. Mark.
Re: deploying RPKI based Origin Validation
On 16/Jul/18 17:26, Job Snijders wrote: > I calculated this here few days ago > http://instituut.net/~job/rpki-report-2018.07.12.txt > > Markus Weber from KPN is generating a daily report here and drew similar > conclusions: https://as286.net/data/ana-invalids.txt Markus scrapes all > routes from the AS 286 PEs and marks the routes for which no valid or > unknown alternative exists as "altpfx=NONE". Thanks. Protein. So the numbers are not that far off from when I last checked this back in 2016, i.e., less than 1% of the total IPv4 routing table. Do you have numbers for IPv6, out of interest? > Or delete the incorrect RPKI ROA. Either way is fine. That would work, but the risk with that then is trying to get those networks back into RPKI would be more difficult, and if they do, chances are that the folk that were pushing it would have since left the company, making our education efforts a lot more difficult. So I'd be for pushing these folk to ROA the more-specifics, which is just a click of a button in their RIR's system. > Perhaps the RIRs should start an outreach program to proactively inform > the owners of those 2,200 invalid route announcements to get them to > either fix... I would be in support of this, and would certainly work very closely with AFRINIC to fix our side of things. Happy to also do a co-preso paper with you during EPF in Athens for the RIPE side of things. If you'll be in Vancouver, we can do the same for the ARIN side. I'm at MyNOG next week, and can speak to the folk from APNIC that will be showing up about this as well. That leaves LACNIC. Mark.
Carriage Burst Speeds [was Re: Proving Gig Speed]
On 17/07/2018 5:49 pm, James Bensley wrote: Also there are SO many variables when testing TCP you MUST test using UDP if you want to just test the network path. Every OS will behave differently with TCP, also with UDP but the variance is a lot lower. One of the issues I have repeatedly run into is an incorrect burst size set on shaped carriage circuits. In the specific case I have in mind now, I don't recall what the exact figures were - but the carrier side configuration was set by the carrier to be something like a 64k burst on a 20M L3 MPLS circuit. End to end speed testing results both with browsers and with iperf depended enormously on if the test was done with TCP or UDP. Consequently the end customer was unable to get more than 2-3MBit/sec of single stream TCP traffic through the link. The carrier insisted that because we could still get 19+ MBit/sec of UDP then there was no issue. This was the same for all operating systems. The end customer certainly didn't feel that they were getting the 20Mbit circuit they were sold. The carrier view was that as we were able to get 20 TCP streams running concurrently and max out the link that they were providing the service as ordered. After many months of testing and negotiating we were able to get the shaper burst increased temporarily, and the issue completely went away. The customer was able to get over 18MBit/sec of continuous TCP throughput on a single stream. I was told that despite this finding and admission that the burst was indeed way too small, the carrier was going to continue to provision circuits with almost no burst, because this was their "standard configuration". The common belief seemed to be that a burst was a free upgrade for the customer. I was of the alternate view that this parameter was required to be set correctly for TCP to function properly to get their quoted CIR. I'd be very interested in other's thoughts with regards to testing of this. It seems to me that measuring performance with UDP only means that this very critical real-world aspect of a circuit (burst size on a shaper) is not tested, and this seems to be a very common misconfiguration. In my case...seen across multiple carriers over many years and many dozens of hours spent on "faults" related to it. [NB: I've always used the rule of thumb that the L3 burst size should be about 1/8th the Contracted Line Rate, but there seems to be no consensus whatsoever about that...certainly no agreement whatsoever within the carrier world] Reuben
Re: Proving Gig Speed
On Tue, 17 Jul 2018 at 10:53, James Bensley wrote: > Virtually any modern day laptop with a 1G NIC will saturate a 1G link > using UDP traffic in iPerf with ease. I crummy i3 netbook with 1G NIC > can do it on one core/thread. I guess if you use large packets this might be true. But personally, if I'm testing network, I'm interested in latency, jitter, packet, bps _AND_ pps goals as well, not just bps goal. And I've never seen clean 1Gbps on iperf with small packets. It just cannot be done, even if iPerf was written half decently and it used recvmmsg, it still wouldn't be anywhere near. Clean 1Gbps with small packets in user space is actually very much doable today, just you can't use UDP socket, you must use AF_PACKET on Linux or BPF on OSX and you can write portable 1Gbps UDP sender/receiver. I'm very surprised we don't have iperf like program for netengs which does this and reports latency, jitter, packet loss with binary search for highest lossless pps/bps rates. I started to write one with Anton Aksola in Rust (using libpnet[0]), and implemented quite flexible protocol (server/client, client can ask server exactly what kind of packet to construct/expect, what rate to send/receive over JSON based protocol), so you could also use it to ask it to DDoS your routers control-plane in lab etc. And actually got it working, OSX+Linux ~wirarate (still needs higher end laptop to do 1.5Mpps on single core and we didn't implement multicore support). But as both of us are trash in Rust (and every other applicable language in this domain), we kind of dropped the project once we had sufficient POC running on our laptops. Someone who actually can code, could easily implement such program in a weekend. I'm happy to share the trash we've done if someone intends to check this box in open source world. May use it for inspiration, or just straight up add polish and enough CLI to make it usable as-is. I think very important quality is multiplatform with static binaries. Because important use case is, that you can ask modestly informed customer to copy paste one line to donwload server and copy paste another line to have it running. If use case is that both ends have arbitrary clued people, then there are plenty of good solutions, like Cisco's trex[1]. But what I need is iPerf-like program, which actually a) performs and b) reports the correct things. [0] https://github.com/libpnet/libpnet [1] https://trex-tgn.cisco.com/ -- ++ytti
Re: Proving Gig Speed
On 16 July 2018 at 18:58, Chris Gross wrote: Hi Chris, > I'm curious what people here have found as a good standard for providing > solid speedtest results to customers. All our techs have Dell laptops of > various models, but we always hit 100% CPU when doing a Ookla speedtest for a > server we have on site. So then if you have a customer paying for 600M or > 1000M symmetric, they get mad and demand you prove it's full speed. At that > point we have to roll out different people with JDSU's to test and prove it's > functional where a Ookla result would substitute fine if we didn't have > crummy laptops possibly. Even though from what I can see on some google > results, we exceed the standards several providers call for. > > Most of these complaints come from the typical "power" internet user of > course that never actually uses more than 50M sustained paying for a > residential connection, so running a circuit test on each turn up is uncalled > for. > > Anyone have any suggestions of the requirements (CPU/RAM/etc) for a laptop > that can actually do symmetric gig, a rugged small inexpensive device we can > roll with instead to prove, or any other weird solution involving ritual > sacrifice that isn't too offensive to the eyes? I would say, don't use a browser based speed test - how fast is your browser? Answer: It can vary wildly! Also there are SO many variables when testing TCP you MUST test using UDP if you want to just test the network path. Every OS will behave differently with TCP, also with UDP but the variance is a lot lower. Also I recommend you test to a server on you network near to your peering & transit edge. This way users can test up to the point where you would have over the "The Internet" and have no further control. Testing to a server off-net (like off-net Ookla tells me nothing in my opinion). Virtually any modern day laptop with a 1G NIC will saturate a 1G link using UDP traffic in iPerf with ease. I crummy i3 netbook with 1G NIC can do it on one core/thread. We have several iPerf servers dotted around the network and our engineers can test to those at any time and it works well for us. Cheers, James.
