Re: Extreme congestion (was Re: inter-domain link recovery)

[Stephen Wilcox <steve.wilcox () packetrade com>]

On Thu, Aug 16, 2007 at 10:55:34AM +0100, Alexander Harrowell wrote:
>    An "Internet variable speed limit" is a nice idea, but there are some
>    serious trust issues; applications have to trust the network implicitly
>    not to issue gratuitous slow down messages, and certainly not to use them
>    for evil purposes (not that I want to start a network neutrality
>    flamewar...but what with the AT&T/Pearl Jam row, it's not hard to see
>    rightsholders/telcos/government/alien space bats leaning on your upstream
>    to spoil your access to content X).
>
>    Further, you're going to need *very good* filtration; necessary to verify
>    the source of any such packets closely due to the major DOS potential.
>    Scenario: Bad Guy controls some hacked machines on AS666 DubiousNet, who
>    peer at AMS-IX. Bad Guy has his bots inject a mass of "slow down!" packets
>    with a faked source address taken from the IX's netblock...and everything
>    starts moving Very Slowly. Especially if the suggestion upthread that the
>    slowdown ought to be implemented 1-2 AS away from the problem is
>    implemented, which would require forwarding the slowdowns between
>    networks.
>
>    It has some similarities with the Chinese firewall's use of quick TCP RSTs
>    to keep users from seeing Bad Things; in that you could tell your machine
>    to ignore'em. There's a sort of tragedy of the commons problem - if
>    everyone agrees to listen to the slowdown requests, it will work, but all
>    you need is a significant minority of the irresponsible, and there'll be
>    no gain in listening to them.

sounds a lot like MEDs - something you have to trust an unknown upstream to send you, of dubious origin, making unknown 
changes to performance on your network

and also like MEDs, whilst it may work for some it wont for others.. a DSL provider may try to control input but a CDN 
will want to ignore them to maximise throughput and revenue

Steve