 shepd
join:2004-01-17 Kitchener, ON
·TekSavvy Solutions..
| reply to jfmezei Re: Upgrades... What's next...
said by jfmezei :Consider that Bell would be aware that MLPPP bypasses their satanic boxes. Mr/Mrs Deadpool would have told Bibic about it, and I suspect that the message would have been "a small group of geeks at one ISP found a way around our thorttling, we could stop them, but probably not worth the effort". I bet it is more like "If it's tough enough only the seriously upset do it, and the most upset complain the most, then we have taken the majority of the complaints off the table, and therefore we will win. Leave it like this! It's perfect!" |
|
  jfmezei Premium join:2007-01-03 Beaconsfield, QC
·ELECTRONICBOX
| reply to Guspaz >Why? There are legitimate cases where a user wouldn't have >both lines with TekSavvy
Mr Gazpus,
It isn't that simple. Teksavvy buys bandwidth capacity. We pay for usage (how much data in a month).
To teksavvy, it makes a big difference if users download at full speed continuously until they reached the 200gigs in a day or two, or if they donwload continuously, but at lower speed until they reach 200gigs in 30 days.
They've found a happy medium where bandwdith generated by users is within the bandwdith capacity purchased from transit providers.
But if you end up using 10mbps wuith Teksavvy when you're only giving Teksavvy enough money to support 5mbps, then this put extra strain on their infrastructure for which you didn't pay for.
If a couple of geeks do thst, TSI can ignore it. But deploy this widely, and TSI would have to seriously increase its transit capacity without getting any additional revenus. |
|
  Guspaz Guspaz Premium,MVM join:2001-11-05 Montreal, QC
·Colbanet
| A high capacity carrier like TSI has enough traffic flowing such that bursts average out. They'll still see the daily variations, but the impact of individual users gets lost in the noise. This will only become more true as TSI continues their rapid growth. |
|
  nice guys
@videotron.ca
| I agree with jf, With growth comes costs. Their in business to make money.
Buying someone elses DSL service (two 16-meg lines at that) and using just one log-in for teksavvy to bypass is providing a free ride. Not to mention what JF said about paying for a 5-meg login and using a 16-meg line.
Though I see your point of view, its none the less is a free ride. There should be a nominal fee for people doing this.
With "rapid growth" comes rapid costs.
Nice guys finish last. |
|
  jfmezei Premium join:2007-01-03 Beaconsfield, QC
·ELECTRONICBOX
| reply to Guspaz >but the impact of individual users gets lost in the noise.
Correct. Teksavvy doesn't care that Angelo constantly downloads Linux ISOs.
But it would very much care if this were to become widespread with a large proportion of its customers doing the same.
Same with line bonding using someone else's ADSL line. If TSI is to give you 10mbps worth of bandwdith, it should get more revenu from you than if you use the same account with only 5mbps.
Getting your second link from Teksavvy gives TSI that added revenu. Using someone else's ADSL line doesn't.
Teksavvy might wish to consider steps which would prevent people from using non-TSI provided ADSL links to augment the bandwdith of a single TSI link. This way, they would prevent this currently-non-problem into growing into a serious problem later on should this become too popular. |
|
  moot
@videotron.ca
| I don't know how big of a problem this will be in the future.
Bell is supposed to have (or will) filed with the CRTC to have price and B/W changes inflicted on the wholesalers in order to monitize on B/W at the both the reatil and wholesale level.
I'll make another topic on that since it has my curiosity if anything has goine on so far.
So if these B/W changes do occur (predicted prior to the End of Jan, 2009), new users won't ever get a chance to use their Bell line with teksavvy, or new users will not be allocated more than 60-gigs per line anyhow.
So if what Bell said they will do happens, then the whole debate is moot anyhow. |
|
  TSI Steve TSI Steve Premium,VIP join:2007-01-12 Chatham, ON
