No need to paint the male gender as a whole as being filled with sociopaths. It's just the law of large numbers at work. There's maybe 30 million American men in the age rage that are likely to pick up srange women; if just 1/10 % of them are sociopathic predators that's 30,000 predators; and since they *are* predators they'll be overrepresented in young women's encounters with men in pick-up scenarios. Small numbers can produce disproportionate problems. In this case it represents numbers the actions of such a small proportion of men that our ideas about how normal people act aren't a reliable guide.

Drink spiking is a very rare crime. Most studies that look for evidence of it find very little. The highest I found was a government study which found date rape drugs in 4.5% of the cases from four sexual assault clinics. Note this is 4.5% of the cases where the assault occurred, so we're not talking about 4.5% of encounters, we're talking 4.5% of rapes. 4.5% is certainly high enough to be a concern in certain situations, like residential parties at a college. In such a situation a date rape drug detector might actually have some utility, even though it addresses relatively rare actions by a tiny proportion of men.

A bigger concern than what we think of as a "date rape drug" is alcohol itself. The same study that found date rape drugs in 4.5% of sexual assault samples found alcohol in 55%. This result is consistently found across studies: alcohol is very frequently associated with sexual assault -- around half of the time. This is especially concerning because some people (men and women both) don't believe that surreptitiously incapacitating someone with alcohol in order to have sex is rape. They don't distinguish ethically between two people getting drunk and having sex and one of them slipping extra alcohol into a drink.

But the fact remains most men wouldn't do something like that. But that doesn't preclude the possibility that a woman might often encounter the few remaining men who would. A typical man has sex with a small number of women many times; a man who has sex with a large number of women only once is bound to be encountered by women disproportionately often.

It's one thing to blame Amazon and Google for a price war. But DropBox's pricing scheme was always overpriced. (And the same goes for Evernote -- even though theirs is a slightly different offering). What should cost a couple bucks a month is priced multiples higher.

Besides, DropBox has entertained MULTIPLE exit opportunities and rejected them all.

If they disappear now, they will have only themselves to blame for not choosing any one of the multiple exits that were on the table.

The landscape changed rapidly around the early leaders. And yet, those leaders did not change their models rapidly to match the changing landscape. Knowing when to quit, and how best to exit are essential parts of management. While we may applaud unbounded grit and unshakeable tenacity -- those qualities in a CEO are more frequently disastrous than beneficial.

Exactly. If you want to regard yourself as an engineer, you have to start by accepting you are working to serve the interests of the client, not your career. I've seen so many problems occur because programmers want to have a certain technology on their resume. And the sad thing is that it works to get them through the HR filter. If HR is told to look for experience with a particular technology, it doesn't seem to matter whether the candidate's experience with that technology is failure.

And your point would be?

You realize calling the Big Bang an "explosion" is a metaphor, right?

Except water vapor is the gaseous form of water; the plankton would have to be transported on individual molecules of water to reach the ionosphere.

If plankton were transportable in microscopic *droplets* in the troposphere as you suggest, a more plausible explanation is that the equipment was contaminated -- both the station itself and the gear used to test it.

Or he may have spent years building up a tolerance to iocaine powder...

I disagree. It means trust but don't rely entirely on trust when you have other means at your disposal.

Consider a business deal. You take the contract to your lawyer and he puts all kinds of CYA stuff that supposedly protects you against bad faith. But let me tell you: if the other guy is dealing in bad faith you're going to regret getting mixed up with him, even if you've got the best lawyer in the world working on the contract. So you should only do critical deals with parties you trust.

But if the deal is critical, you should still bring the lawyer in. Why? Because situtations change. Ownership and management change. Stuff can look different when stuff doesn't go the way everyone hoped. People can act differently under pressure. Other people working at the other company might not be as trustworthy as the folks sitting across the table from you. All kinds of reasons.

So you trust, but verify that the other party can't stab you in the back, because neither method is 100% effective. It's common sense in business, and people usually don't take it personally. When they *do*, then that's kind of fishy in my opinion.

Well, not just software costs. You may have to update the CAM more often. E.g. a change of nexthop for one prefix might demand that a compressed CAM entry has to be split up into several entries. Alternatively, it might mean several CAM entries can be consolidated into one. Next, you don't know how often that will happen - a prefix that just got compressed might get split quickly, and vice versa, or it might go back and forth a lot. So you could be doing a lot more updates to the CAM than otherwise. Whether that matters, I really don't know. :)

Ah, yes, of course, for the CAMs (or any other relevant longest-match index) you need to only store 64 bits at worst. Still, it's not the 5 fold saving.

The Cowen algorithm: Her original paper encodes landmark output ports in the label. That's not practical because of updating. However, with some added restrictions and at the cost of a slight amount of generality (e.g. not being able to work for every posssible graph, like pure star/hub-spoke graphs), you can eliminate that and have the addresses just be (landmark,node). You can do this by having nodes not build local clusters that are overly large, and so you can allow landmarks to also maintain local cluster routing tables - eliminating the output-port hack.

The (landmark,node) association need not change too often. Outages of links in the region between landmark and destination can be dealt with as they are today with routing - the scheme has full shortest-path routing in a region around each node. No need for the label to change. Outages that affect the path between the source and the landmark also similarly are dealt with like normal routing today. The one issue would be if there is a complete loss of a local cluster shortest-path route from the landmark to the destination. Then packets would disappear.

The end-node can at least be informed of this quite quickly, through the local cluster routing protocol (which can be a slightly modified BGP). Which is better than BGP today. Dealing with such issues of landmark redundancy, i.e., having associations with multiple landmarks, are perhaps better solved at a layer above the network layer. The theory shows that it is impossible to have both sub-linear routing tables AND full, global, shortest-path routing for /everyone/. If super-linear routing state is a problem you want to have solved, you have to give up something else.

