[e2e] Interpretation of ECN as a less severe congestion signal

[Ongun Yucesan]

 I would like to ask for RED Parameters,

 What if ECN Marks the packets again like

 minThresh <= queue length < maxThresh: mark packet
 maxThresh <= queue length: drop packet

 But linterm in ns or the slope of the discarding chosen to be more
 aggressive just for marking, while still remaining the same for dropping,

 And using the beta = 1/4 or some binomial cong. cont. with parameters
closer
 to the TCP for example k=0.3, l=0.7 with beta=1/2,


 Ongun Yucesan
>
>
>
> ----- Original Message -----
> From: "Michael Welzl" <michael.welzl at uibk.ac.at>
> To: <ecn-interest at research-att.com>; <end2end-interest at postel.org>
> Sent: Monday, July 01, 2002 10:06 AM
> Subject: [e2e] Interpretation of ECN as a less severe congestion signal
>
>
> > Hi all,
> >
> > Just out of curiosity:
> >
> > Why is it that the semantics of an ECN flag were not defined
> > as a LESS severe congestion signal than a dropped packet?
> > For example, a sender could reduce the rate by 1/4 instead
> > of 1/2 in response to an ECN flag; this way, ECN would provide
> > MORE instead of complementary information.
> >
> > Router behaviour would then be:
> > minThresh <= queue length < maxThresh: mark packet
> > maxThresh <= queue length: drop packet
> >
> > I assume that this can't be changed now because the behaviour
> > in routers needs to be uniform - but I like the idea ... it's
> > simple, and it should be better ... it's well known that the
> > rate reduction factor (beta) could be higher than 1/2 and the
> > AIMD idea would still be preserved.
> >
> > I've seen this idea in the Multilevel ECN proposal by Arjan
> > Durresi, Jain et al (somewhere on Raj Jain's publications site).
> >
> > Cheers,
> > Michael
> >
> >
>