& cplSiteName &
Comments
Newest First  |  Oldest First  |  Threaded View        ADD A COMMENT
<<   <   Page 3 / 12   >   >>
stephenpcooke
stephenpcooke
12/5/2012 | 1:50:44 AM
re: Siemens Sees Ethernet Everywhere
technonerd,

I don't think that arch_1 was talking about the connection costs but solely the equipment costs. You are right that the connection costs are substantially higher because a T1 is a regulated interface.

arch_1 is also right that the additional circuitry is not terribly expensive though to generate the negative voltages required by the snicket of the DS1 pulse template you need a negative power supply rail which entails a different power supply scheme than for Ethernet. The difference is still not $450. arch_1 is also correct that a good part of the cost is in the certifications, etc. required, however, this is also not sufficient to make up his quoted difference.

In general it comes down to the $300 hammer for the defense department-type scenario. If you can afford a dedicated T1 for your data you can afford $500 for the router interface.
Tony Li
Tony Li
12/5/2012 | 1:50:42 AM
re: Siemens Sees Ethernet Everywhere
The issue about cell overhead is on the wire, not internal to the system. Certainly switching fixed length cells has proven to be easier to build hardware for.

Tony
sgan201
sgan201
12/5/2012 | 1:50:42 AM
re: Siemens Sees Ethernet Everywhere
Hi Mr. Zippy,
When you ask the wrong question, you will never get the right answer. Question like ATM versus Ethernet always break down to is bandwidth cheap or expensive??

A) ATM is designed to provide abosulte QOS control in a situation where the traffic demand far exceed the uplink/trunk capability.

B) Ethernet is designed where the trunk bandwidth is higher than all the inputs.

Now, ask yourself a question, in the networking world, especially in the Wide Area Network, A occurs more frequently or B??

ATM has a 10% cell tax. But, you can run ATM trunk up to 90% utilization and guarantee QOS.

A Ethernet/POS trunk need to be run at 60% utilization or lower or you will incur severe Packet Queueing delay. So, there is a 40% tax with packet based trunk. By the way, typical tier 1 ISP run the trunk at average utilization of 40% or less.

Chopping packets into cells etc.. This is a non-issue anyhow. If cell is so bad why both Cisco and Juniper core router have a cell fabric??

Dreamer
mr zippy
mr zippy
12/5/2012 | 1:50:41 AM
re: Siemens Sees Ethernet Everywhere
Hi Dreamer101,

