[144003] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Level 3 Peering Guidelines

daemon@ATHENA.MIT.EDU (Patrick W. Gilmore)
Fri Aug 26 21:33:32 2011

From: Patrick W. Gilmore <patrick@ianai.net>
In-Reply-To: <20110826184647.GA578@ussenterprise.ufp.org>
Date: Fri, 26 Aug 2011 21:32:00 -0400
To: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

> I have yet to find a down side to this sort of sunshine.  I'd wecome
> anyone who thinks its a bad idea to educate me.

Why is that any different than forcing businesses to explain which links =
are paid?  Or any other internal data?  Private businesses are private.  =
Their relationships with other private businesses are private.  Saying =
some data should be public while others are not is arbitrary.

Next time Cogent de-peers someone, customers do not care who was being =
more reasonable.  They care that their links are broken.  Customers do =
not care if links are out of ratio, they care if packets are dropped.  =
Further there are companies who can push 75 Gbps on an 8x10 LAG for 12 =
hours without dropping a packet, while other companies cannot push 60 =
Gbps on that same link without some intermittent packet loss.  =
Explaining to customers which are 'good' and which are 'bad' is an =
impossible task.

Finally, if this were to happen, a lot of links would be quickly =
disconnected.  Perhaps that could be considered a feature, but I am not =
at all certain it would be.

In summary: I do not like gov't involvement, even if it is just to =
require some random set of data to be made public.

--=20
TTFN,
patrick



On Aug 26, 2011, at 2:46 PM, Leo Bicknell wrote:

> In a message written on Fri, Aug 19, 2011 at 05:40:43PM -0400, Patrick =
W. Gilmore wrote:
>> Yes, Above.Net broke the original peering-ratio fight that way.  =
Thank you for that.  Too bad it didn't last.
>=20
> I forgot to write back when you first posted this, but the recent
> follow ons reminded me...
>=20
> While it is not a wide spread practice, I am 99.99% sure several
> networks are still using this method in private.  I also know of
> at least two networks that have in the past deaggregated their large
> supernets to peers to affect a similar result.
>=20
> The interesting thing is that this is not done to elminate the
> peering ratio argument in the aggregate, but to make up for the
> geography of the two networks.  Maybe one network insisted on peering
> in a city that the other only has a few customers in, so the link
> is mostly idle while others run too hot.  Rather than provision
> more bandwidth they agree to meds or deaggregates to get the traffic
> to the lightly loaded link.  The ratio in the aggregate is basically
> unchanged.
>=20
>> I've said it before, more times than I can count.  Peering is a
>> business tool, a means to an end.  The goal, the 'end', of for-profit
>> companies is to make a profit.  Sounds obvious, but surprising how
>> many people forget this.  If peering with another network will
>> increase your profit and you turn down the peering request, you
>> should be fired.  Your ego should not be substituted for business
>> decisions.
>=20
> I agree with your premise, and think everyone involved _thinks_
> they are making the best business decision for their company.
> However I believe many folks are in fact making poor decisions for
> their company because they lack data.  It's interesting to look at
> the first order costs of peering; the port, cross connect, and time
> to set it up.  In my experience though the second and third order
> effects are far more important; how it affects your ratio with other
> peers, your customer's perception of your network performance, etc.
> These are much harder to measure, and near as I can tell virtually
> no network does.
>=20
> I've been asked many times how the government could step in and
> help, aka regulate peering to make it better.  In thinking about
> all the things that could be mandated, the interactions that can
> be regulated, I see them generally as a univeral bad.  With one,
> major, glaring exception....
>=20
> Right now peering is all done in secret.  You don't really know if
> your competitor is getting free peering, paying to peer, or getting
> paid to peer.  You don't know if they are really insisting on the
> same locations with other parties they insist with for you.  It's
> a perfect game of poker.  This is in stark contrast to say, transit,
> where you can get prices from 20 people and compare.
>=20
> AboveNet also used to put graphs of almost all of its peering links
> online, in real time.  A few peers flat out refused, but most were
> there.  You could see where they peered, at what speed, and how
> much traffic was flowing.  You could also calculate the ratio.
>=20
> I think the Government could bring a lot of sunshine to the party
> if it simply required all ISP's to do just that.  Post a graph of
> every peering link or port to a public exchange, updated in real
> time.  They all have the data internally, they are all collecting
> it for their own needs.  You still wouldn't know if any money is
> changing hands, but imagine how it would change many of the
> interactions.   Oh, you require me to hit 3Tb aggregate, when you
> have 20 peers that are less than half that?  Really, you're going
> to require me to peer with you in Nome Alaska when you don't have
> any other peers at that location?
>=20
> It would also let ISP's make an informed decision about depeering
> events.  The next time cogent splits from someone you can go look
> at the graphs on both sides, and make your own decision who was
> being more reasonable.  It would also let you, the transit customer,
> evaluate the extent and free capacity to peers your ISP has before
> buying.
>=20
> I have yet to find a down side to this sort of sunshine.  I'd wecome
> anyone who thinks its a bad idea to educate me.
>=20
> --=20
> Leo Bicknell - bicknell@ufp.org - CCIE 3440
>  PGP keys at http://www.ufp.org/~bicknell/



home help back first fref pref prev next nref lref last post