Quote:
|
Originally Posted by MrBen
I've been told that traffic shaping is not currently active at the moment.
I was also told that shaping might work in the following ways...
(Note: This info was given as a personal opinion so may or may not be correct)
|
Quote:
- On-net transfers (i.e. between ntl: customers) will not be shaped because each customer is paying ntl: for their bandwidth.
|
OK, not unknown I guess. Doesn't do anything to tackle local congestion but does improve customer experience potentially.
Quote:
- ntl: users receiving data from another ISP will not be shaped because they are sucking from another ISP. Having said that the ntl: user maybe subject to shaping on the other network
|
Umm ok. Even though ntl will potentially be paying transit costs regardless of the direction of the traffic this is considered as not being a major issue.
Quote:
- A non-ntl: receiving data from an ntl: customer is likely to be shaped because they are taking data from ntl:'s network but are not paying ntl: for the bandwidth
|
Well no I'd expect to see that shaped more because upstream bandwidth is limited on the cable network but if this is the case this seems to be all about trying to save a few quid trying to save transit and peering setup costs. Considering that various other ISPs are busily putting multiple 10Gbit ports into LINX, Amsix, etc, this seems lame.
If this goes ahead on those terms hope you aren't the lucky person who has to deal with the depeering requests when you ruin the traffic patterns.
I'd suspect with this will come some traffic redirection, directing requests from on-net customers to other on-net customers to fulfill, which can even potentially increase upload congestion from customers getting hits they wouldn't usually. I guess that'll be where the caching comes in...
This the first part of a project to turn the whole ntl network into one giant LAN?