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.
Owen
Owen,
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?
/John
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.
/John
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. info@mindspring.com
ICQ: 2269442
Stop Smurf attacks! Configure your router interfaces to block directed
broadcasts. See http://www.quadrunner.com/~chuegen/smurf.cgi for details.