[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug



As the discussion between Wenjie, Jamal and Renato indicates,
there is clearly things that you can do in the router that is
not specified in RFC 2481, and is subject to "interpretation" (or
at least creative exploration).
As we stated in the RFC,
"this document does not attempt to specify a
 particular mechanism for active queue management,..."
That said, it probably is still worthwhile to convey each other's
thinking on what might be appropriate, and experiment.

On Jan 29, 11:27am, Renato Lo Cigno wrote:
> Subject: Re: bug
> >
> >
> > On Thu, 28 Jan 1999, Wenjie Weng wrote:
> >
> > > Hi, we use ns-allinone-2.1b3 version. We found a bug in red.cc for
> > > ECN simulations. When average queue size exceeds maxinum threshold,
> > > the RED gateway drops packets. For ECN simulation, it should mark
> > > the packet instead of dropping it.
> >
> > The ns code is right.
> > RED should drop the packet; it marks only (instead of
> > dropping) when between maximum and minimum threshold.
> >
> > cheers,
> > jamal
> >
> > Computing Technology Labs (CTL), Nortel
> >
> Hi,
>
> let me just try to clarify the matter a little.  First of all the
> term "bug" is probably unlucky.
>
> What we were trying to point out, is that in RFC2481, there is no hint
> (correctly, that is concerned with the end hosts behavior, not with
> router queue management) to how the router marks or drops packets,
> although there is a clear indication that ECN should be used with RED
> routers or other routers actively managing the queue.
>
> We run sume experiments and we could not obtain good results with ECN
> unless the high threshold was set very high and we noticed that when
> the queue was above the high threshold packets were dropped.

I am worried about this statement. If you say that ECN yielded poor
results when the high threshold was not "very high", did you see
that not having ECN improved the results? I would hope not.

>
> We also noticed that, in an environmet with all ECN capable
> connections, marking ALL packets above the high threshold leads to
> good performance.

There is a question I have: marking ALL packets gives you "good
performance", but dropping packets above the high threshold does
not give "good results". How do you measure these, and what is
the environment (with Reno; Sack?)

On the one hand, I would say that marking rather than dropping packets
is desirable. On the other hand, I believe that it is important to keep in mind
at least a couple of things that we cannot control:
a) non ECN capable end systems; b) non-cooperative end systems;
So, with these in mind, if we mark all packets above the high threshold,
but not drop them, it is possible that we have a case where we're
marking packets of non-cooperative end systems which don't reduce but
instead other well-behaved flows to reduce their window.
Of course, I strongly believe that this is a transient, and will likely
result in our queue growing up to the max. causing packets to be lost
anyway. However, it seems to me that if we've set the RED parameters
and thresholds "appropriately", then going beyond the high threshold
should be infrequent. Dropping packets when operating above
the high threshold will likely help in combating non-cooperative users.

>
> What I would expect at this point, is that in a mixed environment a
> RED router will take the decision on wheter to mark or drop the packet
> based on its ECN capability and not only on the average queue length.
>
I would agree that this is true when operating between the low and
high RED thresholds.

> We just wanted to point out this fact and have more information (if
> available) about RED queue management with ECN.
>
> I hope I was reasonably clear. Let us know if we "missed" something in
> the process.
>
> Renato Lo Cigno
>
>-- End of excerpt from Renato Lo Cigno
          K. K. Ramakrishnan


-- 
K. K. Ramakrishnan                             Email:[email protected]
AT&T Labs-Research, Rm. A155                   Tel: (973)360-8766
180 Park Ave, Florham Park, N.J. 07932         Fax: (973) 360-8050
	URL: http://www.research.att.com/info/kkrama