All of lore.kernel.org
 help / color / mirror / Atom feed
* Time in Queue, bufferbloat, and... our accidentally interplanetary network
@ 2011-12-05  9:05 ` Dave Taht
  0 siblings, 0 replies; 20+ messages in thread
From: Dave Taht @ 2011-12-05  9:05 UTC (permalink / raw)
  To: bloat, bloat-devel, netdev, linux-wireless

I was tickled to see that expiring packets based on 'time in queue'
was already a
key design feature of the IPN,

http://www.science20.com/interwebometry/lessons_nasa_can_learn_internet-84861

and the idea was suggested also independently in saturday's CACM
article's comments...

http://queue.acm.org/detail.cfm?id=2071893


Making decisions based on time in queue (TiQ), rather than length of
queue, would
seem to be a win, especially for wireless, but also for  that does
'soft' traffic
shaping with HTB-like qdiscs and sub qdiscs. Anything that is not running
at GigE plus speeds would benefit.

... since basically what's been happening with bufferbloat is a too early
implementation of the IPN, with detours between here and the moon!

... and so far I haven't seen any major theoretical holes in with TiQ, except
for deciding as to how long is too long as to consider a packet as 'expired',
(which can be measured in ms or 10s of ms), and having reasonably
monotonic time.

I just wish I (or someone) could come up with a way to implement it in Linux
without multiple layer violations. skb->queuestamp has a nice ring to it, but
when I look at this portion of the stack I freely admit quivering in ignorance
and fear.

I did a bit of work on a set of timestamping fifos, but realized that
it was the
entire queue's duration from entrance to exit (through multiple scheduling
qdiscs) was what needed to be  measured, and the drop/no drop decision
needs to be made as late as possible - and preferably, the queue being
pulled from needs the next packet pulled forward so as to inform the
receiver that congestion is happening...

And Eric dumazet also produced a preliminary patch a few weeks back
that tied timestamping to before the head of a queue, but that tried to use a
reserved field in the skb that appears from points A to Z is not guaranteed
to be preserved.

Thoughts?

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2011-12-09 18:46 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-05  9:05 Time in Queue, bufferbloat, and... our accidentally interplanetary network Dave Taht
2011-12-05  9:05 ` Dave Taht
2011-12-05 10:59 ` Eric Dumazet
2011-12-06  2:03   ` Adrian Chadd
2011-12-06  2:03     ` Adrian Chadd
2011-12-07  9:59     ` Dave Taht
2011-12-07  9:59       ` Dave Taht
2011-12-07 10:15   ` [Bloat] " Hagen Paul Pfeifer
2011-12-07 10:15     ` Hagen Paul Pfeifer
2011-12-07 10:19     ` [Bloat] " Hagen Paul Pfeifer
2011-12-07 10:19       ` Hagen Paul Pfeifer
2011-12-07 11:53     ` [Bloat] " Eric Dumazet
2011-12-08 16:06   ` [PATCH net-next] sch_red: Adaptative RED AQM Eric Dumazet
2011-12-08 16:06     ` Eric Dumazet
2011-12-08 17:21     ` Stephen Hemminger
2011-12-08 17:21       ` Stephen Hemminger
2011-12-08 18:16       ` Eric Dumazet
2011-12-09 12:46         ` [PATCH net-next] sch_red: generalize accurate MAX_P support to RED/GRED/CHOKE Eric Dumazet
2011-12-09 18:46           ` David Miller
2011-12-09  0:55     ` [PATCH net-next] sch_red: Adaptative RED AQM David Miller

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.