RE: Backbone IP network Economics - peering and transit
Deepak Jain wrote: But that structure doesn't vary vastly if you'd traffic out that gig via transit vs direct connect. It does vary (and add lots of infrastructure) if you don't aggregate your traffic at IXes and instead use loops to bring transit to you instead of going to it. (say a few 100Mb/s or OC3s in a few places instead of a GigE at an IX).
Indeed.
Perhaps we should (for technical reasons) describe peering as "direct connecting".
This makes a lot of sense to me (although I would suggest a different name later). Since the beginning I have been trying to make the point that "direct connecting" was typically a no-brainer in terms of money. Peering when you have to buy the local loop is not such a slam dunk.
Business reasons aside, technically the difference is that with transit you are expecting access via indirect connections to networks.
I'm not so sure about this. There are lots of people that buy transit and are directly connected to their provider in an IX for example.
With peering you expect direct connections into a network.
If "direct connecting" != peering then definitely. Maybe we need to say differentiate between: - Connected transit - Remote transit - Connected peering - Remote peering And agree that, by default, transit ~= remote transit peering ~= direct peering Michel.
If "direct connecting" != peering then definitely.
Maybe we need to say differentiate between: - Connected transit - Remote transit - Connected peering - Remote peering
And agree that, by default, transit ~= remote transit peering ~= direct peering
Without getting too complicated. transit is always direct connection to a single AS, and indirect to all others. For simplicity's sake, single-homed customer ASes behind the transit AS are not considered apart from the transit AS. It is indirect for the rest of the internet, including the sum of all peering (read: direct connection without any indirect connections) connectivity. peering is a always direction connection to a single AS and no indirect connections are expected. Again, single-homed customer ASes are considered part of the peering AS. ASes that can only be reached from a single AS can only be reached by those with a direction connection to the upstream AS. --- This model [good or bad] allows people who pay for customer-only routes from a transit provider they can't settlement-free peer with be considered in the same breath as "true peers". For technology concerns, I think this is valid. For business reasons there is probably some difference. DJ
Deepak Jain wrote:
If "direct connecting" != peering then definitely.
Maybe we need to say differentiate between: - Connected transit - Remote transit - Connected peering - Remote peering
And agree that, by default, transit ~= remote transit peering ~= direct peering
Without getting too complicated.
transit is always direct connection to a single AS, and indirect to all others. For simplicity's sake, single-homed customer ASes behind the transit AS are not considered apart from the transit AS. It is indirect for the rest of the internet, including the sum of all peering (read: direct connection without any indirect connections) connectivity.
peering is a always direction connection to a single AS and no indirect connections are expected. Again, single-homed customer ASes are considered part of the peering AS.
Slight error, there.. While the first always is true, the second statement may not be..... customers of peers are visible between two AS's peering.
ASes that can only be reached from a single AS can only be reached by those with a direction connection to the upstream AS.
---
This model [good or bad] allows people who pay for customer-only routes from a transit provider they can't settlement-free peer with be considered in the same breath as "true peers". For technology concerns, I think this is valid. For business reasons there is probably some difference.
DJ
participants (3)
-
Deepak Jain -
Michel Py -
Richard Irving