IPv6, SSL, scheduled tasks, storage discounts & bulk bandwidth

We have quite a few feature announcements to bring you this holiday season. We’ve added support for several features, some of which have been requested for years like IPv6, SSL, and scheduled tasks (AKA cron jobs). We’ve also introduced new billing options that make our service pricing fairer and more scalable; these options will help a broad variety of our members save money.

IPv6 support for hosted sites

We’ve added IPv6 support for hosted sites. Just select the “Manage IPv6” action from the site info panel and enable it. Each site that enables IPv6 is currently assigned a unique IPv6 address. There is no extra cost for IPv6.

IPv6 isn’t fully deployed on the Internet yet, and consumer ISPs are the worst laggards, so IPv6 isn’t enabled by default and you may want to consider whether it’s right for you. More info is available in our UI.

SSL support

We always said that we would focus on SSL support as soon as IPv6 was done. And that’s just what we did. SSL support is now available in two forms.

First, you can obtain (or generate) an SSL certificate for any alias on your site, upload the certificate, the key, and the chain file (if applicable) to your site, and then request SSL be enabled for that alias through our UI. This is a great option if you want to secure traffic to your site for all visitors.

Second, generic support for securing the (shortname).nfshost.com alias of each site is available without the need for your own certificate. Use of this option is also requested through our UI, but it’s our domain name, so its use is subject to our pre-approval. (For example, we won’t be approving any sites with names like “securebanklogin.”) This option is good if you just want to administer your site through a web UI securely.

Our SSL implementation depends on the SNI feature of the TLS standard, which is now available in all modern browsers, so we are comfortable deploying it. SSL currently does not have any extra cost associated while it retains experimental status. It may get a nominal fee in the future to cover the added CPU cost of encryption once we get a better idea about how tightly we can pack certificates without causing problems.

Scheduled tasks

We’ve added the long-requested ability to run scheduled tasks on specific sites at regular intervals. Great for processing log files or refreshing content, scheduled tasks can be set to run hourly, daily, weekly, or monthly. There’s currently no extra charge for this feature, but we’ll keep an eye on the resources it uses.

Storage discounts and resource-based billing

Most people (including us) will acknowledge that for a long time, the greatest flaw of our service is that it bills a large amount of the cost based on how much disk space a site uses. This charge then pays for all the CPU and RAM it takes to host sites. This works well enough in terms of covering our costs, but forces sites that are very large to subsidize sites that are very small but resource-intensive. That’s not fair, so we’ve made two changes.

First, we’ve cut the storage charge for static sites, which by definition use few resources. Our published rate is $0.01 per megabyte per month, but with this change, static sites are now charged at $0.01 per 5 megabytes per month. That’s an automatic across-the-board 80% cut for all static sites.

Second, we’ve introduced a new option for dynamic sites called “stochastic billing.” If selected, this option cuts the storage costs for dynamic sites by 90% to $0.01 per 10 megabytes per month. In its place, it divides sites into groups and once per minute, selects a web request at random and bills the associated site for the resource usage attributed to that group. The likelihood of a given request being selected is proportional to the resources it uses, so over time the random sample converges to a very accurate representation of which sites are using which resources, and everyone who participates is billed fairly for the share of resources they used with a very high degree of accuracy.

We’ve set the pricing for stochastic billing in such a way that if everybody switched tomorrow, our bottom line wouldn’t change at all, so this is not a price increase. Most people will actually pay less. Sites that use above-average resources — the ones subsidized under the current plan by sites that use tons of disk space — will naturally cost more if they switch over. But we don’t plan to force anyone to switch. Instead, we intend to preserve both options and allocate to each the hardware resources it is paying for. Over the long term, we expect resource-heavy sites on the old plan will find fewer and fewer disk-heavy sites willing to subsidize them, which may lead them to resource shortages way down the road if they choose not to migrate and pay their own way. But we don’t anticipate any dramatic changes in the short term.

