trout

Mistake seems like a harsh word here. There are lots of partners that aren't in the competency tier that do perfectly fine work. But we try to highlight the ones we can somehow quantify as 'top tier', which is competency. It's imperfect just like any other subjective rating.

AWS definitely cares about any bad experiences. It's the way we improve things for customers, so let us (or me, or anyone at AWS) know the details.

I've been on break/fix and on the Sales Engineer side and know both - there's never a single side to these things.

Sales Engineers in particular don't want to sell something dishonestly - it opens the company up to risk and it hurts their credibility, particularly if you sell multiple products.

There are a few reasons I can think of:

1. The technical people that run the current implementation didn't put their requirements into the sales process.

2. Some of those features really don't matter to the business and were fodder.

3. The requirements were listed, but not accurately or with enough depth.

4. The Sales team didn't have enough knowledge (or training) to know the difference - or inaccurate documentation.

5. It was roadmapped close enough to implementation and including delays to go ahead anyway.

6. The competitor claims to have this feature but theirs is broken also, so it's a race to who can sell broken stuff faster - because nobody can truly do it.

The people and the companies that support this exist certainly - just not for very long.

Skype pulls in a lot of revenue in the OCS/Lync product set. Companies want still largely want to be able to IM MSN, Yahoo, Skype, and AOL users and they're the only ones that have access to all those user groups. They also leverage B2C video/calls to Skype users.

Not a flame - your perspective is very typical for people that don't have a lot of experience with networking past the host or server level. (Very little experience with networking in the core, provider, or putting together network services architecture).

1. In theory the routing table with IPv6 can be smaller. The address design should be hierarchical, which means you should be able to have much fewer routes. It's too early to tell if this is actually true or not, but the addresses themselves are 4x larger - which isn't going to be the determining factor in routing table size.

2. Not everything needs to be publically routable, true. IPv6 has the idea of link local and autonomous system local addressing which IPv4 doesn't have. The RFC 1918 block was used instead. But think for a second - there's only 4 billion addresses (less when you count bogons and multicast ranges), and it's only a matter of time until those are taken up. So we can choose to do it now, 2 years from now, or 5 years from now, but devices are growing faster than ever and it's only a function of time.

3. NAT is not a security feature, is not good for the internet, and the sunk costs spent building an ALG for every protocol to work around it is a significant development sinkhole. It's a workaround often masqueraded as security, and does cause many application problems. It's just not normally the application developers that have to fix those problems - it's the network and security teams.

4. IPv6 was created in the late 90's. People have been waiting for brilliance to supercede IPv6 for a while. I'll admit it's not the easiest, but there are a certain set of problems you have when you expand the address space.

5. I'm familiar with all the IPv4 headers, and nearly all of them are used. ID is used for packet identification, particularly through network services, DSCP is used heavily, DF and other flags are used - they're just obscure. If you look at IPv6 those same headers are basically recreated, though with slightly different names. The ones that aren't included are addressable through the extension headers.

So, yeah. That's another perspective that may help you understand why IPv6 is a bit of a quagmire. The faster people understand this, the sooner we get to a place where the chicken-egg problem fades away.

If HN was on AWS, where would we go to discuss AWS outages?

Interesting, I'm at 1084 days so I missed a chance at a round-number-blog-post.

I would echo many of the same things. I graduated with a computer science degree (and computer systems engineering) but up until about a year ago I had not written a single program. I've started kicking around with Python again, have signed up for Coursera courses that involve Github, AWS, and programming. As well, it's helping me professionally because I'm gradually moving away from VoIP technologies into datacenter networking where Dev Ops, AWS, IaaS, and the latest programming trends are important. I got an Arduino and started hacking around with it as well.

Even though I'm not at a startup, I try to treat my job with the same type of entrepreneurial spirit as those touted in the Silicon Valley Startup Echo Chamber posts. I try to keep in mind many of the core entrepreneurial concepts - fail fast, iterate, A/B test, get feedback, focus on value, user experience is paramount, etc in mind with my comparatively tame 'cushy' corporate job.

So as much as anything else, thanks HN.

It applies if you want to switch schools. We used to call it "failing in".

I'm just hoping I'll be able to drink in a driverless car before I can use electronics in an airplane. If the same safety-at-all-costs model applies to driving these cars, they won't be nearly as fun as we dream.

How many of these P2P overlay networks could run without a centralized head/mapping server? BitTorrent has drastically reduced the size of theirs, but it still needs a mapping of other hosts somewhere. Same thing for Skype. I don't want to sign up for an internet where every connection needs a 'head' in order to determine how to traverse the overlay network.

It's probably also not a coincidence that Skype and Bittorrent are two of the hardest protocols to 'control' inside the network. This sounds good from a 'the internet should be a free democracy' standpoint but bad from a 'let's guarantee the performance of the application' standpoint. In terms of visibility into what is happening, being transferred, and where connections terminate there are more productive rather than draconian reasons for understanding those things.

Today with virtual hosting if the website next to you decides to host illegal content, the entire IP is taken down collateral damages or not. Well, that's part of your choice in choosing a provider as an end host. If the entire next generation internet and application space is based on overlays and other nebulous architectures, much of those same problems are going to exist to larger scales, including at transit points. Except it won't be as optional as changing hosting providers.

Since you've got BGP experience - think about the fun in troubleshooting eBGP neighbor problems when every connection is a GRE tunnel that may actually be tunneling through another BGP AS, which itself may be tunneled again. GRE tunnels are great immediate bandaids and generally awful long term solutions for enterprise networks to say the least. But the application guy gets his green light and thinks everything is great.