[e2e] [Fwd: RED-->ECN]
Christian Huitema
huitema at exchange.microsoft.com
Thu Feb 1 11:38:34 PST 2001
My specific suggestion would be to start using linear increase (increase
the window by a constant x for each Ack) instead of the sublinear
increase we have now (increase by 1/W), for the high speed connections
(e.g. when W > 40). We can tune the constant "x" so that the increase at
the threshold point (W=40?) is equal on both sides of the threshold
(e.g., x=1/40). The behavior would remain exactly the same in the case
of high error rates, but we would gain better control in the case of low
error rates. Then, the application designers would not be forced into
"optimisations."
-- Christian Huitema
> -----Original Message-----
> From: Bob Braden [mailto:braden at ISI.EDU]
> Sent: Thursday, February 01, 2001 11:18 AM
> To: J.Crowcroft at cs.ucl.ac.uk; Christian Huitema
> Cc: end2end-interest at postel.org
> Subject: RE: [e2e] [Fwd: RED-->ECN]
>
>
> *>
> *> Jon,
> *>
> *> Yes, we could indeed decide that penalizing long
> sessions is a good
> *> thing. But, guess what, the guys writing the download
> applications are
> *> no dummies. If they observe that
> *> loop until EOF
> *> open connection
> *> go to current file location
> *> get an additional 5 megabytes, or the rest of the file
> *> if less
> *> ... gets then better performance than just "open a
> connection and get
> *> the file," guess what they will do? Indeed, you could
> call that an
> *> intelligence test -- smart elephants morph into mice,
> the other ones go
> *> the way of the dinosaurs. But then, why are we bothering
> writing complex
> *> requirements for TCP?
>
> Christian,
>
> Unhh, maybe because the Internet is heterogeneous, and some
> parts of it will always have 4% loss rates rather than .01%?
>
> It is unclear whether your interesting observation is a bug,
> as you suggest, or rather a feature that results from the
> basic packet physics. Why is it a bad thing if users can
> optimize their service by opening multiple TCP connections?
>
> Bob Braden
>
>
More information about the end2end-interest
mailing list