[WXC/VFX] The Torrent plan and what it's done...

Forums › One New Zealand (including Vodafone, WxC, Farmside) › [WXC/VFX] The Torrent plan and what it's done...

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ... | 23

3539 posts

Uber Geek

Trusted

#167166 25-Sep-2008 20:52

insane: At the end of the day, most xnet users are perhaps getting the cheapest prices in the industry, when you buy a Dihatsu you cant expect ferarri performance.

Opportunity for xnet to launch lowish capped plans with $2/gb with seporated bandwidth with the ability to also use any spare from the normal pool?

I really have no idea as to the ramifications of such a scheme, but from a layman's perspective, I guess it must greatly complicate things for an ISP so far as network management is concerned. Otherwise, surely there would be a stampede to offer multi-tiered plans with QoS being the differentiator.

Nevertheless, it's an excellent idea which bears looking into if ISPs want to retain Low Data / High Value customers.

As SimonM says above, I would gladly have paid several $ per GB, just to ensure that the performance was there when I needed it.

For example:

My new ISP is NetSpeed and by the looks of the Speedtest result, they wholesale bandwidth from Snap.

$69.95 per month gets me a wireless connection with 1Mbps down / 340kbps up and a 2GB data cap.

2GB is plenty for my needs, and in the past 12 months I have only exceeded it on one occasion by 250MB or so. Xnet would have charged me 25c for the privilege, whereas NetSpeed would charge me $2.50.

Whatever, it's a very small amount of money compared to the monthly plan cost but the important thing is that the bandwidth is there when I need it.

Just now I did a Speedtest to LA:

Compare that with one I did this afternoon:

As you can see, there is virtually no difference

Some will say that Speedtest results are meaningless and to some extent I agree. That is why I also measure YouTube throughput as an alternative benchmark:

2pm 25/9/08 One YouTube stream 380kbps Two YouTube streams 759kbps

8pm 25/9/08 One YouTube stream 390kbps Two YouTube streams was around 700kbps
However, a small amount of buffering was observed on the stream that started after the first one had begun.

As you can see, the YouTube test is more demanding than Speedtest. What it is telling me is that at 8pm -- which is Peak Time in anyone's language -- Snap/NetSpeed are providing around 700kbps of International Bandwidth to my connection which is using 2 x Flash Video streams simultaneously.

I think that's pretty damned good

Talkiet

4792 posts

Uber Geek

Trusted

#167171 25-Sep-2008 21:17

[snip]As you can see, the YouTube test is more demanding than Speedtest. What it is telling me is that at 8pm -- which is Peak Time in anyone's language -- Snap/NetSpeed are providing around 700kbps of International Bandwidth to my connection which is using 2 x Flash Video streams simultaneously.

I'm glad it's working out better for you - but it's unfortunately not true. There's no way their business model is predicated on providing 700kbps to you at 8pm. What it does mean is that because of their higher cost for additional data (and hopefully you are not sharing a bandwidth pool with users that pay a small or no amount for overage), their network doesn't have indiscriminate users.

This in turn means that while they'll still have some periods of congestion, they are likely to be MUCH shorter and less frequent. In the order of seconds or maybe minutes, instead of in a solid block from midnight to 8am.

That said, it still sounds good - and I'm on the lookout for a new ISP so I have added your snap.net test to my list of things to consider.

Cheers - Neil G

Please note all comments are from my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

grant_k

3539 posts

Uber Geek

Trusted

#167177 25-Sep-2008 21:25

Talkiet: I'm glad it's working out better for you - but it's unfortunately not true. There's no way their business model is predicated on providing 700kbps to you at 8pm.

Yes, good point Neil

Obviously I can not expect to have 700kbps of International Bandwidth reserved exclusively for my use. At least, not at the price I'm currently paying

Rather, I live in the hope that at least 400kbps will be available when I need it, and so far, Snap is living up to that promise. We also use them to provide an ADSL connection at our Auckland house and I have never had trouble playing YouTube videos at night there either.

insane

3236 posts

Uber Geek

ID Verified

Trusted

#167201 25-Sep-2008 22:29

700kbps is not much to scream about for peak times.... I checked today on my Maxnet connection (they recently bought another chunk of int bandwidth and shuffled business and residential users around a little across their three upstreams)

my residential connection was getting full line speed (4mbps) during their peak time which is during business hours for them and getting full line speed again during the evenings obviously which is non-peak.

