Ed Wildgoose <lists@xxxxxxxxxxxxxx> writes: > You need something which works at IP level or above. TCP (level higher) has > some stuff, but (I repeat) it basically involves dropping traffic until the > sender slows down. There are protocols like ECN, but they are broadly > unsupported. ICMP stuff is frequently dropped by routers/firewalls making it > problematic (look at how difficult it is just to do MTU discovery!) ECN is largely there so that *non*-TCP protocols can implement congestion control like TCP does. The problem that was observed in DRUMS was that UDP based protocols like the various streaming audio/video protocols that have cropped up in recent years would push any TCP streams out of their way. Routers would drop UDP packets but most of them didn't throttle their bandwidth on dropped packets. And congestion control using dropped packets required every protocol to implement its own acknowledgement and windowing infrastructure. The goal was to have something simple that could be supported at a lower level. ECN on TCP connections is a bit superfluous. It could be used to throttle the bandwidth being used before it led to dropped packets, but it's unclear that would help any. Traditional TCP congestion control is fairly effective at grabbing all the available bandwidth anyways. ECN would be accomplishing largely the same thing that RED accomplishes at much greater expense on the router. Incidentally, ICMP Source Quench turned out to be a bad idea. Modern RFCs say hosts "SHOULD NOT" send them. The problem is that responding to congestion by sending more packets exacerbates the congestion. -- greg _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