Practice suggests that those who require redundancy at scale already seek to do so above the network layer. I.e. it is already good practice to locate redundant services on different prefixes precisely to guard against routing fsck-ups and failures. That suggests multi-homing in the "global prefix for one prefix" sense is not something that you should make too many other compromises for in any new routing architecture. Even with IPv4 which does do multi-homing for all to all, BGP multi-homing is not reliable enough to rely on. So it's probably better solved at the transport layer or higher, mediated at end nodes, and not complicate or compromise routing for it, as networks will still go and implement higher-layer redundancy anyway.

Indeed, by providing 2-way signalling in the routing layer, we can make the higher-layer redundancy solutions much better. Today if you advertise a prefix, you have no idea who has and has not received it, beyond your immediate neighbours. Even for your immediate neighbours, you still don't know if they have accepted the route. You can't really improve this in a routing system where all prefixes have global visibility, the communication and state costs would likely be unacceptable. However, in a Cowen Landmark routing scheme, we could at least provide an advertising node knowledge of which landmark nodes have working local cluster connectivity back to it. That's made possible because the scope is restricted, no longer global.

Note that the routing isn't source routing. Just because the address contains (landmark,node) doesn't mean the packet goes via the landmark. As a packet gets near to a landmark it may hit a node that already has the destination in its local cluster routing region, and so the packet goes shortest-path from there to the destination - potentially skipping the landmark. It's more two-stage routing, but each stage is shortest-path, per-hop routing. The 1st stage is routing the packet towards the landmark, the 2nd is when it hits a node with the destination in its local cluster (which, in the worst case, is the landmark).

On address sizes, that's a very interesting point about Teredo and 6to4. Yet another reason why IPv6 is too small. :) You should leave a comment on my blog!

If you're interested in this stuff, I'm trying (desperately ;) ) to finish writing up my PhD thesis on (slightly more) practical Cowen Landmark routing. Hopefully done really soon. I havn't considered the issues of source routing for Internet, but that could be very interesting too to consider, along with contrasting it with Cowen Landmark Routing. Designing a network layer to replace IPv6, in case IPv6 should fail at some point, would be interesting too! (Personally, where previously I laughed, now I think ISO OSI was right: addresses should be variable length, indeed maybe the solution is the ISO CLNS protocol ;) ). I can try ping you when I'm done with the thesis if you want. A comment on my blog would be easier for me to find back later. ;)

Oh, come on; everything's more futuristic in a geodesic dome.

You need to buy a dictionary.

I don't know if there are vendors who use this kind of compression to save CAM memory to be honest. On the one hand it saves memory, on the other it adds complexity.

On the last point, yes, be good to see more work on this.

Well, let's agree to disagree to on point 1. I do agree with you though, IPv6 will be less fragmented than IPv4, though I do also think there are processes besides de-aggregation in the face of address space pressures that cause fragmentation, and I think IPv6 will face those pressures too. IPv6 needs to be seriously used first, and it may also require time.

Next, IPv6 addresses are of course 4 times larger than IPv4 addresses. Even if your IPv6 routing table has 5 times fewer entries, you're not getting a 5 times saving in memory. You're only getting a 5/4 times saving or tables that are 80% of the IPv4 - nowhere near as dramatic.

I'd contend 2 is the real underlying problem. Routing tables growing with the size of the network, in terms of # of entries - even if not at all fragmented. In terms of overall size, it's O(NlogN), however given we're using a fixed-length address label, that logN factor makes itself known in quite big jumps, as illustrated in the previous paragraph. That 20% saving will be eaten extremely quickly if the Internet keeps growing at super-linear pace. Given so much of the world's population isn't yet online, there's every reason to think the Internet still has plenty left to grow. Even in the developed world, there's no reason to think the amount of address space used per person will not grow dramatically. The amount of network enabled devices each of us own just keeps growing. The "Internet of Things" is the current buzzword, looking at network-enabling many small devices. Granted, that won't directly increase pressure on routable bits where a site upgrades to v6 from an existing v4 connection, e.g. a person's home, however there are surely many use-cases that involve new distinct locations coming online (e.g. cars?).

IPv6 is just neutral on the routing scalability question. Reduced fragmentation seems a trivial saving, at least to me.

Worse, it is possible that IPv6 is actually too small to be able to solve routing scalability.

IPv4 has been around a lot longer, and has had a lot more real use and legacy concerns. Even if you got that 5× fold reduction in routing table sizes by switching everyone over to IPv6, then:

1. You won't *keep* that nice clean space. The same processes that led to IPv4 fragmentation, ex space, will start to affect IPv6: Mergers; ASes eventually running out of bits in their prefix, given enough time (and remember, we're talking routable bits - that's only 16 in a /48, a lot but not impossible to exhaust either, a /56 would be even easier to exhaust) and neighbouring prefixes no longer being available to allocate.

2. Say 1 is wrong, and v6 stays clean. Ok, you've got a 5 fold linear reduction compared to IPv4. However it still doesn't fix the problem that current Internet routing leads to O(N) routing tables at each AS in terms of number of entries (O(NlogN) in terms of total size), where N is the size of the Internet and N keeps growing at a fast rate - even if measured in # of ASes rather than # of prefixes. Certainly supra-linear, potentially exponential Internet growth to date, and we've still got much of Africa, China and India still to become rich enough to start using address space like we do in the developed world. That 5x linear reduction is, ultimately, a barely noticeable blip in the face of continued supra-linear, perhaps exponential growth of the Internet.

IPv6 doesn't fix routing table growth problems, at least not in terms of providing a mode change in how routing table sizes grow with respect to the overall network, because IPv6 does not fundamentally do anything to change how routing is done, in a way that could slow the mode of routing table growth.