General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Albert Rafetseder <albert.rafetseder+bufferbloat@univie.ac.at>
To: bloat <bloat@lists.bufferbloat.NET>
Subject: Re: [Bloat] Designer of a new HW gadget wishes to avoid bufferbloat
Date: Mon, 12 Nov 2012 09:03:20 +0100	[thread overview]
Message-ID: <49104739-8041-4BB9-84E8-A5A5398FC716@univie.ac.at> (raw)
In-Reply-To: <1210270249.AA18154@ivan.Harhan.ORG>

> Yes, I know how ring buffers work. :-)

No offense meant :-)

>> The trick is now to push the read =
>> pointer forward a bit instead of holding back the write pointer.
> 
> Can't do that: the ^r pointer will normally point at some cell in the
> middle of a packet being transmitted.  Jerking that pointer forward
> will cause us to transmit garbage consisting of partial packets, which
> is the last thing we want.

As it turns out from your answer to Jonathan, we were talking about the same (kind of) implementation, i.e. keep additional information on the start cells of packets, advance the read pointer systematically if needed, so as not to stop transmitting in the middle of packets, etc.

To save you the additional ring buffer, the starts-of-packets information could be stored as a length or number of cells field in front of the stream of cells of one packet. In a 46kibibit RAM, this will consume 3-4 cells' worth of data as overhead.

> But we still have to have tail drop (or my
> "modified tail drop") as the backup packet drop mechanism that
> protects the integrity of the ring buffer.  I guess the trick is to
> design the AQM policy such that it does most of the job and the
> out-of-buffer packet drop mechanism is rarely exercised.

"Caudal" (near tail / tail-side) drop? I wonder if it suffices to head-drop more than one packet's worth of cells if required to keep the read and write pointers sufficiently far apart. With a buffer of less than four Ethernet MTUs, what's the worst case really?

I'll need to get myself an envelope to scribble on...
  Albert.
-- 
Albert Rafetseder BSc. MSc.
Member of Scientific Staff

University of Vienna
Faculty of Computer Science
Research Group Future Communication
(Endowed by A1 Telekom Austria AG)
Waehringer Strasse 29/5.46, A-1090 Vienna, Austria

T +43-1-42777-8620
albert.rafetseder@univie.ac.at
http://www.cs.univie.ac.at/fc





  reply	other threads:[~2012-11-12  8:03 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-27  2:49 Michael Spacefalcon
2012-11-12  8:03 ` Albert Rafetseder [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-11-18  0:53 Michael Spacefalcon
2012-10-26 18:54 Michael Spacefalcon
2012-10-26 19:56 ` Jonathan Morton
2012-10-26 21:45 ` Albert Rafetseder
2012-10-14  3:41 Michael Spacefalcon
2012-10-22 15:58 ` Albert Rafetseder

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

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to=49104739-8041-4BB9-84E8-A5A5398FC716@univie.ac.at \
    --to=albert.rafetseder+bufferbloat@univie.ac.at \
    --cc=bloat@lists.bufferbloat.NET \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox