On 07/09/2007, paul at clubi.ie <paul at clubi.ie> wrote:
> On Wed, 5 Sep 2007, Thomas Bridge wrote:
> > The entire thrust of my comments have been aimed at the position
> > that as a cost of managing and routing P2P traffic, transit is not
> > particularly high on the list. I've never suggested there were
> > problems with using transit (by which I include peering with other
> > ISPs).
> So there are no problems - at least, nothing mentioned by me or the
> other two posters so far is a problem.
Thats not what I said - again, read what I wrote.
What I said was the cost of transit is not high on the list of the
problems involved with an ISP trying to manage P2P traffic.
I should probably make my assumptions clear - I am assuming that the
ISP typically backhauls it's DSL user traffic to a central location -
eg a Data Centre. In that location, there are multiple transit
providers willing to sell transit. This transit is then delivered by
running a cable under the floor to the transit provider's meet me
point. (Again transit in this case is deemed to include peering -
it's any traffic that has to exit the ISPs AS sets).
It gets a little more complex if you're running several aggregation
points (as you might in the UK - you might have a presence in Glasgow,
Manchester, Birmingham, Bristol and London), but the thrust of my
point is still broadly valid.
> How about going into detail as to what (if any) problems P2P is
> causing ISPs, with respect to load particularly. That'd be far more
> productive application of your operational experience than this
> naysaying..
Typically, the issues with P2P traffic are on the last mile - the link
from the ISPs aggregation point to the customers PC. These problems
are two fold - on the path either from the ISP to the exchange if you
use the ATM based model, or from the ISP to the Telco's BAS. The
behaviour of a small number of users can have a negative impact on the
rest of the users (it should be noted in the Irish case that ATM
handles the contention more fairly, but L2TP diluted the problem by
sticking Nxc customers into one N Mb circuit, rather than N 1MB
circuits of c customers).
In general, the fact remains that if 100 customers each order 5MB in
the same exchange, there isn't going to be 500 MB out of the exchange.
And that's where P2P starts to cause an issue.
It is also worth noting that most current P2P applications such as bit
torrent and gnutella are going to get your Linux ISOs or dodgy MP3es
over the ISPs transit connections.
> > No - I said the costs of getting traffic from the customer site to
> > the ISP's data centre were the biggest part of the cost involved in
> > supplying a DSL service. For clarity, it's the cost of building
> > and maintaining the DSL "circuit/link" in the first place - not
> > just the cost of carrying traffic over the link.
> The whole 'connect customers to ISPs' circuit-switching model also
> has a lot over administrative overhead.
But not typically on a per user basis - the administrative overhead
tends to be involved in the setup of the service. The incremental
overhead on a per customer basis adds minimal cost to the setup of the
model in the first place.
> Intriguingly, this does NOT seem to be borne by the IP guys. All the
> work of co-ordinating with Eircom to connect "DSL at line with number
> Y" -> ISP X seems to get done by non-technical administrative staff.
Correct - but that work is pretty much the same regardless of what
technology is used to connect line Y to ISP X.
> If everything ran in a single network, with the /ability/ to
> short-circuit ISP traffic at exchanges and/or BAS (if the ISPs
> involved deemed that to be 'shortest'), you might save some of those
> human overheads. Hence the 'build' cost might be slightly lower..
Are you on crack? Seriously? How are you going to save "human"
overheads by exchanging local traffic at the exchange? If any thing,
you're going to add to it by increasing the amount of management the
ISP and the Telcos need to carry out.
> The average amount is going to tend towards "the link capacity". The
> masses *will* one day be watching corry via IP.. And P2P is the new
> multicast..
Be more to the point to use actual multicast. Which is what a lot of
cable ISPs are going to be doing.
> > I would say that the proportion of traffic travelling from house to
> > house within the same street is typically less than 0.1% of the
> > average DSL users traffic.
> From your view of a DSL network operatio. Agreed. Because it's
> impossible at present for people to do so.
No, it's because my neighbor (this is a general term rather than a
comment on other residents of my town) rarely has anything I want.
> I bet the picture is different with cable networks where customers
> can see each other..
>From what I've seen in multicast presentations and the like, typically
multicast is what the various providers are preferring to use.
This is presumably part of the motivation behind the likes of Magnet
extending out to the exchange - it gives them the ability to benefit
from the scaling that multicast brings.
> We could have invented ways to distribute IP configuration
> information from ISPs to wholesaler, rather than have invented ways
> to fake-up L2 links between customer and ISP (e.g. PPPoE, L2TP -
> energy mispent).
Presumably it was cheaper to fake up the links :) In fact, given
what I know about the history of L2TP, it was.
Telcos and ISPs are businesses - they aren't going to spend millions
making pure models when they can deliver practically the same service
for thousands. And looking at most developments in the
IP/MPLS/VPN/whatever stack, they are based on tweaking the existing
model to fit new requirements.
> > If we'd left it to incumbent telco to run the country's ISP
> > infrastructure, we'd all still be using 33.6K modems at an average
> > cost of about €40 a month.
> Sure, agreed.
And therefore my point stands - you don't want one ISP managing the IP network.
> I.e. instead of having invented PPPoE, L2TP, MPLS, etc.. If we'd
> dealt with the fundamental management problems instead (that retail
> ISPs didn't have a way to exchange IP configuration information with
> wholesale ISPs, and have wholesale ISPs apply that information) then
> we'd today have much more efficient broadband networking.
I'm still struggling to see the existing model as particularly
inefficent in that 99.9% of traffic still seems to take the "optimal"
route.
It's also frankly the nature of the internet - if I use my gmail
account to send an email to my brother with a hotmail account, I may
potentially be sitting in the UK, connecting to a server in Holland,
which then exchanges the email with an MX in New York, which stores
the email on a server in Dublin, which my brother later connects to
from the same PC.[1]
In other words, the more you move up the layers, you more get
abstracted from the underlying physical topology.
If I order a protected STM-1 circuit, I'm not typically worried about
which way around the ring my traffic goes. It may even be
"inefficent" if I have say, an IP device in London, an IP device in
Manchester, and my circuit goes via Birmingham. I may have another
circuit that connects from London to Birmingham, and it may mean that
my packet goes through Birmingham twice. It's the nature of IP that
I abstract that topology.
> Inventing one wouldn't have taken any extra thought over the other,
> except that telco people seem wedded to thinking of networking as
> circuits - so to solve problems they create things to make circuits..
I'm struggling to see how you connect two sites together without using
"circuits" - of either the WAN or LAN type.
> circuits of neto.... are a good thing, the reality is they're a
> kludge. It's provably inefficient,
I'm not disputing either of these.
>and it needn't have been so.
That's more debatable :)
Thomas
[1] Note to google bods on the list - the fact that you almost
certainly have a more sane model than this doesn't negate the thrust
of the point I'm making.
--
Thomas Bridge
CCIE #14108
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
