All of lore.kernel.org
 help / color / mirror / Atom feed
From: don-lartc@isis.cs3-inc.com (Don Cohen)
To: lartc@vger.kernel.org
Subject: Re: [LARTC] SFQ improvement ideas
Date: Mon, 14 Jan 2002 22:33:38 +0000	[thread overview]
Message-ID: <marc-lartc-101104790232255@msgid-missing> (raw)
In-Reply-To: <marc-lartc-101094979511667@msgid-missing>

 > 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
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://ds9a.nl/lartc/

  parent reply	other threads:[~2002-01-14 22:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-13 19:21 [LARTC] SFQ improvement ideas devik
2002-01-13 21:06 ` John Huttley
2002-01-13 21:10 ` Daniel Wittenberg
2002-01-14  2:02 ` John Huttley
2002-01-14  4:23 ` Daniel Wittenberg
2002-01-14  5:13 ` Don Cohen
2002-01-14  9:35 ` Martin Devera
2002-01-14  9:36 ` Martin Devera
2002-01-14  9:38 ` Martin Devera
2002-01-14  9:54 ` Martin Devera
2002-01-14 14:56 ` Michael T. Babcock
2002-01-14 22:33 ` Don Cohen [this message]
2002-01-16  9:46 ` Martin Devera
2002-01-16 10:07 ` Martin Devera

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-101104790232255@msgid-missing \
    --to=don-lartc@isis.cs3-inc.com \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.