Firstly, I'll admit I don't have a lot of experience in the core of really big networks (largest I've worked in the core of had only 10 000 users, and it was a large enterprise network). I will point to documents that backup my points though.

Now, ask yourself a question, in the networking world, especially in the Wide Area Network, A occurs more frequently or B??

I personally don't know the answer to that question. I'm willing to rely on what Andrew Odlyzko says in his paper, Data Networks are Lightly Utilized, and will Stay that Way, as he seems to have done far more research into this than I have. According to him, neither of these situations occur. From the abstract :

Even the backbones of the Internet are run at lower fractions (10% to 15%) of their capacity than the switched voice network (which operates at over 30% of capacity on average). Private line networks are utilized far less intensively (at 3% to 5%).

ATM has a 10% cell tax. But, you can run ATM trunk up to 90% utilization and guarantee QOS.

I'd accept that the technology can allow you to do that, and specifically has mechanisms that can prevent oversubscription of available capacity. It has been designed to do that, and it can.

The question I would ask is how often is this feature used ? How often do ATM networks suffer from "busy" signals ? Do telco's run their ATM networks such that the average utilisation, over a significant time period, such as a week, run at 90% ? It wouldn't seem very wise to me if they did.

A Ethernet/POS trunk need to be run at 60% utilization or lower or you will incur severe Packet Queueing delay. So, there is a 40% tax with packet based trunk.

I don't understand the 60% figure you state, at least on a point to point link. I understand that packet queuing delay only occurs when the offered load onto the link is greater than the link capacity a.k.a bandwidth.

If the offered load is less than the capacity of the link, the only delay I'm aware of, in the context of our discussion, is serialisation delay.

I would think that you can run a point-to-point POS or Ethernet link up to 100%, just like you can ATM. The difference is that the ATM network can prevent extra traffic being offered to the network once the 100% utilisation has been reached.

However, if your protocol of preference over the ethernet / POS link is TCP (over IP of course), then the packet loss, and more recently, TCP Explicit Congestion Notification will cause the TCP sender to also reduce its rate of transmission.

By the way, typical tier 1 ISP run the trunk at average utilization of 40% or less.

It is interesting you mention that figure. I've seen it quoted in Some Internet Architectural Guidelines and Philosophy

Here is what the authors have to say :

6. The Myth of Over-Provisioning

As noted in [MC2001] and elsewhere, much of the complexity we observe in today's Internet is directed at increasing bandwidth utilization.
As a result, the desire of network engineers to keep network utilization below 50% has been termed "over-provisioning". However, this use of the term over-provisioning is a misnomer. Rather, in modern Internet backbones the unused capacity is actually protection capacity. In particular, one might view this as "1:1 protection at the IP layer". Viewed in this way, we see that an IP network provisioned to run at 50% utilization is no more over-provisioned than the typical SONET network. However, the important advantages that accrue to an IP network provisioned in this way include close to speed of light delay and close to zero packet loss [FRALEIGH]. These benefits can been seen as a "side-effect" of 1:1 protection provisioning


This makes sense to me, as you would provision bandwidth to cope with your occasional peak load, not your average load, much like our roads are provisioned for occasional peak load a.k.a. rush hour.

Chopping packets into cells etc.. This is a non-issue anyhow. If cell is so bad why both Cisco and Juniper core router have a cell fabric??


I'll believe you on that one, I'm not familar with the internals of routers at that level.

That still leaves me wondering why you can't buy an OC192 ATM interface for one of these routers, yet OC192 POS or 10Gbps Ethernet interfaces are available ?
sgan201
sgan201
12/5/2012 | 1:50:41 AM
re: Siemens Sees Ethernet Everywhere
Hi Tony,
Won't having to run packet trunk at average 60% or lower utilization to avoid queueing delay a even bigger problem??

This is one of the biggest lie and fallacy that have been going on for at least 10 years. Until and unless one of the IP guru show up and tell the truth, I have very little regard for the IP folks' capability to tell the truth..

"The truth will set you free!!"

Dreamer
mr zippy
mr zippy
12/5/2012 | 1:50:40 AM
re: Siemens Sees Ethernet Everywhere
Hmpf, use proper HTML, LR board breaks it.

Clickable links :

"Data Networks are Lightly Utilized, and will Stay that Way"

http://www.rnejournal.com/abst...

"Some Internet Architectural Guidelines and Philosophy"

http://www.rfc-editor.org/rfc/...
road__runner
road__runner
12/5/2012 | 1:50:39 AM
re: Siemens Sees Ethernet Everywhere
dreamer101

"The truth will set you free" but also remember that "half knowledge is a dangerous thing"

Firstly lets get this cell tax thing out of the way: ATM tax is more than 10% because of the packing of AAL5 PDUs into cells.
Examples: 40 byte IP PDU requires 53 byte ATM cell (>20% wastage) but only 44 bytes on POS.

64 byte IP PDU requires 106 ATM bytes (2 cells) but only 68 bytes on POS.

As far as link utilization: please show examples of any real ATM network of reasonable size running at 90% utilization with bursty traffic.

If the original traffic is bursty then it does not matter whether you pack it into fixed size cells or variable sized packets. The only thing you can do is decide whether you want to add lots of traffic scheduling mechanisms or not. ATM protocols were designed around putting in lots of traffic scheduling so can yield slightly better utilization (in theory) but in practice the cost of all those additional mechanisms is not worth it. IP chose the route of simplicity so even though link utilization may be slightly lower (in theory) it is more than made up by the lowered complexity and opex by keeping the network simple.

Let me give you a quote (from Radia Perlman I think)

"Putting in excessive scheduling complexity is like putting in traffic lights on a freeway. It is no use putting them in because if the freeway is not congested then every car gets great service anyway. If the freeway is congested then everyone is stuck and it is unlikely that traffic lights would have helped."

We have borrowed the term "traffic engineering" from transportation people, so lets learn from their design principles also.
sgan201
sgan201
12/5/2012 | 1:50:39 AM
re: Siemens Sees Ethernet Everywhere
Hi Mr. Zippy,
Who cares about core?? Ask yourself, what link feed into those core?? How many hops do those DSLAM has to go through before they reach the core?? By the way, most of Central Office where the DSLAM is are running OC-12 or less. So, there are a lot more trunks between the DSLAM and the core than the core. And, those trunk are low speed (OC-12) and less..

Form the Andrew Odlyzko's own paper, even the backbone of the Internet are running at 10 to 15% utilization?? Why?? Why won't they run at higher utilization?? That sound a lousy way to run business that have trunk that run at such a low utilization unless there is a reason..

Remember the core is very small part of the whole DSL network.. It is necessary at least 10 to 20 times smaller..

Pick up a good network book like "COmputer Networks" by Andrew S. Tanenbaum. Look up on queueing delay.. You will see that for any packet switching system queuing delay grow linearly until the utilization reach around the knee of 60%. Then, the delay grow exponentially.. This is true for any variable length packet switching system where IP is one of them..

You have run a Enterprise network. Check you IP trunk utilization.. Why it never exceed 60& for any amount of time?? It is the queueing delay that cause everything to slow down. And, if you want good performance for your user, you better make sure your average utilization is substantially below that and it is 40% or less.

The fun part begins when you try to do VoIP on the same trunk. You will quickly find that the best way to run VoIP and normal IP together is over an ATM trunk..

Who cares about OC-192 trunk?? If I corner the market for all OC-3 and OC-12 trunks and someone else win the OC-192 trunk market, guess who will be the one that will laugh his/her way to the bank??

Dreamer
sgan201
sgan201
12/5/2012 | 1:50:38 AM
re: Siemens Sees Ethernet Everywhere
Hi Road runner,
Do your math..

A DSLAM has X number of DSL lines.. A DSL line has Y number of bandwidth.. A CO has Z number of DSLAM.. Is X * Y * Z substantially greater than OC 3 or less than OC3??

By the way, DS1/E1 IMA is fairly popular interface for DSLAM too..

So, is this trunk congested or not?? DO you need traffic management or not??

Dreamer
sevenbrooks
sevenbrooks
12/5/2012 | 1:50:38 AM
re: Siemens Sees Ethernet Everywhere

Road_runner,

QoS management is best suited when constraints are in place in terms of bandwidth. This is certainly more suitable to access then it is to core. I think that your discussion here is around ATM Core and the article is around Access. Your argument about whether a large scale network can be 90% efficient is unimportant. In access, each line has to be able to perform the function asked of it. That is why applying Core Thinking to Access does not work.

However, I generally concur that the use of complicated QoS structures is not scalable to mass markets. In the ATM construct, this means things like UBR and CBR are scalable with VBR (rt or nrt) and ABR as not effectively scalable to beyond business offerings.

seven
<<   <   Page 3 / 12   >   >>


Featured Video
Upcoming Live Events
November 5, 2019, London, England
November 7, 2019, London, UK
November 14, 2019, Maritim Hotel, Berlin
December 3-5, 2019, Vienna, Austria
December 3, 2019, New York, New York
March 16-18, 2020, Embassy Suites, Denver, Colorado
May 18-20, 2020, Irving Convention Center, Dallas, TX
All Upcoming Live Events