<<   <   Page 2 / 7   >   >>
paolo.franzoi 12/5/2012 | 1:25:40 AM
re: Car Pools & QOS

Carriers are not picking these for real at the moment. There is a vendor debate about it.

My view of the whole TR-58/59 thing is that it works very well as long as the DSLAM remains an unblocked element. The architecture was derived to allow carriers to keep their Alcatel DSLAMs (disclaimer I work on ATM DSL products). As long as the DSLAM is unblocked IP QoS ignoring any CAC requirements of the DSL line or the DSLAM. Video over DSL defeats that. Lets use an example. Carrier has an ASAM 7300 which has a OC-12 backplane and uplink. If one is not multicasting in the DSLAM, then today (with MPEG2 encoding at about 3.5Mb/s per SDTV stream) one can do 177 TVs across that DSLAM. IF one does ADSL (2 TVs/home) one can support about 90 subs. If its 3 TVs/home (ADSL2+) then one gets about 60 subs/DSLAM.

I have not yet talked about what form of PVC management exists yet. What this shows, is that one pretty much MUST multicast in the DSLAM to get to a reasonable price/port on a 300 port DSLAM. So this whole 1 PVC versus 2 PVC argument exists in 1 (yes exactly 1) place. Between the multicasting DSLAM and the DSL Modem. That is why this is not a debate. It does not matter. As one is pairing DSLAM + DSL modem to accomplish this service (see November's TR-48 testing to see that getting Modems and DSLAMs to maximum performance is a dicey thing).

Scott Raynovich 12/5/2012 | 1:25:39 AM
re: Car Pools & QOS >I guess my question to you at light reading is >why you have never had a webinar with folks >that actually have deployed Video over DSL?

Actually we did a Live event on this very topic and the difficulties involved were well documented by attending service providers:


paolo.franzoi 12/5/2012 | 1:25:37 AM
re: Car Pools & QOS
Your correct except you miss the point.

DSLAMs work on ATM QoS on a static basis and have no view to IP QoS.

Router and switches using Ethernet or IP QoS.

Either mechanism can work but we don't have communication between mechanisms that is required.

arch_1 12/5/2012 | 1:25:37 AM
re: Car Pools & QOS There is only one fundamental difference between QoS at the cell level and QoS at the packets level:

With QoS at the cell level, Transmission of a big low-priority packet can be interrupted between any two cells to permit transmission of higher-priority cells. This means that there is less latency variation for the high-priority traffic. This effect is important low-speed links such as the subscriber-to-DSLAM ADSL link the effect is less important in the DSLAM-to-subscriber link, and effectively irrelevant on the DSLAM uplink to the world.

All other QoS-related features can be made available with either approach. They are functionally equivalent except for the one feature. The two camps use different different terminology and argue heatedly, but the functinal equivalence remains. (Note: I'm talking about per-link QoS. I do know the difference between connection and connectionless but that differnce is also irrelevant in this context.)

Jitter difference: a 1500-byte packet is about 12Kbits, or 12ms at 1Mbps. A cell is 424 bits, or .4ms at 1Mbps. This is an important difference in jitter.

The article's analogy with highways is completely wrong, because both cell and packet QoS allow the low-priority traffic to use any bandwidth that is not needed by high-priority traffic.
paolo.franzoi 12/5/2012 | 1:25:36 AM
re: Car Pools & QOS
The CTC one looked good. The other one is a theoreical one as well.

sgan201 12/5/2012 | 1:25:35 AM
re: Car Pools & QOS Hi,
I do not understand what/where is the problem??

A) From the direction of the Internet to the DSL user, the BRAS is the only device that need to know IP and sort the IP packet into 2 ATM VCCs.

B) If you are offering Video service, you need a set top box to decode. Given the horse power and cost of the set top box, it is a minor addition to that box to add DSL modem and broadband router functionality. But, by the way, I do not think video broadcast over DSL justify the business case anyhow. This medium has the same problem as cable TV in that it cannot compete cost effectively with satellite dish.

mr zippy 12/5/2012 | 1:25:35 AM
re: Car Pools & QOS Irrespective of the one or two PVC, Ethernet or ATM debate, I think the real issue will be whether you can trust the customer to classify their traffic to suit QoS.

I don't think you can.

When it comes to sending, IP traffic is generated by a device that the customer owns ie. their PC. Commonly, the customer also owns the CPE ie. DSL / Cable modem / router.

