North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Cogent/Level 3 depeering (philosophical solution)

  • From: William B. Norton
  • Date: Mon Oct 10 13:08:28 2005
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta;; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QuBxLXVxNclHFtQksBan2KPtZ2y+3e5S6UiFxDS416Yp0jE7EYzfcbX/JtQDO0aUW7UKL1bN+acuNK8fnz7fAK2VWydgr2IFbVKuAnv/JEQdPtrR5QavnZkYz3y4dKFFgxmikKUYFoMDddE/lRjUdCrUYHS29sOfam6xcJfnSnw=

Peering Ratios?

It is very timely that the upcoming NANOG Peering BOF X in Los Angeles
will have a debate on this very subject: Traffic Ratios - a valid
settlement metric or dinosaur from the dot.bomb past.

I'm sure the strongest arguments from these threads will be clearly
articulated (in a bullet point/summarized form I hope) during the
debate by the debaters. At the end of the day, as with most things
peering, the focus of this discussion is a meld of business and
technical interests. The heat we have witnessed is probably more
related to the friction of the business interests. We get very upset
about the notion of "fair" don't we.  Perhaps in the few structured
minutes of the Peering BOF debate we can objectively hear both sides
of this argument and provide a little light as well.

Defending Traffic Ratios as a valid peering prereq: Peter Cohen
Attacking Traffic Ratios as peering prereq: Richard Steenbergen

Should be good fun.


On 10/10/05, David Schwartz <[email protected]> wrote:
> > [email protected] ("David Schwartz") writes:
> > >     I think the industry simply needs to accept that it's more
> > > expensive to receive traffic than to send it.
> > It is?  For everybody?  For always?  That's a BIG statement.  Can
> > you justify?
>        In those cases where it in fact is and there's nothing you can do about it,
> you need to accept it. You should not expect to be able to shift the burden
> of carrying your customers' traffic on your network to others. (The fact
> that you can sometimes bully or blackmail and get away with it doesn't
> justify it.)
> > > ...
> > >     The question is whether the benefit to each side exceeds their cost.
> > Yea, verily.  But I don't think you'll find a one-cost-fits-all
> > model.  When
> > one person's costs are lower than another and they're doing
> > similar things,
> > it's often called "efficiency" or "competitiveness".  (Just as
> > one example.)
>        I heartily agree.
>        My point is simply that the "your customers are getting more out of our
> network that our customers are" argument is bull. Your customers are paying
> you to carry their traffic over your network.
>        There can certainly be legitimate peering disputes about where to peer and
> whether there are enough peering points. If someone wants you to peer with
> them at just one place, it would certainly be more cost-effective for you to
> reach them through a transit provider you meet in multiple places, for
> example. (You could definitely refuse settlement-free peering if it actually
> increases your costs to reach the peer.)
>        I am not making the pie-in-the-sky argument that everyone should peer with
> everyone else. I am specifically rejecting the argument that a traffic
> direction imbalance is grounds for rejecting settlement-free peering. If
> your customers want to receive traffic and receiving is more expensive, then
> that's what they're paying you for.
>        Again, carrying *your* customers' traffic over *your* network is what
> *your* customers are paying *you* for. If your customers want more expensive
> traffic, you should bear that greater burden.
>        A traffic direction imbalance is not reasonable grounds for rejecting SFI.
> The direction your customers want their traffic to go is more valuable and
> it's okay if it costs more.
>        DS

// William B. Norton <[email protected]>
// Co-Founder and Chief Technical Liaison, Equinix
// GSM Mobile: 650-315-8635
// Skype, Y!IM: williambnorton