Jerry - 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. Sean.
Sean, I am not so sure that policing is impossible. If the peer has machines that can you can do traces from, and choose random test times and deestinations, you should be able to get a long way. This could be faked, but it gets you up to the point where reasonable trust could win. You could put a cheap colo machine in their site under some anonymous name and test that way. It doesn't seem like nearly the problem to me of getting the more specific routes. Your problem of the colo doing nasty things by fooling TCP congention control is true, but I don't see anything specific to colo in this. Not to pick on them, but BBN could do this just as well as the colo (in both cases, you don't own the source machine.) Also, where you enter someone else's network with packets, which was what I was focusing on, doesn't change this. The people doing this are also likely the people trying to freeload on traffic differential as well, IMO. You ask what do you do when something related to this breaks? My simple answer is you fix it. I again don't see how this changes anything very much from the current situation other than possibly adding something else to break. I said in my mail that MEDs won't do it, and you agree. So what are the risks and benefits of provider agreeing to send more specific routes at maybe the POP level to a peer that wants to give them a traffic break? How would you go about doing this? jerry
participants (2)
-
Jerry Scharf
-
Sean M. Doran