Definition of "transfer" and pooling period?

    Posts: 4
    Member since: Jan 19
    Contact:  

    The features page says:

    Bandwidth pooling

    Use your bandwidth allowance across your entire cloud. Pay for only the bandwidth you use.

    An early blog post clarifies this as actually referring to data transfer allocation:

    you can use your combined data transfer allocation across all your instances

    Actual bandwidth does not appear to be specified, beyond the fact that the internal network is 10GbE and there are multiple Tier 1 connections; but I recorded 48.15Mbps in and 108.36Mbps out over a five-minute period on a Large instance, so presumably the badwidth available to an instance of this type is at least 200Mbps.

    There are however a few things which are unclear:

    • What is the definition of "transfer"? Bytes in, out (like AWS/Azure/Google), the max of in and out (Vultr), or the sum of in and out (LeaseWeb)? If it is credit-based, do you get credits for each direction that only apply in that direction; or do they apply to both?
    • On what period does the pooling operate? If I start a Large instance early in a month, then convert to Extra Small, is the Large transfer allocation added on a per-minute basis as "credit" available for use by Extra Small later in the month; or does pooling only operate across instances active during the same minute? (Or hour? The billing is listed per hour, but I saw that instance creation and termination is recorded to the minute.)
    • Does transfer between instances count? If not, over which interfaces must transfer take place for it to be "free"?
    • If you upgrade an instance during a month, does it gain credits such that it could potentially reduce or eliminate the cost of a surplus incurred earlier in the month?

    Greater clarity here would be helpful for planning purposes, as it could be the difference between the standard charge of $5 or a surcharge of $10 (1000 * $0.01/GB) -> $15 for an Extra Small instance using 1TB both in and out.

    Laurence "GreenReaper" Parry

    WikiFur - Flayrah - Inkbunny

    5 months ago
    Posts: 20
    Member since: Dec 16
    Contact:  

    Hi GreenReaper, thanks for your questions. I'm happy to answer as best we can. However I'd like to make very clear at the start:

    We currently don't even monitor this! We have some internal tools that monitor our overall connection usage and if this suddenly jumps we'll likely start manually having a look at those customers, but unless that is triggered, it really is a soft limit.

    That said, we do have a specification for how this will work (and it was due to be being started this week, up until another priority bumped it down the list again), so I can answer from the point of view of that specification.

    GreenReaper wrote on 9 May 2019 at 14:48:52
    Actual bandwidth does not appear to be specified..., so presumably the badwidth available to an instance of this type is at least 200Mbps.

    We currently have a 1Gbps uplink to the internet, this is currently being upgraded to a 10Gbps connection to some parts of the internet (some exchanges aren't running 10Gb yet, so it won't be entirely 10Gbp everywhere).

    The bandwidth available to all instances is the same, larger instances don't get a higher throughput connection.

    What is the definition of "transfer"? Bytes in, out (like AWS/Azure/Google), the max of in and out (Vultr), or the sum of in and out (LeaseWeb)? If it is credit-based, do you get credits for each direction that only apply in that direction; or do they apply to both?

    The way it will work is based on the total transmitted and received bytes on the pseudo-public interface within a month.

    On what period does the pooling operate? If I start a Large instance early in a month, then convert to Extra Small, is the Large transfer allocation added on a per-minute basis as "credit" available for use by Extra Small later in the month; or does pooling only operate across instances active during the same minute? (Or hour? The billing is listed per hour, but I saw that instance creation and termination is recorded to the minute.)

    The pooling operates effectively using credits for the time those instances are running. Let's say you launch a Large instance with 8TB of transfer. You keep it running for 14 days (so half of a paid month) so you have 4TB in the bank, you only used 1TB on that instance so you have 3TB remaining in the bank for that month to be used by your other instances if they go over their allocation. This is on an hourly basis. We record based on the minute, but charge by the hour.

    Does transfer between instances count? If not, over which interfaces must transfer take place for it to be "free"?

    As per the blog post above about our network configuration, if you connect to another instance on the private network (10.x.x.x) then it won't be counted. If you connect to another of your instances over the 172.16.x.x network then that will be charged because OpenStack doesn't give us separate states per source, only for the network it comes over.

    So if you launch a DB server and have it listening on 10.0.0.1 (for example), and your webserver uses that IP instead of it's public IP (or pseudo-public IP), then communication between them will not take up any of the allocation.

    If you upgrade an instance during a month, does it gain credits such that it could potentially reduce or eliminate the cost of a surplus incurred earlier in the month?

    As a weird quirk, the way upgrades work is that it effectively is seen from a billing point of view as one instance stopped and another of the new size started (the fact that in reality it's the same instance with the same files on disk doesn't matter, we're talking from a billing point of view). Therefore the regular situation applies, the smaller instance will contribute it's pro-rata'd per hour amount of transfer to the bank and when it's upgraded it will from that moment start contributing it's larger pro-rata transfer amount.

    Greater clarity here would be helpful for planning purposes, as it could be the difference between the standard charge of $5 or a surcharge of $10 (1000 * $0.01/GB) -> $15 for an Extra Small instance using 1TB both in and out.

    An XS, on its own, using 1TB in and 1TB out on the pseudo-public/public interface would be liable to an overage charge of $10.

    Hope this helps make things clearer, if you have any more questions - please comment back and I'll try to answer them as best as I can.

    Last edited May, 9th at 16:03

    CTO, Civo

    5 months ago
    Posts: 4
    Member since: Jan 19
    Contact:  

    Thanks for the information, which does indeed help to clarify the situation, and to make plans going forward. As an administrator, I don't mind paying for what I use; I just want to know what the cost is likely to be in advance - no alarms and no surprises, please! 😸

    One thing I'd suggest for when you start monitoring is a clear indication of acount transfer usage on the dashboard; and ideally an estimate of any expected overage, based on average usage in the month to date (or maybe over the last X days?), assuming that currently-running instances remain for the remainder of the month. You could even use this method to suggest an upgrade, offering a comparison of expected costs one way or the other, though this might be over-engineering it a bit.

    Laurence "GreenReaper" Parry

    WikiFur - Flayrah - Inkbunny

    5 months ago
    Posts: 20
    Member since: Dec 16
    Contact:  

    GreenReaper wrote on 9 May 2019 at 16:45:40
    Thanks for the information, which does indeed help to clarify the situation, and to make plans going forward. As an administrator, I don't mind paying for what I use; I just want to know what the cost is likely to be in advance - no alarms and no surprises, please! 😸

    I completely understand.

    One thing I'd suggest for when you start monitoring is a clear indication of acount transfer usage on the dashboard; and ideally an estimate of any expected overage, based on average usage in the month to date (or maybe over the last X days?), assuming that currently-running instances remain for the remainder of the month. You could even use this method to suggest an upgrade, offering a comparison of expected costs one way or the other, though this might be over-engineering it a bit.

    We're definitely planning on having a clear indication of the dashboard of usage vs pool.

    I hadn't thought of the pricing when considering just paying for bandwidth over upgrading/adding instances. We'll have a think about that internally, so thanks for raising it.

    Post liked by GreenReaper

    CTO, Civo

    5 months ago