Everybody wants better and faster, and in particular, when it comes for "nothing". If a customer can mark their "non-high priority" packets as "high priority", and get high priority performance all the time, they will find a way.

While you do need technical knowledge to understand what to do, you don't necessarily need technical knowledge to do it - somebody just has to write a small tweaking app to tune the IP stack parameters. As an example, there are plenty of MTU / TCP paremeter tuning apps around already, where the user just clicks an "OK" button to "get faster DSL access".

I'd suggest you certainly don't need a high percentage of customers to make this change before it effects QoS delivery to the whole customer base. I'd suspect the figure would be in order of only 20%. I'm sure there are a enough PC geeks around that will work out how to do this, and then help their friends do it, such that any benefits of QoS engineering in the network will disappear fairly quickly.

It could be argued that the CPE could enforce these rules. I would argue against that as, firstly, the Telco would have to own the CPE to be able to trust its configuration, and I doubt the market would now accept the CPE being owned by the Telco, and secondly, the CPE would have to contain application recognition capabilities, increasing complexity and cost - and if the Telco owns it, they would have to expect to wear the complexity costs. Additionaly, end user applications would be easily modified over short time frames to get around these application recognition rule sets. It would be an arms race between the CPE vendor / Telco and the end user, with the CPE vendor / Telco always playing catch-up.

arch_1 12/5/2012 | 1:25:35 AM
re: Car Pools & QOS Brookseven said:

Your correct except you miss the point.

DSLAMs work on ATM QoS on a static basis and have no view to IP QoS.

Router and switches using Ethernet or IP QoS.

Either mechanism can work but we don't have communication between mechanisms that is required.

I think we can agree that the actual traffic will be IP, so the marking mechanism in the computers and other gear in the home, and in hte servers in the internet, will be IP QoS marking of some sort, regardless of The DLSAM transport mechjanism. Therefore, we will not be QoS on the last-mile (DSLAM<-->subscriber) until the DSLAM and the DSL modem become aware of IP QoS marking. This is absolutely the case in the subscriber-->DSLAM direction. The only alternative would be to have two separate ethernet ports on the DSL modem, and this would constitute a big hassle for the home user.

In the other direction, sorting priorities into PVC msut occur wherever the segmentation (packet-to-cell) function occurs.

On balence it looks to me like the DSLAM and DSL routers must be upgraded to support QoS whether or not ATM is used. Therefore, there is no difference here, either. The cost of an upgrade cycle overwhems any minor differences in cost between the two approaches.
Scott Raynovich 12/5/2012 | 1:25:35 AM
re: Car Pools & QOS brookseven I'd love to hear more specific "Triple Play Horror" stories if you have any.. give me a call 212 925-0020 x103
paolo.franzoi 12/5/2012 | 1:25:34 AM
re: Car Pools & QOS
Dhreamer and Scott,

The problem dreamer is that first Video Traffic never hits the BRAS. It has to be classified around the BRAS. How many of these devices are capable of running 100% traffic throughput continuously.

Set top box vendors are not generally DSL Modem vendors. The DSL modem performance has to be at a premium. By the way, Sattelite has less than 20% market share so cable is doing quite well.

Scott its not about horror stories its about where this sits from a technology standpoint. The big issues as I see them are.

DSL Modems - You have to get maximum connection rates on every connection. As trivial as this sounds, please take a look at the DSL Forum's TR-48 test last fall. Seriously, ADSL Modems from premium vendors failed this test miserably.

Home wiring - How do we get Ethernet through a home effectively? Guess what, current wireless technology is not there (imagine your microwave trashing your cable picture).

Quality of transmission - By the way while you are doing that even a few visible errors per hour will be considered unacceptable by subscribers.

Channel Switching Time - Customers will not like the service if switching channels takes to long.

Security and IP addressing - Being able to have separate IP address spaces for video and internet. Access Control Lists and Denial of Service attacks.

Raw Bandwidth - Multicasting and where to do it. If you did not multicast a 500 port DSLAM and you wanted an average of 20Mb/s of video available to every sub then the DSLAM requires a 10 Gb/s uplink. The bandwidth upgrades are extreme AND many pieces of equipment don't really have the ummph they claim.

Whether you use 1 VCC or 2 VCCs ranks about 100th on the list of things to worry about.

<<   <   Page 2 / 7   >   >>
Sign In