BCP38 is a fantastic idea. Being in a position in which I serve as a consultant to many indie-ISPs' network administrators on a frequent basis, I strongly encourage sane enforcement of source IP data at ingress-toward-the-ISP from customer-facing links. Many of my clients implement this. The trouble is, it doesn't help with many modern DDoS's. It certainly helps with the common traffic-amplification attack types, but many distributed bot-net based attacks now directly the target service by impersonation of legitimate client implementations. This will do nothing for those. The server side will see the many thousands or more of IPs that are attacking them, and see them correctly, but the trouble is, there are way too many to manage and they look like legit clients. Complicating things, it's likely that many of the infected machines ARE also LEGIT customers / clients. Implementing BCP38 is and will remain a good thing. But as DDoS strategies evolve, and upload speeds on consumer links increase in terms of throughput, this strategy not be a long term solution to many categories of DDoS.

Umm... No. Any such form of congestion notification, if respected by upstream parties, would certainly reduce traffic to you. The obvious problem, however, is that it will reduce NASTY/BOT traffic as well as LEGITIMATE traffic. So, you send this ICMP message, and the upstreams that hear it kindly shape what's exiting their network toward you? How do they choose from the available packets they have heading toward you what to let through and what to delay/drop? If some giant number N of senders wants to swamp you, it matters little that their ISPs or your ISPs or any transports between them know that they must reduce the traffic toward you. You still have a DDoS, but now it's a self-throttled DDoS, and the upstreams are still dropping or delaying legitimate traffic that you want, only now it happens before the natural limits and instead occurs upon artificial limits. The end result is less traffic hits you, and you still go out of service to most of the world (from the end-user experience perspective), because the senders who are politely throttling can't tell which packets are evil and which packets are sent by the people you want to receive from.

Agree -- and I totally meant to mention that as well. In fact, Opera Mini is a more on-point example than the Blackberry infrastructure, as with Opera Mini (at least some builds thereof) you similarly had no choice in keeping another server out of your web-browsing experience.

It's worth taking note that this is not a completely novel idea. The Blackberry web browser when running the Blackberry Internet Service has also used server-side resources of RIM's infrastructure to slice and dice and optimize web services. The same is true of email attachments -- the RIM infrastructure intercepts and re-optimizes. Especially apparent in viewing PDF attachments to email. In the Blackberry Enterprise Server infrastructure, this functionality actually moves to ones own BES server instance, with end-to-end encryption between the BES server and the handheld. This fact, at least, provides a corporation with the ability to not have the security exposure of having RIM decipher the pages and content. Perhaps the objection is that for Kindle fire we don't have an independently implementable server-side browsing optimization node?

I love that word pernicious... I've started naming all my servers after nasty p-words. pernicious, persnickety, pugnacious...