unfortunatly its like $10 for every 2GB you use over your cap :(

I'm going to give xnet a chance to sort things out as they have over the years given mea good deal I feel..... but if things continue I'll have to change my home connection to a ISP that better suits my individual needs.

grant_k

3539 posts

Uber Geek

Trusted

#167204 25-Sep-2008 22:37

insane: 700kbps is not much to scream about for peak times....

I know

But when you've been suffering from 200kbps or less for the past 6 months, it's just pure bliss

morganiser

6 posts

Wannabe Geek

#167207 25-Sep-2008 22:59

Hmmm... well to me it seems reasonably simple.

- if you (for whatever reason) like to browse the interent between 12 and 8am then join up with another ISP. (and join the queu's waiting on hold for service, then get treated like a number. - we've all been there, personally, I've had enough)
- tolerate the status quo, perhaps hoping for an improvement sometime

Remember xnet is a business, so while the numbers of torrent users signing up are greater than the number of moaners leaving they can write off the customer losses.

To me the good about xnet outweighs the bad and the alternatives are bleaker - but if there was a better option fro an ISP I would change.

Ragnor

8218 posts

Uber Geek

Trusted

#167212 25-Sep-2008 23:31

I have the feeling several people in this thread so far don't understand the difference between kilobit/second and kilobyte/second

For example: 200 kilobit/second is around 25 kilobytes/second

Equinox IT

Cloud spending continues to surge globally, but most organisations haven’t made the changes necessary to maximise the value and cost-efficiency benefits of their cloud investments. Download the whitepaper From Overspend to Advantage now.

Talkiet

4792 posts

Uber Geek

Trusted

#167214 25-Sep-2008 23:35

Ragnor: I have the feeling several people in this thread so far don't understand the difference between kilobit/second and kilobyte/second

For example: 200 kilobit/second is around 25 kilobytes/second

For the record, I have assumed all values to be accurately named as kilobits/sec... So no provider can budget 700kbits/sec, 400kbits/sec or even 100kbits/sec as an amount of bandwidth to dimension for users...

Cheers - N

Please note all comments are from my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

PenultimateHop

637 posts

Ultimate Geek

Trusted

#167223 26-Sep-2008 01:25

Talkiet:
Ragnor: I have the feeling several people in this thread so far don't understand the difference between kilobit/second and kilobyte/second

For example: 200 kilobit/second is around 25 kilobytes/second

For the record, I have assumed all values to be accurately named as kilobits/sec... So no provider can budget 700kbits/sec, 400kbits/sec or even 100kbits/sec as an amount of bandwidth to dimension for users...

For what it's worth, most telco/large ISP networks are dimensioned around 50Kbit-150Kbit/s average bandwidth per subscriber. Generally in the lower end of the spectrum (most AsiaPacific telcos/ISPs I have worked with it's less than 90Kbit). Since that's per subscriber loop, you may find it is even lower for international transit (say 20-30Kbit).

Note this works well when you are statmuxing across large numbers of endpoints. If your subscriber numbers are low, you will have problems... which most NZ ISPs seem to be experiencing. There are a lot of mitigation tactics for this though.

grant_k

3539 posts

Uber Geek

Trusted

#167254 26-Sep-2008 08:48

Talkiet: For the record, I have assumed all values to be accurately named as kilobits/sec...

Yes, all values quoted in my posts are kilobits per sec. hence the small b.

Talkiet: So no provider can budget 700kbits/sec, 400kbits/sec or even 100kbits/sec as an amount of bandwidth to dimension for users...

Yes, I think many people would realise that. In practice it's more likely to be in the 20kbps to 90kbps range as mentioned by PH above.

To Exclusively Reserve bandwidth per user -- also known as CIR I believe -- is where the charges get very expensive i.e. well outside the reach of residential customers and more into the province of larger businesses or carriers.

What I am talking about is the ability to Burst your bandwidth when needed e.g. to play a YouTube video. The rest of the time when you're not doing that, the bandwidth is sitting idle and can be used by someone else.

Ragnor

8218 posts

Uber Geek

Trusted

#167344 26-Sep-2008 13:41

PenultimateHop:
Talkiet:

For the record, I have assumed all values to be accurately named as kilobits/sec... So no provider can budget 700kbits/sec, 400kbits/sec or even 100kbits/sec as an amount of bandwidth to dimension for users...

For what it's worth, most telco/large ISP networks are dimensioned around 50Kbit-150Kbit/s average bandwidth per subscriber. Generally in the lower end of the spectrum (most AsiaPacific telcos/ISPs I have worked with it's less than 90Kbit). Since that's per subscriber loop, you may find it is even lower for international transit (say 20-30Kbit).