| said by moot :
I don't know how big of a problem this will be in the future.
Bell is supposed to have (or will) filed with the CRTC to have price and B/W changes inflicted on the wholesalers in order to monitize on B/W at the both the reatil and wholesale level. You mean, to double dip. We ALREADY pay Bell for B/W. It's included in the costs for our AGAS connections.
If they charge us for B/W, they should lower the cost of the AGAS (significantly). Which I am willing to best they won't...
Steve |
|
  R0CKY TSI Rocky Premium,VIP join:2005-05-19 Chatham, ON
| said by TSI Steve :said by moot :
I don't know how big of a problem this will be in the future.
Bell is supposed to have (or will) filed with the CRTC to have price and B/W changes inflicted on the wholesalers in order to monitize on B/W at the both the reatil and wholesale level. You mean, to double dip. We ALREADY pay Bell for B/W. It's included in the costs for our AGAS connections. If they charge us for B/W, they should lower the cost of the AGAS (significantly). Which I am willing to best they won't... Steve We also pay some b/w through the cost of each connection ($20-$21/month). We then also pay for bandwidth on each of the Gig-E connections, the AGAS component as you mentioned.... Not considered is also the fact the individual is paying for some of the copper costs through the phone/long distance services as well.... There's something like a 5 or 6 dip in this thing, not just a double-dip!  -- TSI Rocky - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )
|
|
  TSI Steve TSI Steve Premium,VIP join:2007-01-12 Chatham, ON
| said by R0CKY :We also pay some b/w through the cost of each connection ($20-$21/month). We then also pay for bandwidth on each of the Gig-E connections, the AGAS component as you mentioned.... Not considered is also the fact the individual is paying for some of the copper costs through the phone/long distance services as well.... There's something like a 5 or 6 dip in this thing, not just a double-dip! OK WELL THEN....
I stand corrected... 
Steve |
|
 45578933
join:2008-10-13 canada | reply to R0CKY Steve don't mind ROcky. He's in a bad mood today. Someone from Bell peed in his timmies this morning. |
|
  R0CKY TSI Rocky Premium,VIP join:2005-05-19 Chatham, ON | Hehehe... Nah... not it a bad mood... Just thought I'd call things for what they are today rather than playing to political card! |
|
  TSI Steve TSI Steve Premium,VIP join:2007-01-12 Chatham, ON | reply to R0CKY Oh well I replied "I stand corrected " Not because Rocky corrected me, but because the correction makes me sad to know.
Steve |
|
 mr_hexen
join:2007-08-02 Brampton, ON
| reply to jfmezei said by jfmezei :Bu if MLPPP starts to become mainstream, then it will be looked at by Bell. If this happens then TSI (and other ISPS who support / offer MLPPP) would have an open and shut case with Bell Anti-competitive behaviour. As Bell increases their own speeds using ADSL2+, MLPPP is the easiest way for TSI and others to match that speed. Screwing with that would be anti-competitive for sure.... not that the CRTC is honest or anything... |
|
 Omr
join:2004-01-10 M1S-1B3
| reply to R0CKY Probably why Bell has waited off in doing anything about MLPPP ... they figure lets rather not give the CAIP more ammo while the CRTC case still lingers. I'm guessing after tomorrow is when we find out there MLPPP strategy both scenarios don't bode well for MLPPP but hey we can always give the CRTC another go. |
|
  pnjunction Teksavvy Premium Premium join:2008-01-24 Toronto, ON
·TekSavvy Solutions..
| reply to jfmezei Yeah I'm thinking one unlimited login from Teksavvy and 2-3 16 Mbps lines from Bell would be quite a screw-job on Teksavvy.
It's the best of both worlds (TSI transit, caps and MLPPP support with ADSL2 sync rate), but not fair to Teksavvy at all.
If only Bell would allow wholesale access to ADSL2/remotes with reasonable rates/caps (hah!), we wouldn't be having this discussion. |
|
  DJMASACRE
