Re: Sending vs requesting. Was: Re: Sprint / Cogent

From: Barrett Lyon (no email)
Date: Sat Nov 01 2008 - 13:30:25 EDT

  • Next message: Dave Blaine: "routing around Sprint's depeering damage"

    Patrick,

    To further your point about the dynamics of peering:

    Not to sound overly altruistic, but nowhere in there did I see, "it's
    good for the Internet". If peering was less of a raw business
    decision, the Internet would be a better place. In this case, if they
    left it status quo and congested, at least users could send smoke
    signals across the two networks and could at least communicate.

    The implications of this depeering could be pretty severe. If you dive
    into business ethics, there's some pretty serious moral dilemmas
    involved with cutting communications between two major networks. This
    could be taken to an extreme if it causes VoIP calls to fail and
    ultimately disrupts someone's 911 calling. In less reaching
    situations, someone can't SMS with their wife to know what to bring
    home from the grocery store. Regardless of how stupid relying on the
    Internet is (I know it's sad we can't) I do feel networks have a moral
    responsibility to provide continuity.

    As you know, beyond business, peering can decrease latency, increase
    throughput, and provide better network engineering, thus increasing
    the scale of the overall Internet. As a technologist and entrepreneur
    I try to do what's best for the Internet in my peering decisions
    rather than what Bill Lumbergh would say, "umm yeah, do what's best
    for the company".

    In this case, it's very clear that customers are impacted and the
    Internet as a whole suffers, which is really unfortunate. The end
    result of a business decision has been to sacrifice the customer's
    needs, trust, and ability to communicate. It's a bad maxim to
    subscribe to! I really hope that other networks do apply more
    thinking into peering than just what's best for business -- it sure
    shows off an ugly underbelly.

    -Barrett

    On Nov 1, 2008, at 9:45 AM, Patrick W. Gilmore wrote:

    > On Nov 1, 2008, at 12:05 PM, Chris Adams wrote:
    >> Once upon a time, bas <> said:
    >>> I've heard eyeball networks refer to traffic flows as sending too..
    >>> "You content hosters are sending us too much traffic, we want
    >>> money to
    >>> upgrade ports and transport all that traffic" Complete reverse
    >>> logic
    >>> imho. It is always eyeball network customers that request data.
    >>> (except for a small portion of iphone/blackberry push email, but
    >>> that
    >>> can't account for much.)
    >>
    >> Traffic sources tend to be concentrated in large data centers
    >> (easier to
    >> service), while traffic sinks (DSL, cable, wireless) are widespread
    >> and
    >> costly to upgrade. The sink customers don't want to pay more (and
    >> there's at least some competition), so the sink providers look to see
    >> where else they get income to pay for their needed network upgrades.
    >
    > Combined with hot-potato routing, the first part of that paragraph
    > is a fancy way of saying "I have to carry the large packet a long
    > way, you have to carry the small packet a long way". It is not
    > "fair". This is almost a good reason, but not quite. (It can also
    > be offset by moving the source next to the sink, through cold-potato
    > routing / MEDs, anycast, CDNs, etc.)
    >
    > The second part is a good business reason. Profitable revenue is
    > good, costs are bad.
    >
    > There are good business reasons not to pay the sink as well. But
    > neither decision is obvious or the same for everyone.
    >
    > Peering is complicated, people should stop trying to generalize it.
    >
    >
    > Peering is a business tool. For years & years many people have
    > claimed that to "peer" you must be equal. Bullshit. If I can make
    > more or spend less by peering, I should do it. If not, I should
    > not. Full stop. Notice the complete lack of regard for how big you
    > are, how much capacity your backbone has, how many ASes are
    > downstream of you, etc.? When I go to buy routers or hire employees
    > or any other business transaction, I don't say "that router vendor
    > is making more money than I am, so I won't buy from him". If people
    > applied "peering" logic to anything else, they'd be laughed out of a
    > job.
    >
    > Don't know about you, but I am in business to make money, not
    > measure my anatomy. How big the next guy is doesn't enter into my
    > equation - other than how it affects my bottom line.
    >
    > To be clear, it is entirely possible that peering does not save you
    > money. Vijay is right, most people can't measure their COGS to save
    > their life. And if the network in question cannot, there's no way
    > in hell the prospective peer can. If you are a huge point source of
    > traffic and want to peer, I may save money by saying no and paying a
    > transit provider to deliver the packet to me where I want it
    > (especially at today's prices). Fiber, routers, colo, NOC
    > employees, engineers, etc., are all not free ya know.
    >
    > You can claim my customers asked for the data and therefore I have a
    > requirement to peer, but you would be deluded. What my customer and
    > I have agreed has _nothing_ to do with you or your needs. You don't
    > tell me how to run my network, and I won't tell you how to run
    > yours. Deal?
    >
    > On the flip side, saying "you are not on 3 continents so I will not
    > peer" is stupid of not peering costs you millions a year. Stupid
    > decisions abound in the peering ecosystem.
    >
    > There are tons of other _business_ reasons to peer, or not to peer.
    > But "we're equal" or "your customer asked for it" are not reasons,
    > stop using them.
    >
    > --
    > TTFN,
    > patrick
    >
    >


  • Next message: Dave Blaine: "routing around Sprint's depeering damage"





    Hosted Email Solutions

    Invaluement Anti-Spam DNSBLs



    Powered By FreeBSD   Powered By FreeBSD