Re: bug

[Renato Lo Cigno <locigno@CS.UCLA.EDU>]

> 
> 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.

We think on this point we all agree. 

> > 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.

Don't worry! As a general rule we never got with ECN results worse
than with RED alone, apart from possible "statistical fluctuations".

> 
> >
> > 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?)
We are using TCP-Reno, unidirectional connections (sink receivers, not
full TCP). We assume a "bad" performance, when ECN does not give an
advantage (measurable!) over RED, while a "good performance" means we
can measure an advantage (either loss rate, throughput, fairness, ...)
over RED. 


> 
> 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.

We think you have a point there, but that is not the focus of our
research. We are trying to understand how ECN works, what are the
conditions where it gives clear advantage, how difficult it is to tune
RED parameters, etc. Hence we did not concern ourselves with mixed
traffic. 

As far as point b) is concerned, I agree, but only to a given point. 
Indeed there is a problem when end system do not
co-operate, but, as far as I know, there is no way to cope with them
unless some "ad hoc" solutions are sought, maybe monitoring single
flows. What happens if the non co-operating end-system just avoid the
transmission window reduction when a packet is lost? (some people tell
that there are these kind of fraudolent TCP versions around). 
The idea of punishing everybody because some connections are non
co-operating sounds a little "unfair", although there is a point where
the network must protect itself, regardless of fairness. 

We think you're right if you're thinking about deploying a RED-ECN
router in a network, but performance analysis via simulation
fortunately allows you to forget about fraudolent hosts!

> 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.
We did not observe this "transient" phenomenon, specially if the high
threshold is not very high. We found some problems in defining what
the "appropriate" value of RED thresholds and parameters is, specially
in environments where the number of active connections and the
propagation delay change. We did not think about dynamically adjusting
the parameters and we think that such a solution will have great
stability problems. 

> >
> > 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.

Why not using the same discrimination above the high threshold? It
seems you have a reason, but we do not understand it completely. 

In any case we find this discussion very interesting!

Thanks for sending explanations and comments.

Renato, Wenjie.