Note this works well when you are statmuxing across large numbers of endpoints. If your subscriber numbers are low, you will have problems... which most NZ ISPs seem to be experiencing. There are a lot of mitigation tactics for this though.

No where did I say that ISP's should budget 700 kbit/sec per active user. However many people are able to achieve those kinds of speeds sustained in peak time by using bit torrent at the expense of other users because bandwidth is not allocated equitably between users by Xnet.

Remember with bit torrent we're talking hunderds of tcp/ip connections vs web browsing/email/gaming/voice comm probably using less than 10. I am not against bit torrent, in fact I use it to get game patches, trailors and so on quite often.... the problem here lies in that my 1000 tcp/ip connections via torrenting can suck up much more than a fair share of bandwidth adversly affecting other users because there is no per User QoS in play,

Ragnor

8218 posts

Uber Geek

Trusted

#167352 26-Sep-2008 14:04

grant_k:

To Exclusively Reserve bandwidth per user -- also known as CIR I believe -- is where the charges get very expensive i.e. well outside the reach of residential customers and more into the province of larger businesses or carriers.

What I am talking about is the ability to Burst your bandwidth when needed e.g. to play a YouTube video. The rest of the time when you're not doing that, the bandwidth is sitting idle and can be used by someone else.

We are not neccesarily talking about an exlcusive reserve, just a more equitable division of available bandwidth between active users would be a positive change.

The tech to do this sort of stuff exists now, it's cheaper than deep packet inspection and it's starting to be used in ISP's and universities overseas.

I highly suggest a quick read of this blog article about how p2p systems exploit the tcp/ip protocol to increase it's bandwidth share and adversely affect regualr single connection traffic if you don't understand what I'm complaining about.

Fixing the unfairness of TCP congestion control

insane

3236 posts

Uber Geek

ID Verified

Trusted

#167357 26-Sep-2008 14:16

PenultimateHop: Since that's per subscriber loop, you may find it is even lower for international transit (say 20-30Kbit).

Obviously this is a very closely guarded secret, but I know that most residential isps in NZ offer lower than 20kbps int to each cusomer.

but I guess its all irelevent if the bandwidth is not shared/managed correctly between users

grant_k

3539 posts

Uber Geek

Trusted

#167385 26-Sep-2008 15:13

Ragnor: I highly suggest a quick read of this blog article about how p2p systems exploit the tcp/ip protocol to increase it's bandwidth share and adversely affect regualr single connection traffic if you don't understand what I'm complaining about.

Fixing the unfairness of TCP congestion control

That was a good read, Cheers Ragnor.

I especially liked this bit:

I could imagine a fairly simple solution where an ISP would cut the broadband connection rate eight times for any P2P user using the older TCP stack to exploit the multi-stream or persistence loophole. It would be fairly simple to verify whether someone is cheating with an older stack and they would be dropped to much slower connection speeds. For the vast majority of people who aren’t using P2P, they would continue getting the higher connection speeds regardless of whether they update to a weighted TCP stack or not because they never use the multi-stream or persistence loophole to begin with. For P2P users running a weighted TCP stack, they get to download as much as they like at maximum burst speeds because their TCP implementation will politely back off for short bursts of time when single-stream and non-persistent users are trying to use the network.

This sort of bandwidth policy would create the necessary incentives for P2P users to implement a fairer and more polite TCP mechanism. Users can opt to continue exploiting the multi-stream and persistence loophole but they’re making a choice to live with much slower connection speeds. Normal users regardless of whether they implement a newer weighted TCP stack will get a much higher and fairer share of bandwidth because the bandwidth hogging P2P users will either be operating at much slower speeds or they’ll be much more polite.

This would be a totally voluntary system where the ISP will no longer need to single out any specific protocol for bandwidth hogging so there can’t even a hint of impropriety. But without this fundamental fix in TCP congestion control, ISP have no choice but to specifically target P2P applications since those are undeniably the applications that hog the network. Ultimately, it is in everyone’s best interest to hear out Bob Briscoe’s proposals. At the very least, I think we can all agree that the current system is broken and that we need a TCP implementation that treats individual users and not individual flows equally.

It addresses the situation where P2P users with existing TCP/IP stacks would not otherwise want to change to the new Weighted stack.

Makes an awful lot of sense to my way of thinking.

linw

2849 posts

Uber Geek

#167513 27-Sep-2008 16:43

Thanks, Ragnor, for the link to that article. Now I REALLY understand why ISP's and their non p2p customers are being stomped into the ground.

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | ... | 23