ADSL Bandwidth Monitoring

[Ted Mittelstaedt]

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Joao Barros
> Sent: Saturday, September 08, 2007 7:33 PM
> To: Ted Mittelstaedt
> Cc: freebsd-questions at freebsd.org
> Subject: Re: ADSL Bandwidth Monitoring
>
>
> On 9/8/07, Ted Mittelstaedt <tedm at toybox.placo.com> wrote:
> >
> >
> > > -----Original Message-----
> > > From: owner-freebsd-questions at freebsd.org
> > > [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Amitabh Kant
> > > Sent: Saturday, September 08, 2007 12:25 PM
> > > To: Bahman M.
> > > Cc: freebsd-questions at freebsd.org
> > > Subject: Re: ADSL Bandwidth Monitoring
> > >
> > >
> > > On 9/8/07, Bahman M. <b.movaqar at adempiere.org> wrote:
> > > > I tested the connection by downloading 2~3 files
> simultaneously and used
> > > > 'bmon' as Mel suggested in another reply (thanks to him).  As I'd
> > > > already guessed the RX don't get bigger than 30~40% of the expected
> > > > bandwidth.  I performed the test with some other files and
> there was no
> > > > difference.
> > > >
> > > > Thanks,
> > > >
> > > > Bahman
> > >
> > > The bandwidth being advertised by your ISP would be the maximum
> > > thoughput allowed on your DSL lines with multiple DSL users sharing
> > > the same bandwidth, something that is generally known as contention
> > > ratio.
> >
> > Rubbish.  I work for an ISP and this is nonsense.  DSL is not a
> > shared medium until it gets to the ISP and the ISP should be able
> > to handle full rate circuits internally.
>
> >From the customer to the DSLAM it's a copper pair.

No contention on that.

> If the DSLAM is far
> from the ISP backbone you have a shared connection. That's where
> contention is applied.

No, sorry.  There's not that many different types of DSL that are
deployed simply because there's only a handful of companies out there
that manufacture DSL chipsets, and DSLAMS.

Virtually all DSLAMS that are out there use an ATM cell circuit
from the DSLAM to the ISP.  Fujitsu for a while was making frame-relay
based DSLAMS but telcos finally stopped buying them and nobody is using
them now.  The ATM connection uses either variable speed bitrate or
unspecified bitrate.  Not "committed bitrate" that is used for voice
circuits through an ATM network.

The reason for this is that all telcos these days use ATM switches
to carry voice calls - ATM was a standard dreamed up by the telcos
specifically for carrying phone calls.

When DSL was first dreamed up it was thought that to save money on
backend fiber costs that the telcos could use smaller pipes and
introduce contention.  That is why ubr and vbr encapsulations
were selected instead of cbr.

However, the thing that most people (who don't work at telcos) do not
understand is that the telcos found very quickly that they cannot put
contention into an ATM network comprised of a DSL atm circuits for a
very simple reason.

The ATM cell is a fixed 56k bytes.  The majority of Ethernet packets
once a TCP stream gets going and has adjusted it's sliding windows
are close to 1400 bytes long.

Now, imagine what happens to an ATM cloud when you program the ATM
switch that the cloud resides in to introduce contention into the
cloud.  The ATM switch does this by dropping ATM cells in all the
ubr and vbr ATM circuits that traverse the switch.

As a result, you start missing 56 byte packets in your ATM stream
that the DSL is riding on.

If the sender and receiver were using 56 byte MTU's this would be
no problem.  A missing ATM cell would cause a retransmit of the
TCP/IP packet and would be handled by the TCP protocol.

But since the sender are receiver are using 1500 byte MTU's and
the TCP packets are almost that large, what ends up happening
is that even a small amount of contention in the ATM cloud will
cause almost every TCP packet to have bits missing in it - ie:,
to arrive with an invalid CRC and be discarded.

Worse, since the entire packet is missing the sender and receiver's
TCP stack has to retransmit the packet, loading the ATM cloud down
even more.

SO, the cost of discarding a single 56 byte ATM cell means the ATM
cloud will have to get another 1400 bytes of data retransmitted
through it.

It doesen't take a rocket scientist to see that introducing contention
into an ATM circuit carrying a DSL circuit will cause a massive increase
in traffic in the switch, and wipe out any gains from contention.
Furthermore, your customers will start dropping TCP connections without
reason, when the stacks get long series of 1400 byte packets one after
another that are corrupted.  And then calling you and bitching and
wasting your tech support time.

When the Telcos found this out they gave up on that idea.  DSL circuits
today that traverse any ATM cloud -as virtually all of them do since
virtually all telcos use ATM backbones in their DSL networks - cannot
have contention introduced into them by the Telco.

Even the practice of delaying ATM cells causes the same problems
because you cannot introduce enough delay for the packet reassembly
process in the DSL modem and the DSLAM to actually show latency on
the entire packet, without damaging it.

 If for example he has 10mbits downstream
> contracted and there are several "power" users hitting the same DSLAM
> and the link to the ISP isn't big enough...
>

The link from the telco to the ISP is going to be ATM if the Telco
uses an ATM backbone and the same problems with contention apply.
The ISP simply cannot introduce contention into that circuit - they
MUST buy an ATM circuit from the telco that is fatter than the
peak bandwidth that their DSL users are pulling.

The ONLY place the ISP can introduce contention is by dropping
or delaying ENTIRE tcp frames in their equipment somewhere.  If
their upstream connections are point-to-point circuits that use
a 1500 or 1600 MTU then they can overload the circuit and
cause their upstream feed to drop packets, as a way of introducing
contention.  If their upstream connections are ATM or other circuit
that has a smaller MTU than 1500 then they cannot do this - they
have to introduce bandwidth limiting (ie: traffic shaping) in their
routers.

OR they have to hard-wire the PVC at their router port going to the
DSLAM network for each customer to lower than the customers DSL
modem is synchronized at - so that the router's packet disassembly
routines can see the lower speed and not accept incoming TCP packets
from the upstream at a higher rate than the PVC is tied to before
disassembling them and sticking them into atm cells and sending them
out the PVC.

But the OP said his ISP said they had NOT restricted the port to him,
lower than 1.5M

That is why I said for the OP to test with a personal webserver
page at his ISP then go from there.

My guess is his modem is not synced at 1.5M for whatever reason.
That is the most common problem for a speed loss between the
ISP and the customer on a DSL line.  If it WAS telco contention
the OP would be seeing disconnects and other side effects that
are much worse than the decreased bandwidth.

> > He should be able to get max bandwidth from his home system to his
> > ISP's system.  All our customers can. Beyond that, from his ISP to
> > the rest of the world
> > that is a different story.  But he needs to get the bandwidth correcte
> > dbetween himself and his ISP first.
>
> He should be able to get max bandwidth but not every ISP in the world
> has link bandwidth allocated for all their customers. Example: you
> have 100 customers with 10mbits contracted downstream. Think every ISP
> out there will have a 1Gbps link from the DSLAM to the backbone? Most
> definitely not. The same happens for mail servers. Do you believe
> every ISP has enough storage space to hold the advertised email
> storage space to their total number of customers? Most definitely not.
>

ISPs (at least, good ones) do not deliberately seize circuits smaller
than the peak bandwidth used, in order to introduce artificial contention or
bandwidth limiting.  There are bad side effects to do this and it
is very amateurish.  Maybe your brother Clive does it out in Podunkville
in Tennesseee, but it's not done like this by most people.

What is done is the circuits are seized for a comfortable margin above
NORMAL peaks.  Then bandwidth limiting restrictions are placed into
the network that are a bit higher than normal peaks.  These are safety
valves that in the event the customer base all decides to listen to
the president's speech at 5pm some evening, that it doesen't melt the
network.  But in normal operation they do not institute limiting.  And
a single customer pulling 1.5Mbt isn't going to even be noticed in a
large DSL network nor cause the average to exceed the limiters.

Ted