Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comcast: Simulating shitty network connections so you can build better systems

github.com

Post reply on HN
Print view View original

81–87 of 87 posts

Re: Comcast: Simulating shitty network connections so you can build better systems

#81

Post by superuser2 »

api wrote: post #16

Nice. It'd be neat to include options to simulate other pathological conditions often encountered in the field like: - Multiple layers of NAT - overlapping un-synchronized timeouts are one thing ... but the REAL fun comes in when intermediate layers have the same IP ranges as IPs you are trying to reach on the "outside" of the NAT sandwich. All kinds of "interesting" things can happen, like the "software laser": http…

>WHYWHYWHYWHYWHY

Are there any network administrators who don't consider NAT traversal to be a security breach? Making it difficult would seem to be a feature, not a bug, in most enterprises.

Re: Comcast: Simulating shitty network connections so you can build better systems

#82

Post by api »

superuser2 wrote: post #81
api wrote: post #16

Nice. It'd be neat to include options to simulate other pathological conditions often encountered in the field like: - Multiple layers of NAT - overlapping un-synchronized timeouts are one thing ... but the REAL fun comes in when intermediate layers have the same IP ranges as IPs you are trying to reach on the "outside" of the NAT sandwich. All kinds of "interesting" things can happen, like the "software laser": http…

>WHYWHYWHYWHYWHY Are there any network administrators who don't consider NAT traversal to be a security breach? Making it difficult would seem to be a feature, not a bug, in most enterprises.

NAT traversal is a security breach that became a de-facto standard and is part of the SIP, STUN, and IPSec (extended) standards among other RFCs. It exists because NAT itself is an abomination.

Re: Comcast: Simulating shitty network connections so you can build better systems

#83

Post by FireBeyond »

jvehent wrote: post #57

I don't need this, I have comcast. $ sudo ping -i 0.02 8.8.8.8 [...] 64 bytes from 8.8.8.8: icmp_seq=578 ttl=53 time=15.5 ms ^C --- 8.8.8.8 ping statistics --- 579 packets transmitted, 364 received, 37% packet loss, time 13854ms rtt min/avg/max/mdev = 15.009/19.308/50.884/6.152 ms, pipe 2

Comcast Business connection in Olympia WA:

``` --- 8.8.8.8 ping statistics --- 538 packets transmitted, 530 packets received, 1.5% packet loss round-trip min/avg/max/stddev = 13.706/27.511/101.208/11.207 ms

Re: Comcast: Simulating shitty network connections so you can build better systems

#84

Post by akshatpradhan »

Spooky23 wrote: post #24
api wrote: post #16

Nice. It'd be neat to include options to simulate other pathological conditions often encountered in the field like: - Multiple layers of NAT - overlapping un-synchronized timeouts are one thing ... but the REAL fun comes in when intermediate layers have the same IP ranges as IPs you are trying to reach on the "outside" of the NAT sandwich. All kinds of "interesting" things can happen, like the "software laser": http…

My favorite enterprise network pathologies: - Randomly block specific ports "because security" - Limit RPC port ranges to some random small number. - Strange network optimizations. Example: Optimize TCP Window Size to support NT4 clients on 56k frame relay circuits. - Very Slow DNS response - Optimize core switching rules to fully utilize switch CPU. Avoid configurations that take place in an asic. - Long DHCP Leases…

What do you mean randomly block specific ports because "security"? All ports should be denied access except ports which have a justified business reason. Got a web app? The only thing open should be 80/443. There's no reason for SMTP to be open on the web server. Anything doing mail should be on its own MTA server. Least functionality per server. That's not even security. That's just good system administration.

Re: Comcast: Simulating shitty network connections so you can build better systems

#86

Post by Spooky23 »

akshatpradhan wrote: post #84
Spooky23 wrote: post #24

Earlier quoted context omitted.

My favorite enterprise network pathologies: - Randomly block specific ports "because security" - Limit RPC port ranges to some random small number. - Strange network optimizations. Example: Optimize TCP Window Size to support NT4 clients on 56k frame relay circuits. - Very Slow DNS response - Optimize core switching rules to fully utilize switch CPU. Avoid configurations that take place in an asic. - Long DHCP Leases…

What do you mean randomly block specific ports because "security"? All ports should be denied access except ports which have a justified business reason. Got a web app? The only thing open should be 80/443. There's no reason for SMTP to be open on the web server. Anything doing mail should be on its own MTA server. Least functionality per server. That's not even security. That's just good system administration.

At one of the enterprises that I've had the pleasure to work at, the network guys would randomly come up with some "concerns" about your firewall requests, and would just not include certain parts of your request.

So you might request ports 4000-4100, and find that 4007 is blocked, "because security".

I'm pretty sure the reality was that the firewall rules were a big hairball, and they were stepping in some other rule out in place a long time ago.

Re: Comcast: Simulating shitty network connections so you can build better systems

#87

Post by exelius »

api wrote: post #80
exelius wrote: post #70

Earlier quoted context omitted.

The problem isn't power (well it is; but that can be overcome), it's spectrum and pricing. Pricing: Most people in the US are charged for the data they use on their mobile devices, and thus would not want P2P used on their phone because it costs them money. Spectrum: P2P is not a very efficient distribution model in a world where most clients are on asynchronous connections. Asynchronous connections exist because tra…

P2P doesn't necessarily mean cooperative relaying or swarm distribution like BitTorrent. I agree that those applications are mobile-unfriendly with current batteries and cell networks. It just means you are talking directly to your peers instead of back-hauling to the cloud. You can have P2P where the only traffic you handle is your own. In that scenario total aggregate bandwidth shouldn't be that different from a cl…

If you're talking about P2P over cellular, I think it's just in general a bad idea. The way cellular networks are operated, you can't do device-to-device connections - they have to go through the tower for a number of (very good) reasons. That's where the latency comes in, and the wireless transmission latency can be an order of magnitude higher than the latency on a cross-country connection. Furthermore, the resource that is constrained is the amount of available spectrum - so we need to optimize for that. Bandwidth is effectively infinite from the tower to the cloud, but bandwidth from the tower to the device is the constraint.

P2P over non-cellular (i.e. Wi-Fi or Bluetooth) where you can actually make a direct device-to-device connection seems like it may have some use cases (messaging apps, etc.) But they're edge cases and by no means a common use case because it just isn't reliable enough.

Post reply on HN