How does it look when you examine it by not the count of sessions or links but by the volume of overall data? I wonder if it may change a little like 50% of the volume of traffic is covered by a handshake. (I made 50% up - could be any percentage.) Jason PS - My email address has changed and I’m trying to send a 3rd time. Apologies if they all suddenly post to the list as duplicates! :-)
On 2/10/16, 6:34 PM, "NANOG on behalf of Patrick W. Gilmore" <nanog-bounces@nanog.org on behalf of patrick@ianai.net> wrote:
I quoted a PCH peering paper at the Peering Track. (Not violating rules, talking about myself.)
The paper is: https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2 0 11.pdf
I said ³99.97%² of all peering sessions have nothing behind them more than a ³handshake² or an email. It seems I was in error. Mea Culpa.
The number in the paper, on page one is, 99.52%.
Hopefully everyone will read the paper, and perhaps help create better data.
-- TTFN, patrick
I was going to ask the same thing, since even for settlement free peering between large content providers and eyeball networks there are written agreements in place. I would have no clue on the volume percentage but it's not going to be near 99%. Phil From: Livingood, Jason Sent: Friday, February 12, 2016 11:41 AM To: North American Operators' Group Subject: re: PCH Peering Paper How does it look when you examine it by not the count of sessions or links but by the volume of overall data? I wonder if it may change a little like 50% of the volume of traffic is covered by a handshake. (I made 50% up - could be any percentage.) Jason PS - My email address has changed and I’m trying to send a 3rd time. Apologies if they all suddenly post to the list as duplicates! :-)
On 2/10/16, 6:34 PM, "NANOG on behalf of Patrick W. Gilmore" <nanog-bounces@nanog.org on behalf of patrick@ianai.net> wrote:
I quoted a PCH peering paper at the Peering Track. (Not violating rules, talking about myself.)
The paper is: https://www.pch.net/resources/Papers/peering-survey/PCH-Peering-Survey-2 0 11.pdf
I said ³99.97%² of all peering sessions have nothing behind them more than a ³handshake² or an email. It seems I was in error. Mea Culpa.
The number in the paper, on page one is, 99.52%.
Hopefully everyone will read the paper, and perhaps help create better data.
-- TTFN, patrick
* bedard.phil@gmail.com (Phil Bedard) [Sat 13 Feb 2016, 01:40 CET]:
I was going to ask the same thing, since even for settlement free peering between large content providers and eyeball networks there are written agreements in place. I would have no clue on the volume percentage but it's not going to be near 99%.
It's much closer to 99% than to 50%, though. -- Niels.
On 2/12/16, 8:56 PM, "NANOG on behalf of Niels Bakker" <nanog-bounces@nanog.org on behalf of niels=nanog@bakker.net> wrote:
* bedard.phil@gmail.com (Phil Bedard) [Sat 13 Feb 2016, 01:40 CET]:
I was going to ask the same thing, since even for settlement free peering between large content providers and eyeball networks there are written agreements in place. I would have no clue on the volume percentage but it's not going to be near 99%.
It's much closer to 99% than to 50%, though.
Any reference on that? I¹m wondering who (if anyone) is formally measuring / tracking this and seeing the exact trend over time. Thanks Jason
On Feb 16, 2016, at 9:49 AM, Livingood, Jason <Jason_Livingood@comcast.com> wrote:
On 2/12/16, 8:56 PM, "NANOG on behalf of Niels Bakker" <nanog-bounces@nanog.org on behalf of niels=nanog@bakker.net> wrote:
* bedard.phil@gmail.com (Phil Bedard) [Sat 13 Feb 2016, 01:40 CET]:
I was going to ask the same thing, since even for settlement free peering between large content providers and eyeball networks there are written agreements in place. I would have no clue on the volume percentage but it's not going to be near 99%.
It's much closer to 99% than to 50%, though.
Any reference on that? I¹m wondering who (if anyone) is formally measuring / tracking this and seeing the exact trend over time.
Niels is in a position to know what his network does. You are in a position to know what your network does. My guess is Comcast requires a contract with everyone, meaning your peering bits are mostly (all?) contracted. I know Akamai does not require a contract, and will only sign if the other side requires it. (This is not a secret.) My guess is they have a lot more un-contracted peering bits than Comcast. However, let’s look at the basic premise here. A handful of networks (50? 100? 200?) on the Internet require contracts with everyone. And if we are being honest with each other, about 5 of those are legacy “backbone” networks which have not been purchased by a broadband network. The rest are broadband networks guarding their monopoly positions. (Interestingly, broadband networks without monopoly positions to guard do not require contracts.) The other many 1000s of networks do not require contracts to peer. The premise above therefore devolves to: Since most of the traffic is to those networks, then most of the bits flow over contracted peerings. Perhaps “most” can be argued, but obviously a significant portion of all peering bits flow over contracted sessions. Hopefully we can all agree on that. And let’s also agree there are reasons to have contracts. Peering can require a great deal of time, effort, and money. Peering can require contracts with transport providers, equipment suppliers, colocation facilities, etc. I’m not saying everyone should have a contract for everything. I’m just saying there are good and valid reasons for them, at least sometimes. But saying “most bits flow over contracts” is not the end of the story. First, look at the three content “networks” with the most traffic - Google, Netflix, Akamai. All will peer without contracts. All peer at IXes. In fact, all are happy to exchange traffic without even an email to the other network (i.e. route-server peerings). Since these three networks are some of the largest (the largest?) on the planet, it is clear that volume alone does not create the requirement for a contract. Also, let’s take the bottom 10K peering networks. They will not get peering with Comcast, DT, CT, Telstra, FT, etc. Meaning pretty much all their peering bits are over un-contracted sessions. The rest is transit. I guess you could say the bits sent over transit will eventually hit a contracted peering session, since the people in the core contract their sessions. But does that matter to the small guys? In summary, lots of bits flow over contracted peering sessions. But more sessions are not contracted. And lots of bits flow over those non-contracted sessions. Going back to my original post, I was trying to show there are plenty of jobs for peering people who will rarely or even never sign a contract. Plus this is a great place to learn things like capacity planning, BGP, and other technologies required to do peering well. If you are good, you can learn the commercial underpinnings of peering. Then if you are lucky enough to score a job with a legacy “tier one” which still thinks it is relevant, or a monopolistic broadband company, you can learn contracts after the fact. :) -- TTFN, patrick
The premise above therefore devolves to: Since most of the traffic is to those networks, then most of the bits flow over contracted peerings.
Perhaps “most” can be argued, but obviously a significant portion of all peering bits flow over contracted sessions. Hopefully we can all agree on that.
There’s greater complexity here, however… Many of the bits that flow flow over several networks between their source and destination. Likely the vast majority of bits traverse at least 3 autonomous systems in the process. So when you want to count traffic that went over a non-contract peering session vs. traffic that went over a contract peering session, how do you count traffic that traverses some of each? Owen
Each bit traverses only one peering session, however, at the "top of its trajectory" to use a physical metaphor. The uphill and downhill sides are all transit. -Bill
On Feb 17, 2016, at 14:06, Owen DeLong <owen@delong.com> wrote:
The premise above therefore devolves to: Since most of the traffic is to those networks, then most of the bits flow over contracted peerings.
Perhaps “most” can be argued, but obviously a significant portion of all peering bits flow over contracted sessions. Hopefully we can all agree on that.
There’s greater complexity here, however…
Many of the bits that flow flow over several networks between their source and destination. Likely the vast majority of bits traverse at least 3 autonomous systems in the process.
So when you want to count traffic that went over a non-contract peering session vs. traffic that went over a contract peering session, how do you count traffic that traverses some of each?
Owen
This assumes that there are no cooperatives providing settlement free peering which includes both peer and transit routes. Owen
On Feb 17, 2016, at 14:09 , Bill Woodcock <woody@pch.net> wrote:
Each bit traverses only one peering session, however, at the "top of its trajectory" to use a physical metaphor. The uphill and downhill sides are all transit.
-Bill
On Feb 17, 2016, at 14:06, Owen DeLong <owen@delong.com> wrote:
The premise above therefore devolves to: Since most of the traffic is to those networks, then most of the bits flow over contracted peerings.
Perhaps “most” can be argued, but obviously a significant portion of all peering bits flow over contracted sessions. Hopefully we can all agree on that.
There’s greater complexity here, however…
Many of the bits that flow flow over several networks between their source and destination. Likely the vast majority of bits traverse at least 3 autonomous systems in the process.
So when you want to count traffic that went over a non-contract peering session vs. traffic that went over a contract peering session, how do you count traffic that traverses some of each?
Owen
On Feb 17, 2016, at 5:04 PM, Owen DeLong <owen@delong.com> wrote:
The premise above therefore devolves to: Since most of the traffic is to those networks, then most of the bits flow over contracted peerings.
Perhaps “most” can be argued, but obviously a significant portion of all peering bits flow over contracted sessions. Hopefully we can all agree on that.
There’s greater complexity here, however…
Many of the bits that flow flow over several networks between their source and destination. Likely the vast majority of bits traverse at least 3 autonomous systems in the process.
So when you want to count traffic that went over a non-contract peering session vs. traffic that went over a contract peering session, how do you count traffic that traverses some of each?
Lower in my post: On Feb 16, 2016, at 10:31 AM, Patrick W. Gilmore <patrick@ianai.net> wrote:
I guess you could say the bits sent over transit will eventually hit a contracted peering session, since the people in the core contract their sessions. But does that matter to the small guys?
-- TTFN, patrick
participants (6)
-
Bill Woodcock -
Livingood, Jason -
Niels Bakker -
Owen DeLong -
Patrick W. Gilmore -
Phil Bedard