More information about this is available in our FAQ and our forum, and the option is available by changing your site’s server type in our member UI.

In the coming days, we’ll be adding a $0.01/10MiB/month + stochastic billing option for static sites as well. That’ll be better than the $0.01/5MiB/month plan for most but not all static sites, and we understand some people won’t want anything to do with a billing scheme with a random element, so it will be optional.

Bulk bandwidth option

One of the things we do that’s a little unusual is that we demand very high quality bandwidth for our member sites; there are a number of lower-priced providers commonly used by web hosts for connectivity that we don’t consider good enough. A consequence of this is that the bandwidth costs we pay are relatively expensive compared to some of our competitors of a similar size, and of course we pass that along. We feel it’s well worth it.

At the same time, we have wound up connecting to cheaper providers from time to time. This is not to serve member sites, but rather because cheaper providers — combined with clever routing and network management — can be a good way for us to soak off huge surges of incoming traffic associated with DDOS attacks without affecting the rest of our network. However, even though the bandwidth offered by these providers is relatively cheap, DDOS attacks consume a lot of it, and the more of it we have, the more resilient we are, so the overall bill is not trivial. And at the same time, DDOS attacks generate only inbound traffic, so we’re only using the inbound half of those connections (and then only when we’re being attacked).

So, we’ve got a bunch of unused outbound capacity. We’ve made the decision internally that the price/quality tradeoff is not worth using those connections for our regular traffic, but we respect that not everyone’s site is the same and that in light of the pretty significant cost difference, some people might prefer to make that decision for themselves.

As a result, we’re offering a new class of “bulk” bandwidth that will use our excess outbound capacity on a per-site basis. Instead of being priced per byte transferred like our regular offering, bulk bandwidth is priced per megabit per second (Mbps) per month. You select the amount you want and then pay $5.00/Mbps/mo. (But like most of the rest of our services, it is charged one penny at a time and can be added or removed at any time.) Your actual usage is unmetered. It’s also burst-able, meaning it groups sites together and if another site in the group isn’t using its share at any given moment, your site can borrow it at no extra charge.

Bulk bandwidth is typically best suited to sites that steadily use a lot of bandwidth, for example to distribute large files to the general public. Our regular bandwidth plan will still generally provide higher per-connection speeds, better routing and resiliency, and probably slightly better latency.

To determine if bulk bandwidth is right for a site, first figure out if it’s currently spending less than $5.00/mo on bandwidth under our standard plan. If it is, bulk bandwidth is a bad deal: pay more, get less. But if a site’s bandwidth costs more than $5.00/mo, the answer is maybe. Next, you would look at the nature of the site. If the priority is to deliver the most overall bandwidth per dollar, then bulk bandwidth might be a good choice. If the priority is to provide the fastest individual downloads, or if the site has significant interactive elements — particularly stuff like AJAX — it’s better to stick with the standard plan.

In short, the bulk bandwidth option is the freight truck to our standard plan’s sportscar. Both can move a lot of data very quickly, but in very different ways.

Final thoughts

Whew. Densest. Blog post. Ever.

If you follow our Twitter feed, you already know about these updates. But judging by the follower numbers, most people don’t, so we thought we’d mention it.

We think these changes are huge. They address a lot of the pain points that many of our members have been feeling for a long time, both in terms of features and cost. And they represent a mountain of work, especially these past few weeks to carry them over the finish line in time for Christmas.

Going forward, the biggest question will probably be about PHP 5.4. That’s the big one we weren’t able to make happen in time for this announcement. It remains available in Flex mode if you select the 2011Q4 realm, but 5.4 removes safe_mode support and hence there won’t be a “PHP 5.4 Fast.” Instead, “PHP 5.4 Full” is coming, which combines a lot of the best features of Flex (consistent paths, ability to execute external programs) with performance comparable to existing Fast sites. That’s our top feature development priority, and we’re keeping a close eye on the March 2013 timeframe that the PHP developers have announced for phasing out non-critical updates to PHP 5.3, but we can’t offer an ETA at this time. We also have some internal maintenance to do to keep things running smoothly and fix bugs.

