X-Mailer: Sylpheed version 0.9.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit (Resend) Hi Mike, On Fri, 30 Jan 2004 09:09:57 -0800 (PST) Michael Thomas <mat@xxxxxxxxx> wrote: > Now wait a minute. It's your bandwidth... shouldn't > you be _shaping_ his traffic if there's some reason > he shouldn't be using one path or another? And thus > provide negative feedback so that he has incentive > to use the path that you want him to use? After all, > the end consumer is likely clueless about your > network and is going to do whatever they can to > get what they're after -- bandwidth. Sounds to > me that if he's able to cause your bills go > through the ceiling _you're_ doing something > wrong. I guess Daniel's problem is not that simply solved. Just the shaping isn't enough, because the backup path should be fully used only when the main path has some "trouble". Moreover, "trouble" isn't also such a simple thing like a direct link failure, such as fibre cut, but it includes yet upper link(ISP)'s failure. This is not even a problem of "OK" or "Not OK". I mean, those cases are very likely to happen that you can communicate with only a few of ASes through the main path. So, though you may say "we can stop the shaping if we have troubles in the main path," it is not such easy. You have to change the bandwidth of backup path's shaping depending on the number of routes passed from main path's upstream ISP. I'm not familiar with BGP routing techniques that much, but I guess these policies can be implemented, right ? Though I believe end-to-end multihoming is the way to go, I don't have a good answer for this problem. -- /arifumi a@xxxxxxxxxxx