> From: Martin Devera <devik@cdi.cz> > > I have an alternative suggestion, which I think might profitably be > > added to a number of qdiscs: > > a parameter for the maximum delay allowed for forwarded packets > > When you dequeue a packet that is older than that (current time minus > > arrival time stamp) you drop it. > > It would be definitely nice. But it is not cheap to implement. > SFQ has constant complexity. To discard old packets you would need > either sorted queues (log N) or cycle on head of queue until all > expired ones are deleted. But it doesn't preserve fairnes IMHO. > In any way I'll think about it :) You're thinking of removing a packet when it has been in the queue too long. I'm thinking of something much easier. When you dequeue just check to see it's not too old. If it is then discard it and go on to the next one. I admit that this could result in a large amount of work for one packet dequeued, but that work translates into much more time saved by not sending old packets. > > > 2) Interactive traffic isolation > > > > > > Cisco IOS implements WFQ which has one queue per flow and > > > common queue for interactive traffic. Packets are queued > > > into interactive queue for some time and after it is clear > > > that they constitute large flow they are assigned private > > > queue. Interactive queue has higher prio. > > I was not aware of this distinction between interactive an other. > > How do you recognize interactive other than by low rate? > > Do you have a pointer to doc? > > it is better determined by bytes send. Hi-load traffic is for > example long ftp download.. I'm not sure how to detect them yet. > See www.cisco.com, IOS documentation, QoS section. I have looked there. Perhaps we simply interpret the contents differently. > > > Nice effect is that short conversations are handled faster > > > and long downloads are isolated with lower priority. > > Isn't this just what you get from a queue for each flow? > > I thought that's what WFQ did. > > No. For flows A,B,C,X where X is interactive one the nornal SFQ > schedule is: ABCDXABCDX.... and WFQ is AXBXCXAXBXCX.... Thus lower > delay. (Except for the D's I guess.) Again, where do you see this? I've not seen anything in Cisco doc that says this. > > > parameters like "hash " followed by set of "dip,sip,sport,dport,proto" > > > arguments (e.g. ... sfq hash dip sip dport). > > > > I agree (in fact was going to propose exactly this). > > The real use I see is that people keep asking for what amounts to hash > > only on one address (e.g., fair service to all internal machines). > > Fine. We can agree on this one. You did some things with SFQ, > could you implement it ? Maybe, but not immediately. > > > > --__--__-- > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc > > > End of LARTC Digest
