Comcast Corp. (Nasdaq: CMCSA, CMCSK) submitted a series of filings with the Federal Communications Commission (FCC) last Friday that describe the MSO's new "protocol agnostic" network management platform it intends to migrate to by year's end, as well as additional info about the existing system that plunged the MSO into hot water in the first place.
Comcast filed the documents after the FCC published an order on Sept. 20 that calls on the operator to stop throttling peer-to-peer (P2P) traffic and halt its "discriminatory network management practices." The FCC gave Comcast 30 days to disclose its current practices, provide a compliance plan on how it will stop those practices by the end of the year, and give greater detail about the network management system that will replace the one that's in place now. (See FCC Puts Comcast on the Clock .)
Comcast is asking the Court of Appeals for the D.C. Circuit to reverse the order, but, nonetheless, has agreed to comply with the FCC's request for information. (See Comcast Strikes Back .)
Deployment benchmarks
In addition to a previously announced commitment to transition its entire broadband network to a "protocol agnostic" network management system by the end of the year, Comcast also outlined several other "benchmarks" it expects to meet before then.
Among them, the MSO said it will have completed the installation of PacketCable Multimedia (PCMM) and Internet Protocol Detail Record (IPDR) servers by Oct. 15. By then, it will have also have begun to install "Congestion Management Fairshare" servers from Sandvine Inc. (London: SAND; Toronto: SVC). (See Sandvine Unveils FairShare and Comcast Deploys Sandvine.) [Ed note: More details about these network elements follow further down.]
By Nov. 15, Comcast will have begun commercial "cutovers" to the new system on a market-by-market basis. Once the network-side gear is in place, Comcast will then install software updates on customer cable modems in those given areas and disable the company's current congestion management system.
Comcast said it will send emails to customers at least two weeks before the new system is commercially deployed in a given market. Comcast did not say where the cutovers will occur first, but the MSO is already conducting technical trials of the new system in Chambersburg, Pa.; Warrenton, Va.; Lake City and East Orange, Fla.; and Colorado Springs, Colo. (See Comcast Ready to Test New Traffic Cop.)
Comcast indicated it expects to report to the FCC by Jan. 5, 2009, that it has discontinued its "protocol-specific" congestion management practices across the board in favor of the new platform.
The new system
In a separate filing, Comcast detailed the "protocol agnostic" system that's set to replace the existing one, which singles out how some upstream P2P traffic is managed and delayed. (See Comcast Defends P2P Management .) And it sounds pretty much like the MSO has previously described it -- that some customers could be slowed down temporarily if they are gobbling up an exorbitant amount of capacity, regardless of what type of application they may be using. (See Comcast CTO: Manage People, Not Protocols.)
In the first step, new network software will continuously monitor aggregate traffic usage data for individual segments on the MSO's high-speed Internet network. If overall upstream or downstream usage on a particular segment breaches a predetermined level, the software then determines which customers are using a "disproportionate share of the bandwidth." If the software further discovers that certain subscribers are the source of high volumes of network traffic during a given "period of minutes," traffic for those customers "temporarily will be assigned a lower priority status."
Comcast had earlier confirmed that customers who are subject to this policy could experience slower speeds in the range of 10 to 20 minutes, or until the state of congestion clears up. But that's just a rough guide. (See Sandvine: We're Fine .) However, traffic won't be delayed at all if the system ultimately determines that the particular network segment is not experiencing congestion.
Ozip There is a distinct difference in the quality of service during heavy traffic delivered by flows separated by priorities and those that are physically separated. But one is more efficient than the other. There is also a difference in service delivery between CoS and QoS flow separations.
PacketCable VoIP should not be affected. Separate service flows are created for that traffic than internet traffic. A regular cable modem may have two services flow (one down, one up) for date. Some service providers may implement a separate service flow for device management.
With the addition of PacketCable VoIP, two more pairs of service flows are added: one pair is for signaling, and stays pinned up, the second pair dynamically created for each additional call (i.e. you have a multi-line eMTA and are provisioned for more than none line).
Each service flow is assigned a service class, (there's a default one if you don't assign it one), and each service class is assigned a both a scheduling and traffic priority on a scale of what I believe is 0 to 7. Best Effort is normally near the lowest with a scheduling priority of 1. Voice is assigned a 5. "Real time" applications, such as the signaling channel are assigned a 3. If I had to guess, Comcast would assign their Priority Best Effort one higher than their Best Effort, but which is still less than their "Real time".
This would not affect their voice system. Voice services provided by Comcast use a technology called PacketCable. Voice calls are carried on different service flows (think virtual circuits over the cable plant) to the High Speed Data Service.
The way I read it is that a customer's traffic is moved to the deprioritized status if the customer is found to average 70% or more of his or her provisioned bandwidth , which is determined by the speed tier that was signed up for. So, it certainly does appear that customers could be penalized or slowed down if they are discovered to be close to their (non-guaranteed) speed ceiling for a 15 minute period.
The docs do mention VoIP, at least in an over-the-top service context, noting a belief that the "User Consumption Thresholds" are set sufficiently high that using a cable modem connection for VoIP or most streaming video "cannot alone cause subscribers to our standard-level HSI service to exceed the User Consumption Threshold."
But Comcast also notes that user traffic in the BE (best effort) state during actual congestion "may find that a webpage loads sluggishly, a peer-to-peer upload takes somewhat longer to complete, or a VoIP call sounds choppy." They then go on to stress that the "same thing could happen to the customers on a port that is congested in the absence of any congestion management"
The part about when someone gets converted from PBE to BE is a little convoluted. It looks like people at or over 70% of their provisioned bandwidth during times of congestion will be targeted for the switch. Is this correct? Are they really telling me I get a 8M/1M connection, but if I am using that bandwidth I am paying for and there is congestion, I am going to get punished?
The blogs and comments are the opinions only of the writers and do not reflect the views of Light Reading. They are no substitute for your own research and should not be relied upon for trading or any other purpose.
To save this item to your list of favorite Light Reading content so you can find it later in your Profile page, click the "Save It" button next to the item.
If you found this interesting or useful, please use the links to the services below to share it with other readers. You will need a free account with each service to share an item via that service.
Digg
Del.icio.us
Reddit
