This is a multi-part message in MIME format.
--------------000703010507000003050500
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
it's worse than that. we faced the same problems in china. an
oversubscribed adsl system. in fact there is more than one problem with
the public internet in these scenarios. the first as you have identified
is the lack of capacity. then you can't control the downstream routing -
eg traffic from china to australia was going to the west coast us, then
to florida and finally back to australia via a different gateway in la!
some of the routers along the way have large buffers meaning that they
can introduce significant delays into the transmission. and finally when
all these things overflow you get large packet loss - up to 50% at some
times.
the net result is this: high packet loss means forget about real time
services such as voip or video conferencing. they are asynchronous
services that don't retransmit and are also not very tolerant of packet
loss (over about 10%). long ping times means that synchronous services
such as email are very slow, coupled with packet loss you might as well
be on a dial up.
our solution in a commercial environment was to keep upgrading until we
found a service level that works (more or less). we moved from adsl to
fibre. found an isp at each end that we could talk to and who could give
assistance with routing issues. eg if they have multiple gateways we
experimented until we found the most efficient gateway.
we also know of larger comapnies who pay substantial fees to achieve end
to end qos.
all of this means there's not a lot you can do at your end with limited
choices except to accept that there is no bandwidth at some times of the
day and go have a beer instead :)
regards
rick
Chris Bennett wrote:
> Quick answer is: you can't. You need to know the bandwidth so that
> you can control the queue.
>
> You bring up some interesting theoretical ideas about monitoring the
> overall congestion level and forcing back-offs when you sense that
> you're reaching the current level, though. That would sort of involve
> dynamically adjusting the shaping rules. As far as I know there is
> nothing in existance that does this, but its an interesting idea to
> think about. If you were going to try something like this I think
> you'd need some sort of reliable indicator of what the current
> congestion is like... perhaps some steady ping to use as your "canary
> in the coal mine". Then set up several shaping scripts that assume
> different levels of bandwidth, and depending on the current "canary
> ping", either upgrade or downgrade your assumed bandwidth by calling
> the appropriate script. So I guess if you wanted to try this, maybe
> you could set up three scripts, one set to 80% of your bandwidth, one
> set to 50%, and one set to 20%. Then set up a cron job that checks
> the "ping" for your high priority traffic, and calls the
appropriate
> script to adjust. I doubt it'll work, but it could be an interesting
> experiment.
>
> ----- Original Message ----- From: "Justin Schoeman"
> <justin@expertron.co.za>
> To: <lartc@mailman.ds9a.nl>
> Sent: Thursday, November 25, 2004 3:17 AM
> Subject: [LARTC] Shaping traffic on heavily oversubscribed links?
>
>
>> Hi all,
>>
>> I am having some fun with traffic shaping, and have run into an
>> interesting situation. Here is South Africa, most internet links are
>> heavily oversubscribed, which means that in most cases the local link
>> is _not_ the bottleneck, and shaping on the local link does not help
>> that much...
>>
>> Does anybody have some tips on shaping such links? How can you get
>> interractive traffic if you don't know how much bandwidth to reserve
>> for it? How can you give fair access to a link if you don't know what
>> the link capacity is?
>>
>> Are there perhaps some tools to monitor retransmissions to try and
>> determine congestion levels, and from that adjust shaped bandwidth?
>>
>> Am I perhaps missing something simple in this scenario?
>>
>> Thanks!
>> -justin
>> _______________________________________________
>> LARTC mailing list / LARTC@mailman.ds9a.nl
>> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
>>
>
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
--------------000703010507000003050500
Content-Type: text/x-vcard; charset=utf8;
name="rjm.vcf"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="rjm.vcf"
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
--------------000703010507000003050500--