Re: IP Fragmentation - Not reliable over the Internet?
On (2013-08-27 00:01 +), Christopher Palmer wrote: If anyone has any data or anecdotes, please feel free to send an off-list email or whatever. [y...@ytti.fi ~]% ssh ring ring-all -t90 ping -s 1473 -c2 -w3 ip.fi|pastebinit http://p.ip.fi/KA7N [ytti@sci ~]% curl -s http://p.ip.fi/KA7N|grep transmitted|wc -l 224 [ytti@sci ~]% curl -s http://p.ip.fi/KA7N|grep 0 received|wc -l 10 UUOC wc, but that's how I roll. 224 vantage points, 10 failed. -- ++ytti
Re: IP Fragmentation - Not reliable over the Internet?
On Aug 26, 2013, at 22:02 , valdis.kletni...@vt.edu wrote: On Tue, 27 Aug 2013 00:01:45 -, Christopher Palmer said: What is the probability that a random path between two Internet hosts will traverse a middlebox that drops or otherwise barfs on fragmented IPv4 packets? THe fact you're posting indicates that you already know the practical answer: Often enough that you need to take defensive measures. But there's really several separate questions here: 1) What is the probability that a given path ends up fragging a packet because it isn't MTU 1500 end-to-end? 2) What is the probability that a frag needed is detected by a router that then botches it? 2a) What is the probability that the router does it right but the source node shoots itself in the foot by requesting PMTUD, but then blocks inbound ICMP for security reasons? 3) What is the probability that one router correctly frags a packet, but a subsequent box (most likely a firewall or target host) botches the re-assembly or other handling? 4) When confronted with the fact that there's a very high correlation between the level of technical clue that results in procuring and deploying a broken device, and the level of technical clue clue available to resolve the problem when you try to contact them, what's the appropriate beverage? That's a lot of questions he didn't ask. As I read it, the question he asked is: If I send a packet out as a legitimate series of fragments, what is the chance that they will get dropped somewhere in the middle of the path between the emitting host and the receiving host? To my thinking, the answer to that question is basically pretty close to 0 and if that changes in the core, very bad things will happen. Owen
Re: IP Fragmentation - Not reliable over the Internet?
On 27/08/2013 08:55, Saku Ytti wrote: On (2013-08-27 00:01 +), Christopher Palmer wrote: If anyone has any data or anecdotes, please feel free to send an off-list email or whatever. [y...@ytti.fi ~]% ssh ring ring-all -t90 ping -s 1473 -c2 -w3 ip.fi|pastebinit http://p.ip.fi/KA7N [ytti@sci ~]% curl -s http://p.ip.fi/KA7N|grep transmitted|wc -l 224 [ytti@sci ~]% curl -s http://p.ip.fi/KA7N|grep 0 received|wc -l 10 UUOC wc, but that's how I roll. 224 vantage points, 10 failed. Same tests from RIPE Atlas pings towards nl-ams-as.anchors.atlas.ripe.net today: 48 byte ping:42 out of 3406 vantage points fail (1.0%) 1473 byte ping: 180 out of 3540 vantage points fail (5.1%) Of the 180 vantage points that failed for the 1473 byte ping, 142 were successful in receiving at least 1 reply for the 48 byte ping. Measurement IDs in RIPE Atlas are 1019675 and 1019676. Emile Aben RIPE NCC
Re: IP Fragmentation - Not reliable over the Internet?
Christopher Palmer christopher.pal...@microsoft.com wrote: What is the probability that a random path between two Internet hosts will traverse a middlebox that drops or otherwise barfs on fragmented IPv4 packets? This question is important for large EDNS packets so you'll find some recent practical investigations from the perspective of people interested in DNSSEC. For instance, a couple of presentations from Roland van Rijswijk: https://ripe64.ripe.net/presentations/91-20120418_-_RIPE64_-_Ljubljana_-_DNSSEC_-_UDP_issues.pdf http://toronto45.icann.org/meetings/toronto2012/presentation-dnssec-fragmentation-17oct12-en.pdf Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first.
Re: IP Fragmentation - Not reliable over the Internet?
Christopher Palmer christopher.pal...@microsoft.com wrote: What is the probability that a random path between two Internet hosts will traverse a middlebox that drops or otherwise barfs on fragmented IPv4 packets? This question is important for large EDNS packets so you'll find some recent practical investigations from the perspective of people interested in DNSSEC. For instance, a couple of presentations from Roland van Rijswijk: https://ripe64.ripe.net/presentations/91-20120418_-_RIPE64_-_Ljubljana_-_DNSSEC_-_UDP_issues.pdf http://toronto45.icann.org/meetings/toronto2012/presentation-dnssec-fragmentation-17oct12-en.pdf Related to this and maybe be of interest is the following blog post https://www.nlnetlabs.nl/blog/2013/06/04/pmtud4dns/. jaap
Re: IP Fragmentation - Not reliable over the Internet?
On (2013-08-27 10:45 +0200), Emile Aben wrote: 224 vantage points, 10 failed. 48 byte ping:42 out of 3406 vantage points fail (1.0%) 1473 byte ping: 180 out of 3540 vantage points fail (5.1%) Nice, it's starting to almost sound like data rather than anecdote, both tests implicate 45% having fragmentation issues. Much larger number than I intuitively had in mind. -- ++ytti
Re: CableWiFi SSID in Washington DC?
Drew, Optimum's Hotspot locator will show partner hotspots that they have access through. Check out their wifi locator page below to see you will have wifi coverage. http://m.optimumwifi.com/results.php?s=quickt=washington+dclocal=1lat=38 .9072309lon=-77.0364641#pageTop They may also have an iPhone/Android app for locating optimum hotspots similar to Comcast's appsŠ Android version = https://play.google.com/store/apps/details?id=com.comcast.hsf iPhone version = https://itunes.apple.com/us/app/xfinity-wifi/id549643634?mt=8 Thanks! -chae On 8/25/13 6:18 PM, Drew Linsalata drew.linsal...@gmail.com wrote: I know, completely non-operational and off topic, but have any of you folks in the DC area seen the CableWiFi SSID around town? Traveling next week and I can't get confirmation nor denial that my Optimum Online account will get me wifi access down there.
TCP Performance
Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: CogentOrlando Border Router (Mikrotik)HP Procurve Switch Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: CogentOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router (Mikrotik)HP Procurve SwitchServer Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando ServerHP Procurve SwitchOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router(Mikrotik)HP Procurve SwitchServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root@ded01 ~]# iperf -c 208.90.219.18Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that, nothing really stands out to me as to why these transfers are so much slower. Intra-network iperf testing shows full throughput the whole way with single connection. As well as UDP testing. One thing to note is the Iperf testing has far less TCP re-transmit/dup acks then any of the HTTP testing, Crossing the same Microwave Links and routers. http://cdn.141networks.com/files/captures.zip I appreciate any insight anyone might have. Thanks! Nick Olsen Network Operations (855) FLSPEED x106
Re: ATT.net postmaster contact
I've had good luck emailing them at abuse_...@abuse-att.net. Takes a couple days to hear back from them, but they do generally reply. On 08/26/2013 01:21 PM, Drew Weaver wrote: Howdy, Does anyone know of a good/working ATT.net postmaster contact? We have been trying for several weeks to get an IP that has never been used before removed from the ATT.net blacklist and we aren't getting replies through the forms on their site. Thanks, -Drew
Re: IP Fragmentation - Not reliable over the Internet?
On Aug 27, 2013, at 6:24 AM, Saku Ytti s...@ytti.fi wrote: On (2013-08-27 10:45 +0200), Emile Aben wrote: 224 vantage points, 10 failed. 48 byte ping:42 out of 3406 vantage points fail (1.0%) 1473 byte ping: 180 out of 3540 vantage points fail (5.1%) Nice, it's starting to almost sound like data rather than anecdote, both tests implicate 45% having fragmentation issues. Much larger number than I intuitively had in mind. I'm pretty sure the failure rate is higher, and here's why. The #1 cause of fragments being dropped is firewalls. Too many admins configuring a firewall do not understand fragments or how to properly put them in the rules. Where do firewalls exist? Typically protecting things with public IP space, that is (some) corporate networks and banks of content servers in data centers. This also includes on-box firewalls for Internet servers, ipfw or iptables on the server is just as likely to be part of the problem. Now, where are RIPE probes? Most RIPE probes are probably either with somewhat clueful ISP operators, or at Internet Clueful engineer's personal connectivity (home, or perhaps a box in a colo). RIPE probes have already significantly self-selected for people who like non-broken connectivity. What's more, the ping test was probably to some known good host(s), rather than a broad selection of Internet hosts, so effectively it was only testing the probe end, not both ends. Basically, I see RIPE probes as an almost best-case scenario for this sort of broken behavior. I bet the ISC Netalyzer folks have somewhat better data, perhaps skewed a bit towards broken connections as people run Netalyzer when their connection is broken! I suspect reality is somewhere between those two book ends. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: TCP Performance
You didn't indicate this, but do you understand how TCP windowing works? This conversation can go two very different ways depending on the answer. To me, it looks like this is what you'd expect, and you need to fix your packet loss issues, which possibly might be QoS settings related (but it's hard to tell based on the information given). -Blake On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen n...@flhsi.com wrote: Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: CogentOrlando Border Router (Mikrotik)HP Procurve Switch Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: CogentOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router (Mikrotik)HP Procurve SwitchServer Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando ServerHP Procurve SwitchOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router(Mikrotik)HP Procurve SwitchServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root@ded01 ~]# iperf -c 208.90.219.18 Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that, nothing really stands out to me as to why these transfers are so much slower. Intra-network iperf testing shows full throughput the whole way with single connection. As well as UDP testing. One thing to note is the Iperf testing has far less TCP re-transmit/dup acks then any of the HTTP testing, Crossing the same Microwave Links and routers. http://cdn.141networks.com/files/captures.zip I appreciate any insight anyone might have. Thanks! Nick Olsen Network Operations (855) FLSPEED x106
Re: IP Fragmentation - Not reliable over the Internet?
On Tue, 27 Aug 2013 00:34:57 -0700, Owen DeLong said: That's a lot of questions he didn't ask. This isn't your first rodeo. You should know by now that the question actually asked, the question *meant* to be asked, and the question that actually needed answering are often 3 different things. If I send a packet out as a legitimate series of fragments, what is the chance that they will get dropped somewhere in the middle of the path between the emitting host and the receiving host? To my thinking, the answer to that question is basically pretty close to 0 and if that changes in the core, very bad things will happen. Saku Ytti and Emile Aben have numbers that say otherwise. And there must be a significantly bigger percentage of failures than pretty close to 0, or Path MTU Discovery wouldn't have a reputation of being next to useless. pgptN6Peb7KZo.pgp Description: PGP signature
Re: IP Fragmentation - Not reliable over the Internet?
And then you have other issues like networks that arbitrarily set DF on all packets passing through them. That burnt a good three days of my life back in the day. -Blake On Tue, Aug 27, 2013 at 9:33 AM, valdis.kletni...@vt.edu wrote: On Tue, 27 Aug 2013 00:34:57 -0700, Owen DeLong said: That's a lot of questions he didn't ask. This isn't your first rodeo. You should know by now that the question actually asked, the question *meant* to be asked, and the question that actually needed answering are often 3 different things. If I send a packet out as a legitimate series of fragments, what is the chance that they will get dropped somewhere in the middle of the path between the emitting host and the receiving host? To my thinking, the answer to that question is basically pretty close to 0 and if that changes in the core, very bad things will happen. Saku Ytti and Emile Aben have numbers that say otherwise. And there must be a significantly bigger percentage of failures than pretty close to 0, or Path MTU Discovery wouldn't have a reputation of being next to useless.
Re: TCP Performance
Duplex mismatch has been checked across the board. On every device. Nick Olsen Network Operations (855) FLSPEED x106 From: Chad Dailey na...@thedaileyplanet.com Sent: Tuesday, August 27, 2013 10:48 AM To: n...@flhsi.com Subject: Re: TCP Performance Check for duplex mismatch at the server. On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen n...@flhsi.com wrote: Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: CogentOrlando Border Router (Mikrotik)HP Procurve Switch Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: CogentOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router (Mikrotik)HP Procurve SwitchServer Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando ServerHP Procurve SwitchOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router(Mikrotik)HP Procurve SwitchServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root@ded01 ~]# iperf -c 208.90.219.18Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that, nothing really stands out to me as to why these transfers are so much slower. Intra-network iperf testing shows full throughput the whole way with single connection. As well as UDP testing. One thing to note is the Iperf testing has far less TCP re-transmit/dup acks then any of the HTTP testing, Crossing the same Microwave Links and routers. http://cdn.141networks.com/files/captures.zip I appreciate any insight anyone might have. Thanks! Nick Olsen Network Operations (855) FLSPEED x106
Re: TCP Performance
I have done a decent amount of reading on both TCP windowing and Flow Control. But I've seen a lot of conflicting data. Some say flow control breaks more then it fixes. Where some say it's completely required. Currently we do not have Flow control enabled. Our routers do not support flow control currently (At least, Not at a configurable level, maybe at the NIC hardware wise). The only way we could currently implement flow control would be installing a manged switch (with flow control) between the router(s) and the Microwave links. Regarding packet loss. We once again have conflicting data. If you take a look at the packet captures. The file download in Orlando (Which rocks ~800Mb/) shows ~5K retransmits/Dup Acks. However the file download in Cocoa (Crossing the wireless) is about 3x that (~16K retransmits/dup acks). The same is shown on an intra-network test from server to server.. But only when HTTP. Iperf testing shows ~18 errors, Vs ~13K errors when HTTP based. Nick Olsen Network Operations (855) FLSPEED x106 From: Blake Dunlap iki...@gmail.com Sent: Tuesday, August 27, 2013 10:32 AM To: n...@flhsi.com Cc: nanog@nanog.org nanog@nanog.org Subject: Re: TCP Performance You didn't indicate this, but do you understand how TCP windowing works? This conversation can go two very different ways depending on the answer. To me, it looks like this is what you'd expect, and you need to fix your packet loss issues, which possibly might be QoS settings related (but it's hard to tell based on the information given). -Blake On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen n...@flhsi.com wrote: Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: CogentOrlando Border Router (Mikrotik)HP Procurve Switch Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: CogentOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router (Mikrotik)HP Procurve SwitchServer Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando ServerHP Procurve SwitchOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router(Mikrotik)HP Procurve SwitchServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root@ded01 ~]# iperf -c 208.90.219.18Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that, nothing really stands out to me as to why these transfers are so much slower. Intra-network iperf testing shows full throughput the whole way with single connection. As well as UDP testing. One thing to note is the Iperf testing has far less TCP re-transmit/dup acks then any of the HTTP testing, Crossing the same Microwave Links and routers. http://cdn.141networks.com/files/captures.zip I appreciate any insight anyone might have. Thanks! Nick Olsen Network Operations (855) FLSPEED x106
Re: TCP Performance
This really sounds like you aren't testing the correct flow type in i/jperf, or you have some QoS queues for http traffic but not the perf traffic that are filled. Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake On Tue, Aug 27, 2013 at 9:49 AM, Nick Olsen n...@flhsi.com wrote: Duplex mismatch has been checked across the board. On every device. Nick Olsen Network Operations (855) FLSPEED x106 From: Chad Dailey na...@thedaileyplanet.com Sent: Tuesday, August 27, 2013 10:48 AM To: n...@flhsi.com Subject: Re: TCP Performance Check for duplex mismatch at the server. On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen n...@flhsi.com wrote: Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: CogentOrlando Border Router (Mikrotik)HP Procurve Switch Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: CogentOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router (Mikrotik)HP Procurve SwitchServer Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando ServerHP Procurve SwitchOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router(Mikrotik)HP Procurve SwitchServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root@ded01 ~]# iperf -c 208.90.219.18 Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that, nothing really stands out to me as to why these transfers are so much slower. Intra-network iperf testing shows full throughput the whole way with single connection. As well as UDP testing. One thing to note is the Iperf testing has far less TCP re-transmit/dup acks then any of the HTTP testing, Crossing the same Microwave Links and routers. http://cdn.141networks.com/files/captures.zip I appreciate any insight anyone might have. Thanks! Nick Olsen Network Operations (855) FLSPEED x106
Anyone from Bluehost?
Hello, Can someone from Bluehost please contact me? Email blacklist issue. We have gone through the normal support channels, but have come up with the support staff @ Bluehost not understanding the nature of our request. Thanks, -Bobby
RE: TCP Performance
Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake In my experience - if you're traversing licenced microwave links as indicated flow control will definitely need to be ON. Check the radio modem stats to confirm but - if you're seeing lots of drops there you're overflowing the buffers on the radio modem.
Re: IP Fragmentation - Not reliable over the Internet?
On 8/27/2013 10:04 AM, Leo Bicknell wrote: On Aug 27, 2013, at 6:24 AM, Saku Ytti s...@ytti.fi wrote: On (2013-08-27 10:45 +0200), Emile Aben wrote: 224 vantage points, 10 failed. 48 byte ping:42 out of 3406 vantage points fail (1.0%) 1473 byte ping: 180 out of 3540 vantage points fail (5.1%) Nice, it's starting to almost sound like data rather than anecdote, both tests implicate 45% having fragmentation issues. Much larger number than I intuitively had in mind. I'm pretty sure the failure rate is higher, and here's why. The #1 cause of fragments being dropped is firewalls. Too many admins configuring a firewall do not understand fragments or how to properly put them in the rules. Where do firewalls exist? Typically protecting things with public IP space, that is (some) corporate networks and banks of content servers in data centers. This also includes on-box firewalls for Internet servers, ipfw or iptables on the server is just as likely to be part of the problem. It's not just firewalls border-routers are also apt to have ACLs like these[1]: ip access-list extended BORDER-IN 10 deny tcp any any fragments 20 deny udp any any fragments 30 deny icmp any any fragments 40 deny ip any any fragments I see these a *LOT* on customer routers, before the packets even get to the firewall Regards, dtb 1. I found it most recently at http://hurricanelabs.com/blog/cisco-security-routers/ but I know there are many other guides that include these as part of their ACL.
Re: TCP Performance
If you have a router, you can turn on shaping to the bandwidth the link will support. -Blake On Tue, Aug 27, 2013 at 12:11 PM, Nick Olsen n...@flhsi.com wrote: I do indeed have stats for TX Pause Frames And they do increment. However, Our router is ignoring them since it doesn't support flow control. I guess my next question would be. In the scenario where we insert a switch between the radio and the router that does support flow control. Are we not only moving where the overflow is going to occur? Will we not see the router still burst traffic at line rate toward the switch, Which then buffer overflows sending to the radio on account of it receiving pause frames? Nick Olsen Network Operations (855) FLSPEED x106 -- *From*: Tim Warnock tim...@timoid.org *Sent*: Tuesday, August 27, 2013 1:08 PM *To*: Blake Dunlap iki...@gmail.com, n...@flhsi.com n...@flhsi.com *Cc*: nanog@nanog.org nanog@nanog.org *Subject*: RE: TCP Performance Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake In my experience - if you're traversing licenced microwave links as indicated flow control will definitely need to be ON. Check the radio modem stats to confirm but - if you're seeing lots of drops there you're overflowing the buffers on the radio modem.
Re: TCP Performance
No QoS is in use anywhere.. To the best of my ability I've eliminated Packet loss. However, I've not found a way any better than ICMP/MTR/Ping -f..etc. The reason flow control has been mentioned is to correct buffer overflow at the Microwave links. Where they physically link at GigFDX. But the radio interface is only capable of ~360Mb/s, It's possible for the sending device to overflow the buffer between the fiber/ethernet and the radio interface.I can say we've had an issue like this in the past, Which forcing 100Mb/s FDX on a licensed radio fixed the problem. Being that, The ethernet was now slower then the radio interface. However, The down fall of this is that it limits the link to 100Mb/s which isn't sufficient anymore. In terms of congestion, There is not from my point of view. Every link in questions runs =30% utilization. Nick Olsen Network Operations (855) FLSPEED x106 From: Blake Dunlap iki...@gmail.com Sent: Tuesday, August 27, 2013 11:42 AM To: n...@flhsi.com Cc: na...@thedaileyplanet.com, nanog@nanog.org nanog@nanog.org Subject: Re: TCP Performance This really sounds like you aren't testing the correct flow type in i/jperf, or you have some QoS queues for http traffic but not the perf traffic that are filled. Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake On Tue, Aug 27, 2013 at 9:49 AM, Nick Olsen n...@flhsi.com wrote: Duplex mismatch has been checked across the board. On every device. Nick Olsen Network Operations (855) FLSPEED x106 From: Chad Dailey na...@thedaileyplanet.com Sent: Tuesday, August 27, 2013 10:48 AM To: n...@flhsi.com Subject: Re: TCP Performance Check for duplex mismatch at the server. On Mon, Aug 26, 2013 at 2:07 PM, Nick Olsen n...@flhsi.com wrote: Greetings all, I've got an issue I was hoping to put a few more eyes on. Here's the scenario. Downloading a file at our Border is multiple orders of magnitude faster then a few hops out. Using the same 128MB test file, I tested at two different locations. As well as between them. Using multiple connections improves throughput, However it's the single stream issue we're looking at right now. All testing servers in question are Centos Linux. Orlando Datapath: CogentOrlando Border Router (Mikrotik)HP Procurve Switch Server Results: 2013-08-29 05:04:09 (52.6 MB/s) - `128mbfile.tgz' saved [127926272/127926272] Cocoa NOC Datapath: CogentOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router (Mikrotik)HP Procurve SwitchServer Results: 2013-08-26 13:42:25 (398 KB/s) - `128mbfile.tgz' saved [127926272/127926272] Orlando-Cocoa NOC Datapath: Orlando ServerHP Procurve SwitchOrlando Border Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)East Orange Router (Mikrotik) Licensed Microwave Link (300+Mb/s Capacity)Cocoa Router (Mikrotik)Licensed Microwave Link (300+Mb/s Capacity)Colo Router (Mikrotik)NOC Router(Mikrotik)HP Procurve SwitchServerResults: 2013-08-26 13:56:25 (3.31 MB/s) - `128mbfile.tgz' saved [134217728/134217728] Now, For the fun of it. I ran Iperf single TCP between our Cocoa and Orlando POP's. Just like the HTTP test above. (Server has a 100Mb/s port). It maxes out the port, Unlike the HTTP test. [root@ded01 ~]# iperf -c 208.90.219.18Cli ent connecting to 208.90.219.18, TCP port 5001TCP window size: 16.0 KByte (default)[ 3] local 206.208.56.130 port 47281 connected with 208.90.219.18 port 5001[ ID] Interval Transfer Bandwidth[ 3] 0.0-10.0 sec 114 MBytes 95.7 Mbits/sec Here's associated packet captures for each transfer. As well as full wget output and traceroutes for each test. As you can see, The tests crossing the wireless links show about 3x more TCP re-transmits/dup ACK's. But I'm not sure I'm sold this could show such a huge drop in throughput. Other then that,
RE: TCP Performance
I do indeed have stats for TX Pause Frames And they do increment. However, Our router is ignoring them since it doesn't support flow control. I guess my next question would be. In the scenario where we insert a switch between the radio and the router that does support flow control. Are we not only moving where the overflow is going to occur? Will we not see the router still burst traffic at line rate toward the switch, Which then buffer overflows sending to the radio on account of it receiving pause frames? Nick Olsen Network Operations (855) FLSPEED x106 From: Tim Warnock tim...@timoid.org Sent: Tuesday, August 27, 2013 1:08 PM To: Blake Dunlap iki...@gmail.com, n...@flhsi.com n...@flhsi.com Cc: nanog@nanog.org nanog@nanog.org Subject: RE: TCP Performance Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake In my experience - if you're traversing licenced microwave links as indicated flow control will definitely need to be ON. Check the radio modem stats to confirm but - if you're seeing lots of drops there you're overflowing the buffers on the radio modem.
Re: IP Fragmentation - Not reliable over the Internet?
On Mon, Aug 26, 2013 at 8:01 PM, Christopher Palmer christopher.pal...@microsoft.com wrote: What is the probability that a random path between two Internet hosts will traverse a middlebox that drops or otherwise barfs on fragmented IPv4 packets? Hi Christopher, I think there might be three rather different questions here: 1. If I originate IP packet fragments, such as an 8000 byte NFS packet broken into 1500 byte fragments, what's the probability of some host before the other endpoint dropping one or all of those fragments? 2. If I send an IP packet that's too large for the path and *don't* set the don't-fragment bit, what' the chance that the router with the too-small next hop will fail to correctly fragment that packet (or that the correctly fragmented packet will fall into trap #1 above)? 3. If I send an IP packet that's too large for the path and *do* set the don't-fragment bit, what's the chance of failing to receive the packet too big message it causes the intermediate router to send? Are you after the answer to one in particular? Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: TCP Performance
I have indeed tried that. And it didn't make any difference. Functionally limiting each router port to is connected microwave links capacity. And queuing the overflow. However the queue never really fills as the traffic rate never goes higher then the allocated bandwidth. Nick Olsen Network Operations (855) FLSPEED x106 From: Blake Dunlap iki...@gmail.com Sent: Tuesday, August 27, 2013 1:32 PM To: n...@flhsi.com Cc: Tim Warnock tim...@timoid.org, nanog@nanog.org nanog@nanog.org Subject: Re: TCP Performance If you have a router, you can turn on shaping to the bandwidth the link will support. -Blake On Tue, Aug 27, 2013 at 12:11 PM, Nick Olsen n...@flhsi.com wrote: I do indeed have stats for TX Pause Frames And they do increment. However, Our router is ignoring them since it doesn't support flow control. I guess my next question would be. In the scenario where we insert a switch between the radio and the router that does support flow control. Are we not only moving where the overflow is going to occur? Will we not see the router still burst traffic at line rate toward the switch, Which then buffer overflows sending to the radio on account of it receiving pause frames? Nick Olsen Network Operations (855) FLSPEED x106 From: Tim Warnock tim...@timoid.org Sent: Tuesday, August 27, 2013 1:08 PM To: Blake Dunlap iki...@gmail.com, n...@flhsi.com n...@flhsi.com Cc: nanog@nanog.org nanog@nanog.org Subject: RE: TCP Performance Regardless, your problem looks like either tail drops or packet loss, which you showed originally. The task is to find out where this is occurring, and which of the two it is. If you want to confirm what is going on, there are some great bandwidth calculators on the internet which will show you what bandwidth you can get with a given ms delay and % packet loss. As far as flow control, its really outside the scope. If you ever need flow control, there is usually a specific reason like FCoE, and if not, it's generally better to just fix the backplane congestion issue if you can, than ever worry about using FC. The problem with FC isn't node to node, its when you have node to node to node with additional devices, it isn't smart enough to discriminate, and can crater your network 3 devices over when it would be much better to just lose a few packets. -Blake In my experience - if you're traversing licenced microwave links as indicated flow control will definitely need to be ON. Check the radio modem stats to confirm but - if you're seeing lots of drops there you're overflowing the buffers on the radio modem.
Re: IP Fragmentation - Not reliable over the Internet?
On Aug 27, 2013, at 07:33 , valdis.kletni...@vt.edu wrote: On Tue, 27 Aug 2013 00:34:57 -0700, Owen DeLong said: That's a lot of questions he didn't ask. This isn't your first rodeo. You should know by now that the question actually asked, the question *meant* to be asked, and the question that actually needed answering are often 3 different things. If I send a packet out as a legitimate series of fragments, what is the chance that they will get dropped somewhere in the middle of the path between the emitting host and the receiving host? To my thinking, the answer to that question is basically pretty close to 0 and if that changes in the core, very bad things will happen. Saku Ytti and Emile Aben have numbers that say otherwise. And there must be a significantly bigger percentage of failures than pretty close to 0, or Path MTU Discovery wouldn't have a reputation of being next to useless. No, their numbers describe what happens to single packets of differing sizes. Nothing they did describes results of actually fragmented packets. Owen
Evaluating Tier 1 Internet providers
Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? And how would I get a quantitative or qualitative measure of it? routing stability BGP community offerings congestion issues BGP Peering relationships path diversity IPv6 table size Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. I'm shopping for new service and want to do better than choosing on reputation. (or, is reputation also a criteria?) much appreciated, Eric Louie
Re: Evaluating Tier 1 Internet providers
On 2013-08-27, at 15:02, Eric Louie elo...@yahoo.com wrote: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? And how would I get a quantitative or qualitative measure of it? routing stability BGP community offerings congestion issues BGP Peering relationships path diversity IPv6 table size I would add: - presence of staff in key locations (if 60 Hudson is a critical location for you, find out whether there's someone regularly present in or near the building to clean fibre and help run loopback tests when you need them) - expected time to clue when calling the support number (bonus points for being xkcd-806 compliant) - time taken to turn around BGP import filter changes - response you can expect when you call one day and say our 10GE is maxed out with inbound traffic from apparently everywhere, it has been going on for an hour, please help - billing accuracy, and turnaround time for questions raised about invoices received A lot of this comes down to conversations in the NANOG bar with people who have war stories to share. To that extent, I think reputation is a good indicator, so long as your sample size is reasonable, and depending on the amount of beer involved. One other thing to think about -- Tier 1 providers are transit free, so your can be reached by an IP packet from is naturally limited to specific peering relationships with other Tier 1 providers. Tier 2 providers (those who buy transit from a suitably-diverse set of Tier 1s) can insulate you from route fade due to peering spats. Joe
looking for hostname geographic hint validation
We are currently working on an algorithm that automatically detects
geographic hints inside of hostnames. At this point we are seeking
operators who can validate some of our inferences. Please contact me
if you can valid one of the inferences below or can provide us with one
we have missed.
###
# Inferences
###
iata (International Air Transport Association airport code)
http://en.wikipedia.org/wiki/International_Air_Transport_Association_airport_code
iaco International Civil Aviation Organization airport code
http://en.wikipedia.org/wiki/International_Civil_Aviation_Organization_airport_code
clli COMMON LANGUAGE Location Identifier Code
http://en.wikipedia.org/wiki/CLLI
city name largest populated city with the given name
for example sandiego is San Diego, CA, US
iata[^a-z]+[a-z]+\d*.0rbitel.net
iata([^a-z]+[a-z]+\d*){2}.360.net
iata[^a-z]+[a-z]+\d*.NULL
iata[^a-z]+[a-z]+\d*.aaanet.ru
iata-vis\d*.aapt.net.au
iata.aarnet.net.au
city name[^a-z]+[a-z]+\d*.above.net
iata[^a-z]+[a-z]+\d*.above.net
city name.ac-net.net
iata.accretive-networks.net
iata\d*.acens.net
iata.acesso10.net.br
city name\d*.aco.net
iata.acsalaska.net
iata[^a-z]+[a-z]+\d*.acsalaska.net
iata.wholesale.adamo.es
iata\d*.adaptplc.com
iata.par.adenis.fr
iata-esr\d*.edc\d*.adhost.com
iata-...\d*\d*.adhost.net
city name([^a-z]+[a-z]+\d*){2}.adnettelecom.ro
city name-noc.affrc.go.jp
iata([^a-z]+[a-z]+\d*){5}.africainx.net
iata--africainx.net
iata\d*afrisp.net
city name\d*.afsnetworks.com
city name.ahrt.hu
iata.rev.hu.ahrt.hu
iata([^a-z]+[a-z]+\d*){2}.ainaip.net
iata([^a-z]+[a-z]+\d*){4}.ainaip.net
iata.airband.net
city name([^a-z]+[a-z]+\d*){2}.airexpress.net.ua
city name([^a-z]+[a-z]+\d*){3}.airexpress.net.ua
iata([^a-z]+[a-z]+\d*){2}.airtelbroadband.in
iata\d*.netarch.akamai.com
city name[^a-z]+[a-z]+\d*.akquinet.de
iata\d*.alestra.net.mx
city name\d*-...alkar.net
iata.se.alltele.net
iata([^a-z]+[a-z]+\d*){3}.alog.com.br
iata.altecom.net
iata([^a-z]+[a-z]+\d*){2}.alter.net
iata\d*.alter.net
iata\d*.amcbb.net
clli.ameritech.net
city name[^a-z]+[a-z]+\d*.amis.net
city name\d*.amis.net
iata([^a-z]+[a-z]+\d*){2}.amobia.com
city name.amplivia.fr
iata-..\d*-\d*.anittel.net
iata1.antel.net.uy
iata\d*bras\d*-bb\d*.antel.net.uy
iata01a-ra1.aorta.net
iata01b-rd1-ae12.aorta.net
iata[^a-z]+[a-z]+\d*.apexn.com.au
iata([^a-z]+[a-z]+\d*){2}.arbinet.net
iata\d*.arbinet.net
iata[^a-z]+[a-z]+\d*.arianrp.ir
iata.as12703.net
iata\d*as13237.net
iata.as13285.net
city name([^a-z]+[a-z]+\d*){2}.as2116.net
city name([^a-z]+[a-z]+\d*){3}.as2116.net
iata1.as24557.net.au
iata.ip.as29154.net
iata\d*.as39506.net
iata.at.as39912.net
iata[^a-z]+[a-z]+\d*.as42689.net
iata1.as4851.net
city name([^a-z]+[a-z]+\d*){3}.as5580.net
iata[^a-z]+[a-z]+\d*.as5580.net
iata.as5587.net
city name\d*.as6453.net
Re: Evaluating Tier 1 Internet providers
On Tue, 27 Aug 2013, Eric Louie wrote: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? And how would I get a quantitative or qualitative measure of it? Define Tier 1 provider. I ask this because it's something that many people don't know what it means, but assume that Tier 1 Tier !=1. routing stability Routeviews.org can shed some light here. BGP community offerings If $provider has a page on www.peeringdb.com, they might publish a list of their BGP communities there. Other places to look would be the provider's whois/IRR entries, and on their respective websites, or the sales/marketing folks might be able to get this information for you. congestion issues There are various internet traffic report / weather report sites that can give you indirect insight into things like. By indirect, I mean that you might be able to infer things like congestion at a specific point based on what you see on those sites. BGP Peering relationships You can look at pages like www.peeringdb.com, and you will typically see if $provider is at an exchange, however the peering relationships that many providers have other providers (locations, speeds, etc) are confidential. path diversity You can ask $provider's sales and marketing folks, but there is no guarantee that you will get an answer (actual routes are considered confidential and proprietary information, despite the fact that a lot of providers' fiber ends up converging in a small handful of routes in some areas - i.e. many of them follow the same set of railroad tracks or cross a river at the same bridge, possibly even in the same conduit) or a correct answer (wave X might be re-groomed onto path Y without a whole lot of customer notification). IPv6 table size Sites like routeviews.org can give you some visibility here. Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. I'm shopping for new service and want to do better than choosing on reputation. (or, is reputation also a criteria?) Absolutely reputation should be a factor. I would argue that Internet access is largely commoditized anymore (and has been for several years), so the real differentiators are cost and level of service. jms
Re: Evaluating Tier 1 Internet providers
On Aug 27, 2013, at 12:02 PM, Eric Louie elo...@yahoo.com wrote: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. It's easy. Tier 1 is yourself. Tier 2 is your customers and your competitors. Tier 3 is your customers' customers, your competitors' customers, and your customers' competitors. But yes, I'm sure there are as many criteria as there are NANOG subscribers. But Joe Abley's are the correct ones. ducking -Bill signature.asc Description: Message signed with OpenPGP using GPGMail
RE: Evaluating Tier 1 Internet providers
Clued-in support is a good criteria. (I've been using a broker for some of my connections and there was virtually no value-add there, especially in the prefix-list modifications, and a liability in other MACs) That's a good point with the Tier 2 providers. So that begs the question, why wouldn't I just get my upstream from a Tier 2? (Because my management is under the perception that we're better off with Tier 1 providers, but that doesn't mean their perception is accurate) much appreciated, Eric Louie -Original Message- From: Joe Abley [mailto:jab...@hopcount.ca] Sent: Tuesday, August 27, 2013 12:15 PM To: Eric Louie Cc: nanog@nanog.org Subject: Re: Evaluating Tier 1 Internet providers On 2013-08-27, at 15:02, Eric Louie elo...@yahoo.com wrote: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? And how would I get a quantitative or qualitative measure of it? routing stability BGP community offerings congestion issues BGP Peering relationships path diversity IPv6 table size I would add: - presence of staff in key locations (if 60 Hudson is a critical location for you, find out whether there's someone regularly present in or near the building to clean fibre and help run loopback tests when you need them) - expected time to clue when calling the support number (bonus points for being xkcd-806 compliant) - time taken to turn around BGP import filter changes - response you can expect when you call one day and say our 10GE is maxed out with inbound traffic from apparently everywhere, it has been going on for an hour, please help - billing accuracy, and turnaround time for questions raised about invoices received A lot of this comes down to conversations in the NANOG bar with people who have war stories to share. To that extent, I think reputation is a good indicator, so long as your sample size is reasonable, and depending on the amount of beer involved. One other thing to think about -- Tier 1 providers are transit free, so your can be reached by an IP packet from is naturally limited to specific peering relationships with other Tier 1 providers. Tier 2 providers (those who buy transit from a suitably-diverse set of Tier 1s) can insulate you from route fade due to peering spats. Joe
RE: Evaluating Tier 1 Internet providers
Good stuff Justin - Any other criteria that you would use? much appreciated, Eric Louie -Original Message- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] Sent: Tuesday, August 27, 2013 9:17 AM To: nanog@nanog.org Subject: Re: Evaluating Tier 1 Internet providers On Tue, 27 Aug 2013, Eric Louie wrote: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? And how would I get a quantitative or qualitative measure of it? Define Tier 1 provider. I ask this because it's something that many people don't know what it means, but assume that Tier 1 Tier !=1. routing stability Routeviews.org can shed some light here. BGP community offerings If $provider has a page on www.peeringdb.com, they might publish a list of their BGP communities there. Other places to look would be the provider's whois/IRR entries, and on their respective websites, or the sales/marketing folks might be able to get this information for you. congestion issues There are various internet traffic report / weather report sites that can give you indirect insight into things like. By indirect, I mean that you might be able to infer things like congestion at a specific point based on what you see on those sites. BGP Peering relationships You can look at pages like www.peeringdb.com, and you will typically see if $provider is at an exchange, however the peering relationships that many providers have other providers (locations, speeds, etc) are confidential. path diversity You can ask $provider's sales and marketing folks, but there is no guarantee that you will get an answer (actual routes are considered confidential and proprietary information, despite the fact that a lot of providers' fiber ends up converging in a small handful of routes in some areas - i.e. many of them follow the same set of railroad tracks or cross a river at the same bridge, possibly even in the same conduit) or a correct answer (wave X might be re-groomed onto path Y without a whole lot of customer notification). IPv6 table size Sites like routeviews.org can give you some visibility here. Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. I'm shopping for new service and want to do better than choosing on reputation. (or, is reputation also a criteria?) Absolutely reputation should be a factor. I would argue that Internet access is largely commoditized anymore (and has been for several years), so the real differentiators are cost and level of service. jms
RE: Evaluating Tier 1 Internet providers
On Tue, 27 Aug 2013, Eric Louie wrote: Good stuff Justin - Any other criteria that you would use? Joe covered a lot of good stuff in his response. A few providers call themselves Tier 1, though the accuracy of those assertions is often suspect. The truth can be somewhat more complicated... and exactly how much more complicated isn't always clear until Provider X gets de-peered by Provider Y and finds themselves having to negotiate a quick fix, often by cutting a check. I would also ask people here who they have had very good experiences with, regardless of what tier the provider fits into. jms -Original Message- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] Sent: Tuesday, August 27, 2013 9:17 AM To: nanog@nanog.org Subject: Re: Evaluating Tier 1 Internet providers On Tue, 27 Aug 2013, Eric Louie wrote: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? And how would I get a quantitative or qualitative measure of it? Define Tier 1 provider. I ask this because it's something that many people don't know what it means, but assume that Tier 1 Tier !=1. routing stability Routeviews.org can shed some light here. BGP community offerings If $provider has a page on www.peeringdb.com, they might publish a list of their BGP communities there. Other places to look would be the provider's whois/IRR entries, and on their respective websites, or the sales/marketing folks might be able to get this information for you. congestion issues There are various internet traffic report / weather report sites that can give you indirect insight into things like. By indirect, I mean that you might be able to infer things like congestion at a specific point based on what you see on those sites. BGP Peering relationships You can look at pages like www.peeringdb.com, and you will typically see if $provider is at an exchange, however the peering relationships that many providers have other providers (locations, speeds, etc) are confidential. path diversity You can ask $provider's sales and marketing folks, but there is no guarantee that you will get an answer (actual routes are considered confidential and proprietary information, despite the fact that a lot of providers' fiber ends up converging in a small handful of routes in some areas - i.e. many of them follow the same set of railroad tracks or cross a river at the same bridge, possibly even in the same conduit) or a correct answer (wave X might be re-groomed onto path Y without a whole lot of customer notification). IPv6 table size Sites like routeviews.org can give you some visibility here. Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. I'm shopping for new service and want to do better than choosing on reputation. (or, is reputation also a criteria?) Absolutely reputation should be a factor. I would argue that Internet access is largely commoditized anymore (and has been for several years), so the real differentiators are cost and level of service. jms
Re: Evaluating Tier 1 Internet providers
On Tue, 27 Aug 2013 13:45:34 -0700, Eric Louie said: That's a good point with the Tier 2 providers. So that begs the question, why wouldn't I just get my upstream from a Tier 2? (Because my management is under the perception that we're better off with Tier 1 providers, but that doesn't mean their perception is accurate) The good thing about your upstream being a Tier 2 is that it usually means that if somebody's baking a peering cake, you're not one of the AS's that's suffering. Hmmm... if you're going for a connection to a Tier 1, maybe peering cakes per decade is a valid criterion? pgp7jWzZPadXc.pgp Description: PGP signature
Re: Evaluating Tier 1 Internet providers
http://www.renesys.com/products/ provide some guidance, but probably not the kind of detailed tech you want. Judging from my own experience, we have mostly been hit by limited path diversity everything seems fine support in the past. -- Tassos Eric Louie wrote on 27/8/2013 22:02: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? And how would I get a quantitative or qualitative measure of it? routing stability BGP community offerings congestion issues BGP Peering relationships path diversity IPv6 table size Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. I'm shopping for new service and want to do better than choosing on reputation. (or, is reputation also a criteria?) much appreciated, Eric Louie
RE: Evaluating Tier 1 Internet providers
Tier 1 = Internet backbone providers (United States - ATT, UUNET, Sprint, AboveNet/Zayo, Cogent, Qwest/CenturyLink, L3/GBLX). However, I might be better served with a Tier 2 for reachability as pointed out in another response. When you say level of service, what are you referring to? Customer service? Service level agreement (which is pretty much the same across all the Tier 1's)? much appreciated, Eric Louie -Original Message- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] Sent: Tuesday, August 27, 2013 9:17 AM To: nanog@nanog.org Subject: Re: Evaluating Tier 1 Internet providers On Tue, 27 Aug 2013, Eric Louie wrote: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? And how would I get a quantitative or qualitative measure of it? Define Tier 1 provider. I ask this because it's something that many people don't know what it means, but assume that Tier 1 Tier !=1. routing stability Routeviews.org can shed some light here. BGP community offerings If $provider has a page on www.peeringdb.com, they might publish a list of their BGP communities there. Other places to look would be the provider's whois/IRR entries, and on their respective websites, or the sales/marketing folks might be able to get this information for you. congestion issues There are various internet traffic report / weather report sites that can give you indirect insight into things like. By indirect, I mean that you might be able to infer things like congestion at a specific point based on what you see on those sites. BGP Peering relationships You can look at pages like www.peeringdb.com, and you will typically see if $provider is at an exchange, however the peering relationships that many providers have other providers (locations, speeds, etc) are confidential. path diversity You can ask $provider's sales and marketing folks, but there is no guarantee that you will get an answer (actual routes are considered confidential and proprietary information, despite the fact that a lot of providers' fiber ends up converging in a small handful of routes in some areas - i.e. many of them follow the same set of railroad tracks or cross a river at the same bridge, possibly even in the same conduit) or a correct answer (wave X might be re-groomed onto path Y without a whole lot of customer notification). IPv6 table size Sites like routeviews.org can give you some visibility here. Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. I'm shopping for new service and want to do better than choosing on reputation. (or, is reputation also a criteria?) Absolutely reputation should be a factor. I would argue that Internet access is largely commoditized anymore (and has been for several years), so the real differentiators are cost and level of service. jms
RE: Evaluating Tier 1 Internet providers
I'm thinking that same thing, although after researching, the de-peering King is probably not a contender as one of our primary upstream connection. (And I don't have secondary or tertiary connections) much appreciated, Eric Louie -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Tuesday, August 27, 2013 2:03 PM To: Eric Louie Cc: nanog@nanog.org Subject: Re: Evaluating Tier 1 Internet providers On Tue, 27 Aug 2013 13:45:34 -0700, Eric Louie said: That's a good point with the Tier 2 providers. So that begs the question, why wouldn't I just get my upstream from a Tier 2? (Because my management is under the perception that we're better off with Tier 1 providers, but that doesn't mean their perception is accurate) The good thing about your upstream being a Tier 2 is that it usually means that if somebody's baking a peering cake, you're not one of the AS's that's suffering. Hmmm... if you're going for a connection to a Tier 1, maybe peering cakes per decade is a valid criterion?
Re: Evaluating Tier 1 Internet providers
If you don't have secondary connectivity, then I don't suggest going with a Teir 1. Using a peer-only as a transit link is not something I would recommend in general unless you know what you are doing in that regard, and have designed around the inevitable peering issues related to that decision. -Blake On Tue, Aug 27, 2013 at 4:14 PM, Eric Louie elo...@yahoo.com wrote: I'm thinking that same thing, although after researching, the de-peering King is probably not a contender as one of our primary upstream connection. (And I don't have secondary or tertiary connections) much appreciated, Eric Louie -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Tuesday, August 27, 2013 2:03 PM To: Eric Louie Cc: nanog@nanog.org Subject: Re: Evaluating Tier 1 Internet providers On Tue, 27 Aug 2013 13:45:34 -0700, Eric Louie said: That's a good point with the Tier 2 providers. So that begs the question, why wouldn't I just get my upstream from a Tier 2? (Because my management is under the perception that we're better off with Tier 1 providers, but that doesn't mean their perception is accurate) The good thing about your upstream being a Tier 2 is that it usually means that if somebody's baking a peering cake, you're not one of the AS's that's suffering. Hmmm... if you're going for a connection to a Tier 1, maybe peering cakes per decade is a valid criterion?
RE: Evaluating Tier 1 Internet providers
On Tue, 27 Aug 2013, Eric Louie wrote: Tier 1 = Internet backbone providers (United States - ATT, UUNET, Sprint, AboveNet/Zayo, Cogent, Qwest/CenturyLink, L3/GBLX). However, I might be better served with a Tier 2 for reachability as pointed out in another response. Some of those providers are probably not in the DFZ. I know Cogent has been involved in some peering spats in the past. I don't know off-hand if Zayo/Above lives in the DFZ. When you say level of service, what are you referring to? Customer service? Service level agreement (which is pretty much the same across all the Tier 1's)? Mainly customer service. Things like how easy it is to get a clued individual on the phone when there's an issue, turnaround time for things like BGP filter update requests. Like you mentioned, most providers' SLA terms are likely to look pretty similar if you were to compare them side-by-side. I would also look at which providers are on-net in your location, or would be willing to build into your location for a reasonable cost. One thing you want to avoid is all of your providers using the same local loop provider to get into the building, or local dark fiber providers using the same right-of-way / conduit / manhole to get into your building. Many providers might subcontract the physical last-mile construction to a local dark fiber provider. Entrance diversity and last-mile diversity is something you can probably have more influence over than how provider X gets between Chicago and New York. Many providers will build into your location if they're in your city if you either pay the build costs, or are purchasing enough service that the construction costs can amortized over the term of the contract. If they amortize, make sure you keep that in mind when the contract is up for re-negotiation, so they're no longer trying to ding you for construction costs that you've already paid :) jms
RE: Evaluating Tier 1 Internet providers
I appreciate that warning. The bigger truth is, No secondary/tertiary on that router/in that location. I do have iBGP with alternate providers through my core. much appreciated, Eric Louie -Original Message- From: Blake Dunlap [mailto:iki...@gmail.com] Sent: Tuesday, August 27, 2013 2:23 PM To: nanog@nanog.org Subject: Re: Evaluating Tier 1 Internet providers If you don't have secondary connectivity, then I don't suggest going with a Teir 1. Using a peer-only as a transit link is not something I would recommend in general unless you know what you are doing in that regard, and have designed around the inevitable peering issues related to that decision. -Blake On Tue, Aug 27, 2013 at 4:14 PM, Eric Louie elo...@yahoo.com wrote: I'm thinking that same thing, although after researching, the de-peering King is probably not a contender as one of our primary upstream connection. (And I don't have secondary or tertiary connections) much appreciated, Eric Louie -Original Message- From: valdis.kletni...@vt.edu [mailto:valdis.kletni...@vt.edu] Sent: Tuesday, August 27, 2013 2:03 PM To: Eric Louie Cc: nanog@nanog.org Subject: Re: Evaluating Tier 1 Internet providers On Tue, 27 Aug 2013 13:45:34 -0700, Eric Louie said: That's a good point with the Tier 2 providers. So that begs the question, why wouldn't I just get my upstream from a Tier 2? (Because my management is under the perception that we're better off with Tier 1 providers, but that doesn't mean their perception is accurate) The good thing about your upstream being a Tier 2 is that it usually means that if somebody's baking a peering cake, you're not one of the AS's that's suffering. Hmmm... if you're going for a connection to a Tier 1, maybe peering cakes per decade is a valid criterion?
Re: Evaluating Tier 1 Internet providers
To add some more from recent experiences.. Most of these are in colocation datacenters. - speed to handle your emergency support call. (recent experience, some tier1 can take a couple hours) - if support requires a portal opened ticket, is the staff to reset a password also 24/7. - Latency in your region.(recent experience: I removed 4 circuits because the backbones weren't the same in different areas). - Is you location a pop, metro ring or dedicated fiber elsewhere. - To get more specific, where is their peering in relationship to you. Strong peering not near you could mean a lot of extra latency just to get off their network. thanks, Bryan Socha
RE: Evaluating Tier 1 Internet providers
-Original Message- From: Justin M. Streiner [mailto:strei...@cluebyfour.org] Sent: Tuesday, August 27, 2013 10:36 AM To: nanog@nanog.org Subject: RE: Evaluating Tier 1 Internet providers On Tue, 27 Aug 2013, Eric Louie wrote: I would also look at which providers are on-net in your location, or would be willing to build into your location for a reasonable cost. One thing you want to avoid is all of your providers using the same local loop provider to get into the building, or local dark fiber providers using the same right-of-way / conduit / manhole to get into your building. Many providers might subcontract the physical last-mile construction to a local dark fiber provider. Entrance diversity and last-mile diversity is something you can probably have more influence over than how provider X gets between Chicago and New York. The only thing I'm looking at are on-net solutions - luckily or unluckily we are at data center locations (carrier neutral) so my choices are limited to the on-nets that they already have (I'm not going through the pain of bringing in a new one) and most of them are offering free install Many providers will build into your location if they're in your city if you either pay the build costs, or are purchasing enough service that the construction costs can amortized over the term of the contract. If they amortize, make sure you keep that in mind when the contract is up for re-negotiation, so they're no longer trying to ding you for construction costs that you've already paid :) jms
RE: Evaluating Tier 1 Internet providers
From: Bryan Socha [mailto:br...@serverstack.com] Sent: Tuesday, August 27, 2013 2:45 PM To: Eric Louie; nanog@nanog.org Subject: Re: Evaluating Tier 1 Internet providers To add some more from recent experiences.. Most of these are in colocation datacenters. [EL] I'm colocated too. - speed to handle your emergency support call. (recent experience, some tier1 can take a couple hours) [EL] time to respond / time to resolve are good ones (hard to get them to provide the true values, though) - if support requires a portal opened ticket, is the staff to reset a password also 24/7. - Latency in your region.(recent experience: I removed 4 circuits because the backbones weren't the same in different areas). - Is you location a pop, metro ring or dedicated fiber elsewhere. - To get more specific, where is their peering in relationship to you. Strong peering not near you could mean a lot of extra latency just to get off their network. [EL] How many hops to their edge? Will they admit that? can I get a traceroute? (however, this is in downtown LA so I'm guessing it's close to the edge thanks, Bryan Socha
Re: Evaluating Tier 1 Internet providers
If this was previously mentioned, my apologies. The time they can respond to a PNI upgrade. If you have an existing 10G and wish to add another. Can this be provisioned off the same device to form a LAG or can they only provide ECMP. May not be something you can evaluate at contract signing, but it can quickly become an issue when you need it. On Tue, Aug 27, 2013 at 12:02 PM, Eric Louie elo...@yahoo.com wrote: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? And how would I get a quantitative or qualitative measure of it? routing stability BGP community offerings congestion issues BGP Peering relationships path diversity IPv6 table size Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. I'm shopping for new service and want to do better than choosing on reputation. (or, is reputation also a criteria?) much appreciated, Eric Louie -- Bill Blackford Logged into reality and abusing my sudo privileges.
Re: Evaluating Tier 1 Internet providers
- speed to handle your emergency support call. (recent experience, some tier1 can take a couple hours) *[EL] * time to respond / time to resolve are good ones (hard to get them to provide the true values, though) Call and pretend your a customer with an emergency.You might be surprised how long it takes the first person to be on the call with you. - To get more specific, where is their peering in relationship to you. Strong peering not near you could mean a lot of extra latency just to get off their network. *[EL] *“How many hops to their edge”? Will they admit that? can I get a traceroute? (however, this is in downtown LA so I’m guessing it’s close to the edge * * This one can be harder to get any answers on depending on who you are. You can ask what locations they have most of their peering with. Also ask for a POP list they are located in. Usually they are marked with the type of service each building is (pop vs metro ring vs extension).unless it's a private peer, I woudlnt' expect any peering at locations that are not pops and you can see what is nearby your location that is a pop. Somethign else I just thought of that I do ask providers. Ask how they get into your building. If they are using some sort of metro ring between their routers make sure your not about to screw yourself with no diversity when that ring needs to be worked on. Thanks, Bryan
Re: Evaluating Tier 1 Internet providers
On Tue, Aug 27, 2013 at 3:02 PM, Eric Louie elo...@yahoo.com wrote: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? Billing issues such as: attitude during a billing dispute traceability and accountability (Which service is this 35 cent blah fee attached to?) zombie service rate (Bills showing up for long-ago cancelled products) flexibility (I want you to send me two bills, each for half of that. You can't? Why not?) nickle and dime (There's a $100 monthly rental fee for that 50 foot cat-5 cable!? Really!?) Also, abuse desk knee-jerkiness. If someone reports a problem originating from my system, how much leeway do I have to fix it before you decide to fix it for me? If some knucklehead with a port-scanning worm earns me a no-notice cut off, you and I will have words. At the same time, I don't want to fund someone who would turn a blind eye. Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. I'm shopping for new service and want to do better than choosing on reputation. (or, is reputation also a criteria?) Reputations are well earned and are certainly a factor. They're heavily qualitative, though. I don't know that's it's practical or useful to measure them. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Evaluating Tier 1 Internet providers
You should also consider who exactly your customers (or you alone) want to reach. Are you mostly looking to connect to eyeball networks? Enterprise networks? Government networks? If you have some target networks you should do some due diligence to find out how well connected your various options are to the networks that mean the most to you. If possible, I would also recommend talking to other people that are in your data centers, if that's possible. You might find out about hidden vendor-specific gremlins in that location. Regards, Mike On Aug 27, 2013, at 12:02 PM, Eric Louie elo...@yahoo.com wrote: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? And how would I get a quantitative or qualitative measure of it? routing stability BGP community offerings congestion issues BGP Peering relationships path diversity IPv6 table size Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. I'm shopping for new service and want to do better than choosing on reputation. (or, is reputation also a criteria?) much appreciated, Eric Louie
Re: Evaluating Tier 1 Internet providers
On Tue, Aug 27, 2013 at 3:02 PM, Eric Louie elo...@yahoo.com wrote: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? BGP Peering relationships Peering policy. A tier 1 with an open peering policy would get all my money. Even a semi-open policy (bring your network to any of these neutral locations at your cost and we'll peer settlement-free for our regional routes) would be worth encouraging through the purchase of transit services. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Evaluating Tier 1 Internet providers
- time taken to turn around BGP import filter changes So much This... You don't realize how important this is until your nationwide provider takes 8 WEEKS to add one network to your (already set up and working for 20 other networks) peering. Then decides to charge you a fee for the change. Ben Hatton Network Systems Engineer On Tue, Aug 27, 2013 at 1:05 PM, Justin M. Streiner strei...@cluebyfour.org wrote: On Tue, 27 Aug 2013, Eric Louie wrote: Good stuff Justin - Any other criteria that you would use? Joe covered a lot of good stuff in his response. A few providers call themselves Tier 1, though the accuracy of those assertions is often suspect. The truth can be somewhat more complicated... and exactly how much more complicated isn't always clear until Provider X gets de-peered by Provider Y and finds themselves having to negotiate a quick fix, often by cutting a check. I would also ask people here who they have had very good experiences with, regardless of what tier the provider fits into. jms -Original Message- From: Justin M. Streiner [mailto:streiner@cluebyfour.**orgstrei...@cluebyfour.org ] Sent: Tuesday, August 27, 2013 9:17 AM To: nanog@nanog.org Subject: Re: Evaluating Tier 1 Internet providers On Tue, 27 Aug 2013, Eric Louie wrote: Based on various conversation threads on Nanog I've come up with a few criteria for evaluating Tier 1 providers. I'm open to add other criteria - what would you add to this list? And how would I get a quantitative or qualitative measure of it? Define Tier 1 provider. I ask this because it's something that many people don't know what it means, but assume that Tier 1 Tier !=1. routing stability Routeviews.org can shed some light here. BGP community offerings If $provider has a page on www.peeringdb.com, they might publish a list of their BGP communities there. Other places to look would be the provider's whois/IRR entries, and on their respective websites, or the sales/marketing folks might be able to get this information for you. congestion issues There are various internet traffic report / weather report sites that can give you indirect insight into things like. By indirect, I mean that you might be able to infer things like congestion at a specific point based on what you see on those sites. BGP Peering relationships You can look at pages like www.peeringdb.com, and you will typically see if $provider is at an exchange, however the peering relationships that many providers have other providers (locations, speeds, etc) are confidential. path diversity You can ask $provider's sales and marketing folks, but there is no guarantee that you will get an answer (actual routes are considered confidential and proprietary information, despite the fact that a lot of providers' fiber ends up converging in a small handful of routes in some areas - i.e. many of them follow the same set of railroad tracks or cross a river at the same bridge, possibly even in the same conduit) or a correct answer (wave X might be re-groomed onto path Y without a whole lot of customer notification). IPv6 table size Sites like routeviews.org can give you some visibility here. Seems like everyone offers 5 9's service, 45 ms coast-to-coast, 24x7 customer support, 100/1Gbps/10Gbps with various DIR/CIR and burst rates. I'm shopping for new service and want to do better than choosing on reputation. (or, is reputation also a criteria?) Absolutely reputation should be a factor. I would argue that Internet access is largely commoditized anymore (and has been for several years), so the real differentiators are cost and level of service. jms
Re: Evaluating Tier 1 Internet providers
On Tue, 27 Aug 2013, Ben Hatton wrote: - time taken to turn around BGP import filter changes So much This... You don't realize how important this is until your nationwide provider takes 8 WEEKS to add one network to your (already set up and working for 20 other networks) peering. Then decides to charge you a fee for the change. I think after a week I would be tearing my account rep a new one, and then threatening to dump them as soon as the contract was up... 8 weeks? There is absolutely no excuse I would buy for that, though I might give style points if someone told me the dog ate the ticket or something... jms
Fwd: [newtech-1] Barclays wifi
From the NY tech meetup list. Any one here care to comment, off or on list? j -- Forwarded message -- From: Dean Collins Anyone know more about Barclay Wifi - http://www.fastcompany.com/3007452/innovation-agents/brooklyn-nets-barclays-center-slam-cam-puts-every-dunk-your-face ** ** Can they really stream hidef video to 19,000 devices simultaneously in hd via wifi? Surely they are hitting some spatial limits…..? (eg I know when my old company sold a DECT platform to the ASX we ran into bandwidth limits for the number of base stations in a single room) ** ** ** ** ** ** Cheers, Dean ** ** -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
RE: [newtech-1] Barclays wifi
Any idea of the data rate required per stream? Sent from my Mobile Device. Original message From: Joly MacFie j...@punkcast.com Date: 08/27/2013 8:14 PM (GMT-08:00) To: North American Network Operators Group nanog@nanog.org Subject: Fwd: [newtech-1] Barclays wifi From the NY tech meetup list. Any one here care to comment, off or on list? j -- Forwarded message -- From: Dean Collins Anyone know more about Barclay Wifi - http://www.fastcompany.com/3007452/innovation-agents/brooklyn-nets-barclays-center-slam-cam-puts-every-dunk-your-face ** ** Can they really stream hidef video to 19,000 devices simultaneously in hd via wifi? Surely they are hitting some spatial limits…..? (eg I know when my old company sold a DECT platform to the ASX we ran into bandwidth limits for the number of base stations in a single room) ** ** ** ** ** ** Cheers, Dean ** ** -- --- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -- -
