Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Apr 1998 17:52:44 -0400 (EDT)
From:      Glen Foster <gfoster@gfoster.com>
To:        chrism@keyworld.net
Cc:        Anthony.Barlow@europe.simoco.com, freebsd-isp@FreeBSD.ORG, freebsd@plinet.com
Subject:   Re: Bandwidth limiter for services?
Message-ID:  <199804062152.RAA10319@gfoster.intr.net>
In-Reply-To: <199804062104.XAA27968@mail.keyworld.net> (chrism@keyworld.net)

next in thread | previous in thread | raw e-mail | index | archive | help
Is this really the case?  Dennis has been reluctant to describe the
mechanism of his bandwidth manager but hints he has dropped on this
and other FreeBSD lists indicate that they use a "strategically-timed
ACK delay" mechanism to limit bandwidth rather than dropping packets.
Basically, they ack as fast as the bandwidth limit allows given the
size of the associated queue.

Obviously, this adds a little or a lot of latency, more when the
bandwidth limit is approaching, but this is not unlike the way a
partially-meshed network "looks" to a sender as it approachs
saturation and it conserves aggregate bandwidth better than an
aggressive discard strategy does (at least as long as the ACK delay is
shorter than the retransmission timeout).

This is speculation on my part based on scanty evidence.  I wish
Dennis would 'fess up and describe the logic behind his code in this
forum.

Glen Foster <gfoster@gfoster.com>

>From: "Christopher Martin at Home" <chrism@keyworld.net>
>Date: Mon, 6 Apr 1998 23:08:02 +0200
>
>I suggest that you check it out though. I think it works by dropping
>packets. If it does the pipe might be filled by stuff that is already
>downloaded. This might result in unaccepttable amount of retransmissions
>from source.
>
>So you would not be really saving bandwidth...

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-isp" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199804062152.RAA10319>