Thanks everyone! We never lose sight that our incredible members make our service not just possible but everything it is. (And I allow myself a bit of a smug grin, secure in the knowledge that we have the hands-down smartest member base of any web host, which is the only reason we have the courage to do something as exotic as stochastic billing.)

(Updated 2012-12-26 to reflect that *.nfshost.com no longer uses a self-signed certificate for SSL.)

27 Comments

RSS feed for comments on this post.

1. What a wonderful Christmas present

   Comment by James Duffy — December 26, 2012 #

2. I’m excited about scheduled tasks and the stochastic billing. Thank you following through on all the long-term feature requests!

   Comment by cliff1976 — December 26, 2012 #

3. You mention the twitter account. I *do* follow it, and really appreciate the updates that have been posted lately.

   Question though: I know that you don’t respond to @ messages (and I get why, not questioning it) but do they get read? I ask, because I want to know if it is appropriate to @nfsn when something gets posted to say thanks for the update and such.

   If it isn’t appropriate, what is the best way for me to show my appreciation for the work that you are doing?

   I do rec this service to everyone who is even remotely thinking about hosting, because I figure it’s good for them and good for your business. But sometimes I just don’t think that’s enough.

   Comment by nix — December 26, 2012 #

4. Yes, we do read every @nfsn tweet. Not always right away, but usually within a day or two. We treasure member feedback (positive and negative) and I just wish we had the manpower to fully engage everybody in every medium in response. -jdw

   Comment by jdw — December 26, 2012 #

5. Thank you for the terrific updates. Keep up the wonderful work. (And please do not rely on Twitter for updates but do instead keep the blog up-to-date. Not all of us enjoy Twitter…)

   You can keep up on the Twitter feed from the “Minor Updates” page on our site or from our offsite status page. We’ll continue to blog significant changes like this, but the two media do serve different purposes and we try to use them accordingly. -jdw

   Comment by Tarsier — December 26, 2012 #

6. Thanks for all these changes, especially for static sites!

   I tried stochastic billing on my site which uses SSI, but in 24 hours had run up nearly a dollar in Resource charges where the storage & bandwidth charges combined are usually less than 15 cents.

   Is this because no-one else had adopted stochastic billing at that time so I got an unusually high share of RAUs allocated? I learned about global editing and did away with SSI instead. 😉

   We did make a change a day or two after we first enabled stochastic billing to account for initially allocating too much to it. Currently sites in stochastic billing are running an average of about $0.10/day. -jdw

   Comment by Richard G — December 26, 2012 #

7. These updates and Christmas got me to finally register a domain name. Thank you.
   I also “follow” the Twitter account, but from the Minor Updates link in the Support tab. Just one thing: why’s the font size of the timestamps on that page 20%? I can’t read text that’s three pixels high.

   It’s because we don’t think they’re very important. 🙂 -jdw

   Comment by tripwire — December 26, 2012 #

8. Why don’t you get a certificate from StartSSL. They will not give you a hard time about the yellow-pages problem and once you have an account, you can generate as many certs as you want for free.

   That’s for individuals. Corporations and wildcards go through a process not dissimilar to what we’re wading through and there are also some concerns with their policy of not obtaining certificates for others vs. our use of the wildcard domain. StartSSL is a great choice for our members who want free SSL certificates to use with their own domain though. -jdw

   Comment by Yehuda Katz — December 26, 2012 #

9. […] just saw this blog post from NearlyFreeSpeech.NET. I love being a customer of this company — they are happy to host […]

   Pingback by My favorite cheapo web host probably just got cheaper! | Regensblog — December 26, 2012 #

10. We finally won the “yellow pages” battle and names in nfshost.com approved for SSL have a proper certificate instead of a self-signed one. -jdw

    Comment by jdw — December 26, 2012 #

