[e2e] Open the floodgate
Cannara
cannara at attglobal.net
Sun Apr 25 11:53:35 PDT 2004
Sam,
I agree that ECN may be incomplete too! As far as not seeing timeouts, I'm
afraid the real traffic I've seen on commercial nets actually has run into
timeouts often, much as that example quoted earlier where a <1% loss generated
a >25% slowdown. In any case, even a timeout shouldn't trigger a gross
response. Of course, parameter adjustments can be made, but surprisingly few
people feel able to do so. The bind remains over-
reaction and lack of information on what reaction is actually best.
Alex
Sam Manthorpe wrote:
>
> On Sun, 25 Apr 2004, Cannara wrote:
>
> > Sam,
> >
> > Apparently there's great bias against Source Quench because it requires a
> > packet be successfully sent in the reverse direction, but that's not such an
> > unreasonable thing anyway, given the congestion complained about is opposing.
> > TCP already provides that via a Window=0 statement back to the sender (which
> > is like what ECN can trigger).
>
> I believe there's no algorithm defined on what it should actually do :-)
>
> >
> > The reason 99% of congestion is handled by TCP's naive shutdown is, of course,
> > because it's so nonlinear, like Chicken Little. If all flows experiencing
> > even the slightest loss go back to Slow Start, of course 'disaster' has been
> > averted. This odd concept of a "control system" is like an automotive cruise
> > control that jams on the brakes when speed goes over the set point.
>
> Au contraire. Most of the time (~ 90%) loss is dealt with by fast-retransmit,
> which doesn't jam on the brakes, but eases off on the gas. The brakes
> only get jammed on when you hit timeout, which is far less common. Then
> the "self clocking" mechanism does a pretty good job of keeping loss low
> (check your netstat -s). Seems like a fairly effective control system.
>
> Cheers,
> -- Sam
More information about the end2end-interest
mailing list