This one time, at band camp, Ian Jackson said: > I don't see a clear explanation of what the motivation is to switch to > a commercial CDN. Can you clarify ? That will help us understand > what we would be giving up if we decline to make this change. There are probably several having to do with effort and effectiveness, but I'll just share one story that's been ongoing. At debconf in Spain, I spoke with several people about the idea of putting in a security mirror in the vicinity of China. We are still talking about this, and users in China have made do with .. I don't know what in the meantime. Getting things closer to our users makes things nicer for them - time to first byte can be appalling when viewing our web page from some parts of the world, especially when on a mobile device. Time to first byte matters less when downloading large packages, but again, if we can get caching with large bandwidth, it's a better experience for the end users. I count at least a dozen d.o machines that are nothing but mirrors of one thing or another, and we still don't have very good coverage. There are lots and lots of subdomains (lintian, popcon, people, etc) that are in basically one place. That's a single point of failure, and also, half the time, on the far side of the world from our users. Sure, we could add more mirror machines, and we could make more and more mirror infrastructure and build our own CDN. At some point, though, it makes sense to me to say, "other people already do this really well". We can carry on the way we are, but I think we'll lose out on improving throughput for our end users, getting close to users in parts of the world that have been difficult for us to find hardware or hosting, and reduce the workload on DSA while making more services more available. I understand your concerns about privacy, although I think they are perhaps unrealistic. You're asking, in a world where security services tap uplink cables and passively record metadata about all traffic, for me to get upset about whether someone logs an IP or not. Once the transit is proven to be unsafe, the endpoints no longer matter, in my mind. That being said, I don't think that at least the first iteration of this should force anyone off of their preferred mirror. I don't think we want to rush into this, and I don't think we want to throw out all the work we've done already to make our home-brewed CDN. I think we can let them coexist for a while, and see how we do. We have had one report that someone gets better throughput off of their existing mirror than they do from one of the CDNs offering their support. If we get better coverage for a small number of users and worse coverage for most of our existing users, that's clearly not a tradeoff worth making. I guess what I'm saying is, I can see lots of ways that this can make things better. Right now, we don't have any metrics about the tradeoffs, all we have are emotional responses. I'd like to start trying, so we can collect those metrics and make an informed decision. We can always say, "thanks but no thanks" later, right? Cheers, -- ----------------------------------------------------------------- | ,''`. Stephen Gran | | : :' : sgran@debian.org | | `. `' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Attachment:
signature.asc
Description: Digital signature