join:2008-05-27 Nepean, ON
·TekSavvy Solutions..
·Bell Sympatico
| reply to R0CKY said by R0CKY :Hey gang, As it stands... The above portion (ERX1440) is currently AGAS#6 on it and the below 5 X ERX310s are the other AGAS connections (1:1). After hearing discussion between Marc & Joe here's what will likely happen. We're going to get another 1440 in there, replace the 5 X ERXs and pull the cards from them to spread into the two ERX1440s. Here's why... We'll be able to do up to 12 X AGAS connections through the two 1440, but the beauty is that after AGAS7, which will happen through all of this, we'll have the ability to add new slots live, on the fly, without any future downtime. We'll also then have the ability to better the MLPPP situation (ie: without doing the tomato fix) and will be that much closer to IPv6 as well! The unfortunate thing is it will likely require a couple more maintenance windows from here to Christmas... In any case, this is huge, on many fronts, but in our mind will set us apart from all others and will allow for some crazy expansion/redundancy/capabilities/etc.... Im not complaining about Downtime if its for upgrading.
Its not a problem, its a solution
People shouldnt complain when the internet is down for maintenance, because in the long run it makes everyone happy.
I hope everyone will realize this, and expect more great things from the best ISP in North America !  |
|
  Guspaz Guspaz Premium,MVM join:2001-11-05 Montreal, QC
·Colbanet
| reply to R0CKY DSL_Ricer noticed something interesting when reading the Juniper docs on the ERX1440.
It only supports 4000 MLPPP bundles. Per chassis. This is a software OS limit rather than a hardware limit, as the exact same limit is on the ERX310. If there are 6 AGAS lines going through one ERX1440 eventually, and there are two thousand people on each AGAS (pulling a number out of my ass here), then only 33% of customers will be able to use MLPPP at a time.
Also, unfortunately, the ERXes do not support VJ compression or MPPE. So there's no hope of strengthening the throttling evasion via either of those two methods with TekSavvy's current hardware.
So, if the worst comes to pass, and Bell both wins the CRTC case and begins throttling MLPPP, there's only really one viable solution for TekSavvy; buying a new GAS domain and running an L2TP tunnel through a Linux box acting as the PPP endpoint. Or buying non-Juniper hardware that supports MPPE. |
|
 45578933
join:2008-10-13 canada | reply to R0CKY Someone did something this morning. Half the chatroom pinged out at 4am-ish and ERX06 started answering pings again on the morning of the 19th. |
|
  R0CKY TSI Rocky Premium,VIP join:2005-05-19 Chatham, ON
| reply to Guspaz said by Guspaz :So, if the worst comes to pass, and Bell both wins the CRTC case and begins throttling MLPPP, there's only really one viable solution for TekSavvy; buying a new GAS domain and running an L2TP tunnel through a Linux box acting as the PPP endpoint. Or buying non-Juniper hardware that supports MPPE. Interesting idea this GAS domain idea!  -- TSI Rocky - TekSavvy Solutions Inc.
Authorized TSI employee ( »TekSavvy FAQ »Official support in the forum )
|
|
  Guspaz Guspaz Premium,MVM join:2001-11-05 Montreal, QC
·Colbanet
| It's not my idea, it's the approach currently under testing by another wholesaler. I don't know if I'm allowed to go into further details about their particular approach, though? They never said it was confidential information, but the details haven't been made otherwise public.
There are ups and downs to doing the commodity hardware approach. On the upside, you get reasonably linear scalability (Need more throughput/lines? Throw more RAM and CPU cores at the problem). You also get support for all the technologies that the "big boys" like Juniper don't bother with (header compression, MPPE encryption, etc.).
On the downside, there are certain issues with the Linux PPP implementation that make it non-ideal for server use. DSL_Ricer would be able to tell you more, but I recall something about a fixed 128-packet buffer that had the potential to produce some seriously non-optimal situations. |
|