Date: Sat, 8 Sep 2007 23:16:35 -0700 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Joao Barros" <joao.barros@gmail.com> Cc: freebsd-questions@freebsd.org Subject: RE: ADSL Bandwidth Monitoring Message-ID: <BMEDLGAENEKCJFGODFOCAEGACAAA.tedm@toybox.placo.com> In-Reply-To: <70e8236f0709081933k5f2352d2y389c6e2bb7599b16@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-freebsd-questions@freebsd.org > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Joao Barros > Sent: Saturday, September 08, 2007 7:33 PM > To: Ted Mittelstaedt > Cc: freebsd-questions@freebsd.org > Subject: Re: ADSL Bandwidth Monitoring > > > On 9/8/07, Ted Mittelstaedt <tedm@toybox.placo.com> wrote: > > > > > > > -----Original Message----- > > > From: owner-freebsd-questions@freebsd.org > > > [mailto:owner-freebsd-questions@freebsd.org]On Behalf Of Amitabh Kant > > > Sent: Saturday, September 08, 2007 12:25 PM > > > To: Bahman M. > > > Cc: freebsd-questions@freebsd.org > > > Subject: Re: ADSL Bandwidth Monitoring > > > > > > > > > On 9/8/07, Bahman M. <b.movaqar@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BMEDLGAENEKCJFGODFOCAEGACAAA.tedm>