how-to block ads
|
Uniqs:
1115 |
Share Topic
 |
 |
|
|
2 edits |  Low % congestion #'s could still indicate problem though
As can be observed in the table above, the total percentage of all four types of congested network links during a given month in the period in question has varied between 2.6% and 5.2%. While these numbers may seem low to the average lay person, they are significant to network traffic engineers such that it is important to consider the number of congested links in the proper context. Those numbers are relevant in the context of interactive traffic. Also the percentages can be additive as a packet traverses different sections of the network. They are no problem if we are talking about batch file transfers.
see: »www.usenix.org/events/lisa00/ful···dex.html
Congestion and Circuit Capacity Planning
Like many organizations, we collect router statistics via SNMP every five minutes. While five-minute averages are a useful measure of how a circuit is doing in relationship to its bandwidth limit, they do not tell a lot about the instantaneous (one second, or smaller, time scale) state of a circuit that governs interactive performance. If a circuit is saturated for several ten-second bursts during a single five-minute period the average utilization might appear to be quite reasonable. An interactive user, however, would likely say that the network was slow while his packets were waiting in a router buffer. Since Bell of Canada was using 15 min snapshots and not even the inadequate 5 min snapshots, the low percentages could still mean that congestion is occurring and that interactive traffic is suffering.
It would be interesting to know if Bell also took shorter snapshots(say every second for short periods of time) to get a finer look at suspected congested links, thereby determining if interactive traffic had unusually high latency. Without that kind of data, the supplied stats aren't very persuasive.
But they are probably just supplying what the CRTC demanded and nothing more. Bell's network engineers would have performed other studies with shorter snapshot periods for their own use and the info they supplied to the CRTC also provided latency measurements(another measure of congestion).
This graph that Bell supplied the CRTC was much better at indicating the growing problem than the chart headlined in the BBR story:
--
My BLOG .. .. Internet News .. .. My Web Page | |
|   KrKHeavy Artillery For The Little GuyPremium
join:2000-01-17
Tulsa, OK
 ·AT&T DSL Service
| Re: Low % congestion #'s could still indicate problem though Bell's trying to win the argument that they are justified in throttling their competition's last mile customers.
They aren't, but if they lose the argument they will have to remove the throttling, so they are going to present evidence skewed any which way they feel they need.
--
"Regulatory capitalism is when companies invest in lawyers, lobbyists, and politicians, instead of plant, people, and customer service." - former FCC Chairman William Kennard (A real FCC Chairman, unlike the current Corporate Spokesperson in the job!) | |
|  milnoc
join:2001-03-05
H3B
kudos:1 | Here's my response to that particular chart, which I've already submitted to the CRTC.
quote:
We can clearly see a steady increase in cell loss between May of 2002 and September of 2007, which I would consider perfectly normal considering how quickly the popularity of the Internet has increased over the years. Then, in October of 2007, we see a sudden jump in the average number of cells lost, reaching three times the average cell loss of the first three quarters of 2007.
This spike in average cell loss seemed highly unusual until I noticed its sudden ascent began at about the time when Bell Canada began implementing traffic shaping technology on the network traffic of their own Sympatico subscribers. Could their own equipment be responsible for the sudden increase in cell loss?
Bell Canada's Network Cell Loss History chart may also have an inaccurate scale. The Total Cell Loss Events scale appears to represent the average total of lost cells per 24 hour period. If that's the case, taking into account the enormous amounts of data flowing through Bell Canada's network each and ever day, even a total loss of 4500 cells per day doesn't sound like it should become an issue, averaging at just over three cell loss incidents per minute.
I'm currently studying the latest data released by Bell and will send another response to the CRTC. | |
| | KrKHeavy Artillery For The Little GuyPremium
join:2000-01-17
Tulsa, OK | Re: Low % congestion #'s could still indicate problem though There's a good chance their own throttling equipment is causing the loss. Valid point. | |
|
 GuspazGuspazPremium,MVM
join:2001-11-05
Montreal, QC
kudos:16 | Consider that Bell likely pushes trillions of ATM cells per day, and that they're losing about 4500. They could be losing billions of ATM cells per day and the quality of service would still be unaffected.
Put this way, if you ran the "ping" program (one ping per second, let's say) constantly, you'd have to send (assuming 2 trillion cells per day, which might be underestimating their traffic volume, and 4500 loss events per day) about 45000000 pings before you would lose one due to an ATM cell loss.
Of course, that would take you a year and a half to do those pings. | |
| | | | Re: Low % congestion #'s could still indicate problem though The doesn't show the number of cells lost, but the number of times cell loss occurs. So, based on the graph, in Feb 08, they were reporting cell loss 4500 times per day. There is zero indication of how severe the loss was anywhere.
--
---
Over ten plus years of carrying The Clue Bat... | |
|
 mazhurgPremium
join:2004-05-02
Portage La Prairie, MB
·MTS
1 edit | The cell lost graph is useless in that it does not tell the story; not even part of it.
Like, This is total cell lost on a 24Hrs period over what traffic? If in 02 there was 1 Gig a day of traffic, and in 08 there was 1 TB a day of traffic, this would actually indicate that the total loss cell has actually decreased by a large amount relative to the total bandwidth transmitted.
This graph if only there because it shows a rising trend, but since there is nothing to benchmark it to, it is only there for dazzle and FUD. | |
| | | | Re: Low % congestion #'s could still indicate problem though Hammer, meet nail. You've nailed it.
As traffic flows increase, so does capacity. As capacity increase, so does the network size and complexity in terms of equipment and circuits. As the number of circuits and equipment increase, so do the number of errors and downtime events.
If they took the number of "cell loss events" and graphed them next to the increase in switch ports, interfaces, lambas and circuits they had, you would likely see the graphs parallel each other.
--
---
Over ten plus years of carrying The Clue Bat... | |
| | |  funchordsHelloPremium,MVM
join:2001-03-11
Yarmouth Port, MA
kudos:5 | Re: Low % congestion #'s could still indicate problem though said by NetAdmin1:If they took the number of "cell loss events" and graphed them next to the increase in switch ports, interfaces, lambas and circuits they had, you would likely see the graphs parallel each other. For the win!
--
Robb Topolski -= funchords.com =- Hillsboro, Oregon
HTTP is the new Bandwidth Hog...
| |
|
| | Here's the problem with their cell loss graph, it doesn't show the severity of the loss. Even momentary periods of congestion, that are not severe, due to things beyond saturated links, such as routing path changes, interface flaps or physical layer issues, will cause cell discards that would trigger their system. Congestion is not always due to the users downloading/uploading more than the network can handle.
As well, as their network has more capacity for the users connected, even the most minor interruption in the network can cause significant cell loss, but only briefly. For example, if a OC48 circuit at 50% utilization goes down for even a fraction of a second, many thousands of cells will be lost, causing retransmits that may cause temporary congestion as the link recovers.
What Bell needs to show is sustained congestion, on the orders of 30 seconds to a minute and up. Brief sub to few second bouts of congestion are vastly different than 30 second to minute plus bouts of congestion, which typically signal true network saturation.
--
---
Over ten plus years of carrying The Clue Bat... | |
|
| |
|