11. Have I missed something in the web ui to turn SSL on? Or is it still being rolled out?

    (PS. Thanks so much for these updates!)

    Comment by fowl — December 27, 2012 #

12. SSL is set up using a free assistance request under “Support Options” on the support tab.

    Direct link.

    -jdw

    Comment by jdw — December 27, 2012 #

13. This is a very timely rollout. I’m working on a project that requires scheduled tasks, and had been looking into alternatives for hosting it. Now I don’t have to. Rock on! This service is the best!

    Comment by Ryan Ballantyne — December 28, 2012 #

14. Great stuff! Now we can do website admin from our browser a bit more safely. Love the cron jobs too. I was considering migrating away from NFSN, but I will stay now. Cheers!

    Comment by Rick Hanson — December 29, 2012 #

15. Well done!

    I love NFSN for many reasons, but basically for its deep technical knowledge and inclination for best practices, but the lack of cron jobs was something I just had to bear, but didn’t like.

    Keep up with the good job.

    Comment by Carles Andrés — December 30, 2012 #

16. Very excited to hear about Cron jobs. I’m looking forward to moving another site here shortly.

    Cheers!
    Landon

    Comment by Landon Winkler — January 1, 2013 #

17. When you say to decide if IPv6 is best for you, does that mean it’ll turn IPv4 off when you enable it?

    Comment by Aaron Mason — January 3, 2013 #

18. No, your choices are IPv6+IPv4 or IPv4 only. There is no “IPv6 only” option.

    -jdw

    Comment by jdw — January 3, 2013 #

19. Thanks, that clears it up. I inferred from the wording that enabling IPv6 would disable IPv4.

    Comment by Aaron Mason — January 3, 2013 #

20. Is it possible to produce a basic tool to estimate whether you’d save anything by switching a certain site over to stochastic billing? Is your aim to have many people move over to this model?

    Comment by turkeyphant — January 9, 2013 #

21. The UI already shows a daily average of resources used. To get an estimate of the impact of switching, you can figure out how much that would cost, then compare that to 90% of what you currently pay for storage and see which figure is larger.

    Many people are already moving over to the stochastic billing model. It’s both fairer for everyone and cheaper for a whole lot of people, so its early popularity is neither a mystery nor a surprise. That is only likely to increase once we document it on the public site and make it a selectable option at site creation. We think everyone should switch.

    But we understand that some people with sites for which “fair” equals “more” may prefer not to switch as long as other members are willing to continue subsidizing their usage under the old model. And a few people may be too uncomfortable with “random” and “billing” in the same sentence to ever switch, no matter how good the math is. So we don’t plan to force any changes.

    -jdw

    Comment by jdw — January 9, 2013 #

22. Shiny. Thanks! The stochastic billing looks pretty awesome.

    A few brief comments/suggestions, if that’s no too much trouble:

    1. Thanks for adding SSL. Major bonus.

    2. It would be nice if, at some point in the future, a user could configure which ciphers they’d like their site to support. (I’m not sure if you can do this on a per-site basis.)

    3. I also really appreciate that you have ephemeral Diffie-Hellman key exchange enabled for SSL-enabled sites. This provides perfect forward secrecy and is a Big Deal that’s often overlooked, so thanks. You may also want to see if the current versions of the software you’re using supports Elliptic-Curve DH key exchange (Google uses this and it cuts back a bunch of resource usage on the server). If so, that’d be great if such ciphers were also available. If not, well, one can wait until the next upgrade. 🙂

    4. When you upgrade eventually to Apache 2.4, it’d be nice if OCSP stapling was enabled (or an option) as it can increase performance for users of SSL-enabled sites (and doesn’t have any real penalty for the site or host itself).

    5. Your *.nfshost.com certificate is not installed correctly: you do not have the appropriate Thawte intermediate/chain certificate installed. This should be fixed or it can cause errors for users of *.nfshost.com secured sites.

    Thanks again!

    Comment by Pete S. — January 13, 2013 #

