As I said before, at this position in the datastream, a BCU can only
throttle TCP based applications (like for example SMTP messages going out
and POP3 download data coming downstream) because TCP waits for ACKs to come
back after it has sent a certain number of packets. If they come back
delayed because the BCU delayed the outgoing packets as part of its job (or
has thrown away some if the burst limit was reached), further packets will
be sent with delay - this makes it adapt to the given max speed for any
medium.
UDP and all other IP protocols are different, though: if there is nothing in
the application implemented by a particular UDP protocol that causes a wait
for a response, the BCU will not stop your CPE from sending 1000 packet's
per second towards the base, regardless whether the BCU will drop them later
or not.
Conclusion: a BCU in the pictured position will not stop a malicious or
hacked customer from bringing your wireless net to a grinding halt if, for
example, he got infected with the slammer worm which is sending UDP packets
as fast as it can to port 1434 and even stops gigabit nets. And it will also
not stop two CPEs at the same base from talking to each other (as in a local
VPN scenario).
This is why we favored the Linux TC client - it permits control over the
outgoing data stream at the CPE. As Kevin said, the TC built-in throttling
works both ways which means that one would have to choose the higher speed
for asymmetric services leaving the upstream throttling to a distant BCU
which is only effective for TCP.
As a result, we have higher CPE cost for customers with lower priced
asymmetric services. Not good.
Kind regards,
--
true global communications GmbH
Thomas Giger
In der Au 27, 61440 Oberursel, Germany
fon +49.6171.6381-0, fax +49.6171.6381-19
www.tgnet.de || www.megaspeed-internet.de