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

Re: drop levels with trTCM





CCed to the ECN interest mailing list

On Sat, 12 Feb 2000, Petri Mattila wrote:

> >Assuming you have more than one input interface going towards an egress
> >interface, then the possibility of overloading teh egress interface is
> >there (fan-in problem). I suppose a little engineering would help; but in
> >the worst case you can let GRED+CBQ handle the drops.
> 
> What if ECN is used, I guess then the only place to drop/notify
> is in GRED, assuming it knows about ECN...
> 

;-> tough question. 
Notification is by marking for ECN capable flows.
Within the AF virtual queue however, you still have drops based on the 
virtual queue occupancy. i.e a higher precedence packet will get
priority regardless of whether it is ECN capable (or not).
Now the hard part is the fact that decision to drop for a paricular color
is also influenced by ECN marked packets which are still sitting on the
queue.
Imagine rate limiting DPx (to a very small rate) and say you have equal
number of ECN and non-ECN packets for DPx coming in. And say the packets
are not going out as fast as they are coming in. At some point, the DPx VQ
is fully occupied by ECN packets. The decision to drop incoming
packets which are not ECN is based (unfairly it seems to me) on a queue
occupied by ECN packets. One could argue that this problem will be minimal
if the end systems conform to the notifications i.e an equilibrium point
is reached very fast.

I'd like to hear what KK and Sally have to say about this.

cheers,
jamal

PS:- Petri, I was hoping to run tests along this line in the near future.
You are welcome to join (but if we start any time soon, you'll end doing
most of the work ;->)