23. 2. We cannot currently allow people to specify ciphers on a per-site basis.

    3. Yes, we were able to enable ECDHE support. TLSv1.1 eludes us, however. Renders a wide swathe of browsers unable to connect for some reason. But you should be able to get AES_256_CBC, with SHA1 for message authentication and ECDHE_RSA as the key exchange mechanism now.

    4. We were also able to enable OCSP stapling, although it’s only of limited value when virtually every certificate requires a chain.

    5. We are definitely providing the Thawte intermediate certificate for *.nfshost.com sites. What I did find was that if you hit the server without using SNI, you were getting that certificate as the default with no chain. That’s been corrected; thanks for pointing it out.

    -jdw

    Comment by jdw — January 13, 2013 #

24. Reply to jdw’s above message.)

    2. Drat. Oh well. 🙂

    3. Shiny. ECDHE is a useful thing to have enabled as it’s more CPU-efficient than standard DH.

    3a. You mention that your SSL endpoint is separate from the webservers themselves so it’s unlikely to be running Apache. Does it support DH parameters >1024-bit (that’s the default for Apache and they don’t let you use longer parameters but your endpoint might)? Just curious, as that’d then become the “weak point” (of course it’s unlikely that anyone would attack the crypto itself and would go for application-level attacks, but still).

    4. Awesome. It still saves on one query back to the CA, so that’s a plus. 🙂

    5. Aha! That would do it. I figured you guys would set things up right and was puzzled as to why it was broken in that way. I’m glad you fixed it and am impressed that you did it so quickly.

    -Pete

    Comment by Pete S. — January 13, 2013 #

25. Don’t be too impressed. Before we realized what you were seeing and why, hours were spent staring dumbly at the config trying to figure out why the chain certificates were being so blatantly ignored. 😛

    The SSL endpoint is Apache 2.4; I believe you are correct that the DH parameters aren’t adjustable. (And also that it’s not the end of the world — yet — that they aren’t.)

    -jdw

    Comment by jdw — January 13, 2013 #

26. Heh. Sorry about causing mass confusion!

    Also, it seems like the current setup is now only TLS 1.0 and didn’t have the SSL 3.0 it had a few hours ago. I assume this is intentional (pretty much any client that doesn’t support SNI won’t support TLS 1.0, so it’s not a big deal yet). Is that intentional (for example, is it required for ECDHE?) or did that accidentally get disabled? Or, potentially more likely, I’m hallucinating and didn’t see SSL 3.0 being enabled before.

    Just some quick clarification: on the Submit Assistance Request page for enabling SSL, one line reads “Because certificates are typically licensed for use only on a single host, SSL has an additional single point of failure that our regular hosting does not.”

    What is meant by this? Is there only one, non-load-balanced SSL endpoint for all of NFSN (or a single member site) or is it just an informational warning about the licensing of certain certs?

    Is the normal reverse-proxy/load-balancing done for SSL-enabled sites or only non-SSL-enabled sites?

    I totally understand that the SSL is offloaded to one or more SSL endpoints and I understand if this introduces a single-point-of-failure, but I just want to be sure that’s what it actually means.

    Comment by Pete S. — January 13, 2013 #

27. The SSL endpoint for any given site is a single point of failure for that site’s HTTPS access, because our system makes the good but not perfect assumption that the site’s certificate is only licensed for use on one endpoint.

    SSL 3.0 was dropped while we were testing TLS 1.1, not in relation to any of this. We had some test clients failing due to the number of ciphers offered, and SNI only works with TLS anyway, so it seemed pointless to negotiate connections that are doomed to fail anyway. I’m not sure there is any https-capable stack anywhere that is currently supported by its developer and can do SSL 3.0 but not TLS 1.0.

    -jdw

    Comment by jdw — January 13, 2013 #

Sorry, the comment form is closed at this time.