Generation of traffic in "settled" peering arrangement

p.s. The fact that the sender of traffic should be paying some portion
      of the resulting costs is not a surprise to anyone; many of the
      content companies that I've spoken to believe they already are
      paying more as traffic increases, and were quite surprised to
      find that it doesn't actually make it to the networks which
      bear the brunt of the traffic carriage.

p.p.s. As noted, departure from shortest-exit is also another approach
        which may provide some answers to this situation, but that's a
        different topic which deserves its own thread. This message
        is simply noting that settling for peering traffic is quite
        viable, despite assertions to the contrary regarding traffic
        generation. As long as you're billing the senders on your
        network for increased usage (and handing it off shortest-exit),
        increased traffic is good thing.

Except, John, that you ignore the fact that you have basically required
anyone who wants to put a high-bandwidth server on your network to accept
other people writing a blank check for them, regardless of the legitimacy
of the hits they receive.

I doubt the customer would be too happy if your peering policy suddenly
tripled their bill.


  Clarify... right now, many organizations with high-speed connections
  to the Internet pay based on usage (including traffic sent). Doesn't
  anyone on a usage-sensitive leased-line connection pay based on the
  traffic regardless of the "legitimacy" of the hits received? Isn't
  this why we all hunt down SMURFers?


Everytime we have been SMURFed BBN/GTEI has been unwilling to do anything
to help us. Either filters or aiding in hunting down the SMURFer. My
experience is BBN doesn't help it's customers trace down SMURFers.

Strange... I see tickets opened and worked on for these events;
it's certainly the case that we work them when notified. If you
forward me email from the last time this happened, I can hunt down
the confusion.


helpful in trying to track down the source of smurf attacks when we've
reported them. Much, much better than other providers who flat out refuse
to do any tracing because of "technicial problems with their routers".
Others on my helpful provider list are ANS, Digex and Epoch.

Brandon Ross Network Engineering 404-815-0770 800-719-4664
Director, Network Engineering, MindSpring Ent., Inc.
                                                            ICQ: 2269442

Stop Smurf attacks! Configure your router interfaces to block directed
broadcasts. See for details.