BBN peering, a technical issue
Sean M. Doran
smd at clock.org
Sat Aug 15 16:55:03 UTC 1998
The problem boils down to making traffic move the right way,
and making sure the traffic is well-behaved.
The biggest problem with using MEDs to attract traffic to the
right places, in your model, is simply route aggregation.
The next-biggest -- and less immediately soluble -- problem
is policing the MEDs. How do you tell whether your rival
is obeying your MED announcements faithfully, and what do you
do when they don't? (Conversely, how can you tell if the MEDs
are being fair to you?)
There are other small issues involving what happens in
the face of failures -- peering routers crash, peering
infrastructure fails, people mess up configurations, etc.
In other words, even if you design for traffic going the
right way, sometimes it doesn't. What do you do then?
Finally, my own concern is what happens if the big
colo site ends up playing with devices which deliberately
over-ack -- adding fractional ACKs into the stream
coming back from web browsers -- and other techniques
for opening the congestion window larger or faster than
it should be opened, or otherwise sending traffic that
does not back off in the face of congestion in your network.
It would be ironic if a business race was triggered by
people deliberately breaking congestion-avoidance.
"Come buy colo from us -- your web pages will seem faster
even than web pages on our peers' networks!" would be
pretty bad. I say bad not for business reasons, but because
TCP's timers and other congestion-avoiding mechanisms
are *THE* key mechanism for stability in the Internet.
Classic congestion collapse would not be nice for anyone.
More information about the NANOG