[IMS Group] A case of VoIP QoS and Net Neutrality

84 views
Skip to first unread message

Manuel Vexler

unread,
Feb 19, 2009, 11:14:26 PM2/19/09
to imsg...@imsforum.org

I would like to ask for the the group's feedback regarding how IMS could actually solve the problem of Net Neutrality discussed in this article. I have two questions:

 Is  IMS  a solution to the problem, since it allows a service provider to deliver the same QoS to all VoIP calls, including their own brand.?  
- If IMS is not used as an architecture, what will be another solution to offer differentiated QoS for VoIP traffic?

 


Comcast volleys back at FCC on unfair VoIP QoS practices: Denies it prioritizes native VoIP traffic over wholesale customers, by Doug Allen

Excerpt from an article which appeared in the Telecommunications Online (http://www.telecommagazine.com/newsglobe/article.asp?HH_ID=AR_4843)

Comcast must be starting to feel as if it has a bullseye on its back. On the heels of a seemingly-resolved dispute over rate-throttling based on type of application Comcast finds itself in a related contretemps over a similar question of policy towards a particular service. In this case, VoIP.

Last month, the FCC sought clarification on a Comcast statement that stipulated some VoIP subscribers from other providers using Comcast’s network for wholesale transport may experience a lower QoS experience than Comcast’s own VoIP customers. Specifically, a Comcast FAQ posted online held that when the network is congested, VoIP calls may sound “choppy.” The disclaimer set off alarms at the FCC, who wondered if that meant Comcast’s new network management system — implemented at the FCC’s behest, though Comcast says it was a voluntary move — was penalizing non-native VoIP traffic, for well, not being a direct Comcast customer — in effect, discouraging non facilities-based competition and violating established FCC principles.

Comcast may have felt somewhat blindsided by the charge, as the same FAQ went on to say that Comcast’s Digital Voice service (CDV) runs over separate infrastructure than its own high-speed broadband network, which carries other carrier’s VoIP traffic. In other words, CDV “is a separate facilities-based IP phone service” that “is not affected” by the new network management platform just installed.

Last week, Comcast issued a formal reply, stating that CDV is a managed service, indeed runs over dedicated VoIP facilities other than its primary network, and is thus not an over-the-top content service, which would indeed be an appropriate target for any anti-competitive concerns.

A related concern is the method of regulation the FCC applies to VoIP services. Comcast may have been afraid that the FCC would view any preferential treatment for VoIP as an indication that the service’s designation should be changed from an information service to a telephony service, which would impose “the same intercarrier compensation obligations applicable to other facilities-based telecommunications carriers” on Comcast.

“CDV is not an application that is used ‘over-the-top’ of a high-speed Internet access service purchased by a consumer,” according to the Comcast’s letter to the FCC, signed by general counsel Matthew Berry. “ Significantly, CDV customers do not need to subscribe to Comcast HSI [high-speed Internet] service, and Comcast does not route those CDV customers’ traffic over the public Internet. Rather, as the commission is aware, our CDV service is based on PacketCable specifications that mandate the use of a managed IP network in that services are not delivered over the Internet.”

More pointedly, Comcast refuted any implied charge that its VoIP service could be classified as an information, not a telephony, service. Citing the FCC’s own Cable Modem Ruling, Comcast held that CDV is “an interconnected VoIP [telephony] service,” not over-the-top, which has instead been classified an information service.

Best regards,
Manuel
 
Manuel Vexler
Chair Technical Working Group, IMS/NGN Forum 
 
Work: 561-208-6495
Mobile: 561-289-8353
Email: tech...@imsforum.org
IM: mvexler (Skype)
IMS/NGN Forum

 

Natarajan Kalpathy

unread,
Feb 19, 2009, 11:28:50 PM2/19/09
to imsg...@imsforum.org

I am not sure if IMS solves or addresses Net Neutrality at all.

1) There is only so much bandwidth available at core. (service provider network). IMS is just an architecture which describes how advance services e.g. video,voice and other multimedia services are controlled and delivered from network. The only way to ensure quality is to ensure enough bandwidth is available (expensive) or control which service/who gets how much bandwidth.
2) IMHO, if anything service provider who implement IMS architecture will be against Net Neutrality. Service provider want to ensure the QOS for the services (which may be many because of IMS) they are providing hence differentiating themselves from VONAGE/SKYPE's of the world.
3) There are already mechanism in place to ensure QOS for different services e.g. voice, video by VLAN (in Ethernet environment), MPLS etc.

Just my 2 cents,
Natarajan

--- On Thu, 2/19/09, Manuel Vexler <tech...@imsforum.org> wrote:

> From: Manuel Vexler <tech...@imsforum.org>
> Subject: [IMS Group] A case of VoIP QoS and Net Neutrality
> To: imsg...@imsforum.org
> Date: Thursday, February 19, 2009, 11:14 PM
> I would like to ask for the the group's feedback
> regarding how IMS could
> actually solve the problem of Net Neutrality discussed in
> this article. I
> have two questions:
>
> - Is IMS a solution to the problem, since it allows a
> service provider to
> deliver the same QoS to all VoIP calls, including their own
> brand.?
> - If IMS is not used as an architecture, what will be
> another solution to
> offer differentiated QoS for VoIP traffic?
>
>
>
>
> _____
>

> new network management system - implemented at the
> FCC's behest, though
> Comcast says it was a voluntary move - was penalizing
> non-native VoIP
> traffic, for well, not being a direct Comcast customer - in

> <http://www.imsforum.org/> IMS/NGN Forum
>
> <http://maps.google.com/maps?q=%2CBoca+Raton%2CFlorida%2CUSA&hl=en>
>
>
> <http://www.linkedin.com/e/wwk/150647/>
> <http://www.linkedin.com/e/sig/150647/>
>
> _______________________________________________
> IMSgroup mailing list
> IMSg...@imsforum.org
> http://lists.imsforum.org/mailman/listinfo/imsgroup



_______________________________________________
IMSgroup mailing list
IMSg...@imsforum.org
http://lists.imsforum.org/mailman/listinfo/imsgroup

lucia

unread,
Feb 20, 2009, 6:04:56 PM2/20/09
to natarajan...@yahoo.com, imsg...@imsforum.org
Does anybody know what "Comcast's Digital Voice service (CDV) runs over separate infrastructure than its own high-speed broadband network" really means? Are the  "separate facilities" [-based IP phone service] owned and operated by Comcast?
 
There are other VoIP service providers claiming they also have "VoIP network built from the ground up" to differentiate themselves through quality and reliability of the "Digital Voice service" (e.g. Alteva). 
 
Maybe the same "separate infrastructure" so just trying to understand what these providers really do before getting into the net-neutrality debate:
- is it profitable to own and operate a separate carrier-grade infrastructure to do VoIP and if not then who is really the provider of that infrastructure and under which terms
- how is traffic managed at the broadband access point where VoIP and Internet are mixed
 
Lucia
--
Lucia Gradinariu, PhD
mobile: +1.719.964.1446
skype: lgradina
http://www.gradinariu.com/Lucia_Gradinariu.html

Tom Nolle Public

unread,
Feb 20, 2009, 7:27:54 AM2/20/09
to tech...@imsforum.org, imsg...@imsforum.org

First, there is no problem.  The FCC ruled in 2005 that there was no barrier to having separate facilities for common carriers to offer IP services like IPTV, and that these facilities did not have to be shared, but they were not “the Internet” and not subject to QoS or other net neutrality issues.  If that wasn’t the case then U-verse would be illegal.  Second, having IMS applied to “real” VoIP would make Comcast’s problem worse because it would move their QoS management from a separate facility where there is no real Internet connection and no net neutrality issue, to one where there is.  They’d be in court in a week.  Third, no operator would ever dream of deploying IMS to support over-the-top voice QoS because they couldn’t expect to be paid.

 

Tom

 


From: imsgroup...@imsforum.org [mailto:imsgroup...@imsforum.org] On Behalf Of Manuel Vexler
Sent: Thursday, February 19, 2009 11:14 PM
To: imsg...@imsforum.org
Subject: [IMS Group] A case of VoIP QoS and Net Neutrality

 

I would like to ask for the the group's feedback regarding how IMS could actually solve the problem of Net Neutrality discussed in this article. I have two questions:

Natarajan Kalpathy

unread,
Feb 20, 2009, 6:30:44 PM2/20/09
to lucia, imsg...@imsforum.org

I think the answer to this question really is that Comcast reserves some bandwidth for it's CDV service using DOCSIS (I believe the current version is 3.0). So in case of congestion your internet data traffic does not get the same treatment at core and may be dropped.

I think other technology e.g. Fiber might have similar mechanism for ensuring QOS at level2.

Here is an article which discusses this approach

http://www.lightreading.com/document.asp?doc_id=171464&site=cdn

-Natarajan


--- On Fri, 2/20/09, lucia <lucia.gr...@gmail.com> wrote:

Tom Nolle Public

unread,
Feb 20, 2009, 6:53:09 PM2/20/09
to lucia, natarajan...@yahoo.com, imsg...@imsforum.org

In a letter dated January 30 2009, Comcast told the FCC that their voice service was completely separate from their high-speed Internet service, and to my knowledge that is now and has always been true.  PacketCable separates voice from Internet using an MPEG-like sublayer structure so even on the cable it’s a separate service.

 

Tom

 


lucia

unread,
Feb 20, 2009, 11:38:49 PM2/20/09
to Tom Nolle Public, imsg...@imsforum.org
the lightreading article was really good pointer!
 
Between the CMTS and the CMs both CVD Service and Internet use the same infrastructure, there is no "other facilities". DOCSIS 2.0/3.0 is used for data transmission in this area and it supports IP (even v6) and QoS. Let's assume here all traffic is equal.
 
Where the story gets interesting is at the "separate facilities"point. As Tom mentioned, FCC ruled in 2005 that there was no barrier to having separate facilities for common carriers to offer IP services. Comcast's statement sounds like they are using PacketCable2.0 which requires a different core architecture i.e. IMS, the way 3GPP has worked it with CableLabs to adapt the specifications  for cablecos/MSOs. (see http://www.cablelabs.com/news/newsletter/SPECS/NovDec_2006/story4.html)
 
These may be the "separate facilities". At the edge, this architecture integrates with the CMTS/DOCSIS part through a PacketCable Applications Manager that takes care of the session-level QoS requests and talks with the CMTS about this through a reference point defined in PacketCable 2.0 spec.
 
If this is the real case (so far just assumptions) then we have specific QoS for CVD service in the Internet access area for the end user (between CMTS and CM).
 
This may prove two things:
- there is disparate treatment of its own VoIP service as compared to that offered by other VoIP providers on its network
- CVD is a separate telecommunications services up to the CM which is the access point for the end user
 
Thoughts?
 
Lucia 

Ibrahim Dawood

unread,
Feb 21, 2009, 2:35:08 AM2/21/09
to lucia, natarajan...@yahoo.com, Tom Nolle Public, imsg...@imsforum.org
Hi Manuel and All,

I agree with the opinion that IMS will not be of a great effect on net neutrality in concept ... the tools are already available whether on the Telco's side or on the regulatory side, but there are numerous constraints on the Telco side due to issues such as bandwidth as some mentioned.

I agree with Tom, that multiple services can run on the same cable, yet be treated and considered as different services, so I don't think comcast has to build a new network for its voice services from the ground up, it doesn't make any sense -to me at least-.

but by looking at things from the operator's point of view, I -as an operator- must prioritize my traffic over other people's traffic, this is the basic sense, especially in the times of need such as network congestion, because my customers are the revenue generators for me, not wholesale traffic! unless of course the opposite then I am a different kind of operators!

nevertheless, the agreements between comcast and other operators should govern comcast's treatment of their traffic and the QoS that they will get, an I believe the regulator should be involved to govern the basic terms and conditions, as well as monitoring.

there are multiple ways to control QoS for VoIP traffic ... my favourite is Deep Packet Inspection (DPI) because it provides L2-L7 visibility over traffic which helps identifying the true source and destination of any VoIP call going over my network, and with cooperation with other components I can specify whatever class of service to differentiate between different streams of VoIP, allow, deny, rate limit, etc.

Thanks,
Ibrahim

--- On Sat, 2/21/09, Tom Nolle Public <tno...@cimicorp.com> wrote:

> From: Tom Nolle Public <tno...@cimicorp.com>
> Subject: RE: [IMS Group] A case of VoIP QoS and Net Neutrality
> To: "'lucia'" <lucia.gr...@gmail.com>, natarajan...@yahoo.com
> Cc: imsg...@imsforum.org
> Date: Saturday, February 21, 2009, 3:53 AM
> In a letter dated January 30 2009, Comcast told the FCC that
> their voice
> service was completely separate from their high-speed
> Internet service, and
> to my knowledge that is now and has always been true.
> PacketCable separates
> voice from Internet using an MPEG-like sublayer structure
> so even on the
> cable it's a separate service.
>
>
>
> Tom
>
>
>
> _____
>

> <http://maps.google.com/maps?q=%2CBoca+Raton%2CFlorida%2CUSA&hl=en>

Tom Nolle Public

unread,
Feb 21, 2009, 7:53:15 AM2/21/09
to ida...@vupoint.ca, lucia, natarajan...@yahoo.com, imsg...@imsforum.org
With respect to prioritization and QoS, I'd also like to suggest that
service quality is NOT an attribute of IMS as much as it is of ITU/RACF. I
make the distinction because the ITU model puts Service Control (IMS and
IPTV, for example) above the Transport Plane, controlling the latter through
the RACF. When a session requires a data path, admission control
(separately) and RACF would be used to bring about priority handling. That
means that you could, by operating through RACF, prioritize traffic that had
nothing to do with IMS, or even with sessions.

I think this model is highly useful in general, and there is work to bring
about harmonious linkage of what I'll call RACF Domains (to avoid for the
moment the IMS term) proceeding in the IPsphere group of the TMF.

Tom

Banibrata Dutta

unread,
Feb 21, 2009, 11:15:58 AM2/21/09
to imsg...@imsforum.org
On Sat, Feb 21, 2009 at 1:05 PM, Ibrahim Dawood <ida...@vupoint.ca> wrote:
Hi Manuel and All,

I agree with the opinion that IMS will not be of a great effect on net neutrality in concept ... the tools are already available whether on the Telco's side or on the regulatory side, but there are numerous constraints on the Telco side due to issues such as bandwidth as some mentioned.

I agree with Tom, that multiple services can run on the same cable, yet be treated and considered as different services, so I don't think comcast has to build a new network for its voice services from the ground up, it doesn't make any sense -to me at least-.

but by looking at things from the operator's point of view, I -as an operator- must prioritize my traffic over other people's traffic, this is the basic sense, especially in the times of need such as network congestion, because my customers are the revenue generators for me, not wholesale traffic! unless of course the opposite then I am a different kind of operators!
 
But why ? Selfishness isn't defensible in court of law. Wholesale traffic is traffic that was just sold differently. What is defensible in court of law however is clearly stated QoS guarantees (or lack there-of) for different tariff plans, and more transparency about how traffic would be handled during periods of congestion. Clearly specified traffic engineering parameters, in language that can be easily understood by average consumers.
 
nevertheless, the agreements between comcast and other operators should govern comcast's treatment of their traffic and the QoS that they will get, an I believe the regulator should be involved to govern the basic terms and conditions, as well as monitoring.

there are multiple ways to control QoS for VoIP traffic ... my favourite is Deep Packet Inspection (DPI) because it provides L2-L7 visibility over traffic which helps identifying the true source and destination of any VoIP call going over my network, and with cooperation with other components I can specify whatever class of service to differentiate between different streams of VoIP, allow, deny, rate limit, etc.
 
But DPI only rules for clear-text (or decipherable text). Much of P2P traffic is not clear-text. DPI then needs the aid of what people believe is the "other camp", i.e. Policy Controllers, but to fine-tune and have good policies, which limit false-positives to bare min., is an art. Stock/canned policies which are not adapted to the law of the land, and operators logical interpretation of the policies are no good. Anyway, I think, "technology" is a non-issue.



--
regards,
Banibrata
http://www.linkedin.com/in/bdutta

Tom Nolle Public

unread,
Feb 21, 2009, 2:23:21 PM2/21/09
to Banibrata Dutta, imsg...@imsforum.org

I think we’re missing a fundamental point about this, and possibly I contributed by not being clear.

 

In cable networks (PacketCable) there is a four-layer architecture on the cable, and one of the layers is essentially a media subdivision or multiplexing layer (it was originally based on MPEG-2 and I believe that’s still the case).  This layer divides the cable plant in the same way that virtual circuits divide DSL/ATM networks.  Voice services ride on one of these “circuits” and the Internet on another.  There is no connection between them, no DPI or any other IP mechanism can look across the MAC multiplexing and see the voice processes.  The relative capacity assigned at the cable MAC layer is what divides voice versus Internet performance.  The fact that the voice might look like VoIP doesn’t mean that it shares any resources with the Internet.

 

With regard to wholesale versus retail QoS and tariffs, I agree with you except that there is no “wholesale” or “retail” tariff on an Internet connection.  You have best efforts traffic.  The customer pays for access, and nobody pays directly for transport and so there is no guarantee to reference.  The net neutrality debates relate to whether it would be legitimate for operators to prioritize their own Internet traffic flows, or to discriminate against some traffic versus others (which is a kind of implicit prioritize-by-deprioritizing approach).  The FCC has indicated that to discriminate by content, etc, is against their policy.  They have not ruled that they could or would not allow operators to discriminate by “payment class”, meaning that there is a theoretical capability for ISPs to sell premium service.  Google and others who don’t want to pay for that premium handling want operators to offer it without incremental charging.  Clearly they need not do that, nor is it likely the FCC could even order them to (you can’t order a private corporation to lose money).  Where it gets complicated is that the operators might make themselves responsible for priority handling third-party Internet traffic if they prioritized their own traffic; this is the basis of the question on how Comcast handled VoIP.  If their VoIP service shared infrastructure with the Internet, and thus with over-the-top VoIP services from others, then the FCC doctrine would be that preferencing their own VoIP would violate FCC rules.  However, the FCC ruled in 2005 that the Internet is an information service with a bundled and inseparable telecom component.  Thus, it is immune from forced sharing and unbundling at the component level.  Application of the principles the FCC articulated said that if somebody created an IPTV or voice service using IP but not mixed with the Internet, it would be regulated not as Internet service but as the service it purported to be.  The FCC says that the service determines the regulatory treatment and not the technology.  Thus, Comcast voice is NOT Internet voice because it doesn’t travel on the Internet.

 

I’m not a Comcast fan; I dropped their service instantly when FiOS gave me an alternative.  But the law is the law, and they are right in what they claim unless they took the truly stupid (and likely economically fatal) step of lying to the FCC, which I seriously doubt they did.

 

Tom

 


Ibrahim Dawood

unread,
Feb 22, 2009, 4:17:06 AM2/22/09
to imsg...@imsforum.org, Banibrata Dutta
Hi Banibrata,

Thanks for your comments.

circumstances and game rules are different by region, or even countries, like here in the ME region there are not much rules like in the US, after all the market itself is not mature in all aspects even when it comes to the customer itself, thus most telco's here do whatever they want with no questions asked in many cases.

regarding DPI, there has been a lot of development in that field and now it is becoming more mature than before and can provide a magnitude of functionalities, of course along with policy management mechanisms we can have control over QoS and Class of Service, after all there is no single solution that can do it all. or is there?

thanks,
ibrahim

--- On Sat, 2/21/09, Banibrata Dutta <banibra...@gmail.com> wrote:

Tom Nolle Public

unread,
Feb 21, 2009, 4:24:32 PM2/21/09
to DOLLY, MARTIN C, ATTLABS, banibra...@gmail.com, imsg...@imsforum.org

You’re going to have to be a little less terse if you want me to respond, Martin.  I don’t understand what you’re asking.  PacketCable is deployed.  PacketCable Multimedia is deployed.  PacketCable 2.0 is deployed in at least some MSOs.  I don’t claim to have an inventory of their status.

 


From: DOLLY, MARTIN C, ATTLABS [mailto:mdo...@att.com]
Sent: Saturday, February 21, 2009 4:16 PM
To: tno...@cimicorp.com; banibra...@gmail.com; imsg...@imsforum.org
Subject: Re: [IMS Group] A case of VoIP QoS and Net Neutrality

 

Again, deployed vs ???


From: Tom Nolle Public
To: DOLLY, MARTIN C, ATTLABS; banibra...@gmail.com ; imsg...@imsforum.org
Sent: Sat Feb 21 16:10:21 2009
Subject: RE: [IMS Group] A case of VoIP QoS and Net Neutrality

Not sure where you think one’s missing, but PacketCable has been around since DOCSIS 1.1 at least, and the only real shift that has occurred is the one between PacketCable and PacketCable Multimedia or the 2.0 version.  It those later versions that use IP as opposed to TDM.  Comcast, to my knowledge, deploys the latest version (2.0, including IMS capability) but the architecture for cable-plant transport is pretty much the same for both PacketCable Multimedia and 2.0.  DOCSIS 3.0 is being deployed but that architecture is orthogonal to PacketCable; it’s for the broadband side where PacketCable is for the assured or separated services.

 


From: DOLLY, MARTIN C, ATTLABS [mailto:mdo...@att.com]
Sent: Saturday, February 21, 2009 3:58 PM
To: tno...@cimicorp.com; banibra...@gmail.com; imsg...@imsforum.org
Subject: Re: [IMS Group] A case of VoIP QoS and Net Neutrality

 

Please make a CLEAR distinction between what is in standards vs. Deployed???


From: imsgroup...@imsforum.org
To: 'Banibrata Dutta' ; imsg...@imsforum.org
Sent: Sat Feb 21 14:23:21 2009
Subject: RE: [IMS Group] A case of VoIP QoS and Net Neutrality

I think we’re missing a fundamental point about this, and possibly I contributed by not being clear.

 

In cable networks (PacketCable) there is a four-layer architecture on the cable, and one of the layers is essentially a media subdivision or multiplexing layer (it was originally based on MPEG-2 and I believe that’s still the case).  This layer divides the cable plant in the same way that virtual circuits divide DSL/ATM networks.  Voice services ride on one of these “circuits” and the Internet on another.  There is no connection between them, no DPI or any other IP mechanism can look across the MAC multiplexing and see the voice processes.  The relative capacity assigned at the cable MAC layer is what divides voice versus Internet performance.  The fact that the voice might look like VoIP doesn’t mean that it shares any resources with the Internet.

 

With regard to wholesale versus retail QoS and tariffs, I agree with you except that there is no “wholesale” or “retail” tariff on an Internet connection.  You have best efforts traffic.  The customer pays for access, and nobody pays directly for transport and so there is no guarantee to reference.  The net neutrality debates relate to whether it would be legitimate for operators to prioritize their own Internet traffic flows, or to discriminate against some traffic versus others (which is a kind of implicit prioritize-by-deprioritizing approach).  The FCC has indicated that to discriminate by content, etc, is against their policy.  They have not ruled that they could or would not allow operators to discriminate by “payment class”, meaning that there is a theoretical capability for ISPs to sell premium service.  Google and others who don’t want to pay for that premium handling want operators to offer it without incremental charging.  Clearly they need not do that, nor is it likely the FCC could even order them to (you can’t order a private corporation to lose money).  Where it gets complicated is that the operators might make themselves responsible for priority handling third-party Internet traffic if they prioritized their own traffic; this is the basis of the question on how Comcast handled VoIP.  If their VoIP service shared infrastructure with the Internet, and thus with over-the-top VoIP services from others, then the FCC doctrine would be that preferencing their own VoIP would violate FCC rules.  However, the FCC ruled in 2005 that the Internet is an information service with a bundled and inseparable telecom component.  Thus, it is immune from forced sharing and unbundling at the component level.  Application of the principles the FCC articulated said that if somebody created an IPTV or voice service using IP but not mixed with the Internet, it would be regulated not as Internet service but as the service it purported to be.  The FCC says that the service determines the regulatory treatment and not the technology.  Thus, Comcast voice is NOT Internet voice because it doesn’t travel on the Internet.

 

I’m not a Comcast fan; I dropped their service instantly when FiOS gave me an alternative.  But the law is the law, and they are right in what they claim unless they took the truly stupid (and likely economically fatal) step of lying to the FCC, which I seriously doubt they did.

 

Tom

 


From: imsgroup...@imsforum.org [mailto:imsgroup...@imsforum.org] On Behalf Of Banibrata Dutta


Sent: Saturday, February 21, 2009 11:16 AM

alan lloyd

unread,
Feb 21, 2009, 8:55:11 PM2/21/09
to Tom Nolle Public, Banibrata Dutta, imsg...@imsforum.org

Hi  All,

 

 I understand the Comcast Digital Voice discussion and some of the VoiP issues re SDPs(Service Delivery Platform)  -  and that cable systems can offer dedicated infrastructure for different types of QoS  - and  services.  One might even dedicate channels broadcast, emergency and DNS (intranets)  for instance.  Ditto   the use TDM, SDH/SONET

And with voice there are regulations..

 

So with IMS being promoted as multi service / session capability where (e.g.) in quad play t can open up a voice channels,  share movies  by using a few SIP SessionDescProfs to set mbit rates etc.. etc where would the IMS QoS actually be applied. Would it be the on the audio transfers only..  how could it be applied to the audio needs of MPEG – does the V in AV get treated separately?

 

Will the emergency and broadcast services of the future have a dedicated logical infrastructure and how will IMS work with that?

 

Banibrata said a few emails ago  something which I agree with (except for  the last line) – where QoS features can be  classed as revenue earning..

 

QoS has been undermined a couple of times in the last couple of days on this list, but isn't QoS a major differentiator in terms of what premium an Access bit-pipe provider may charge over what may be stock-Utility bit-pipe, setting the basic minimum level / quality of service ? The QoS is not in the Quality of pipe, but overall quality of the user experience, which spans Customer-care, technical support, set-up/fix times, responsiveness, billing etc. Of course, the regions where that basic minimum level of QoS is quite high, charging a premium for anything better may be too costly.

 

As the result of “end user QoS  managed products – we can have one or more IP addresses , parental controls as products and bandwidth on demand as products…. The QoS products relate to , self care provisioning and dynamic control.

 

I might have mentioned this once or twice before J ….  Where in the architecture, a framework or standards – is the function (SDP) that manages the overall QoS issues  needed by  IMS, its services, the network  infrastructure, access systems CMs . STBs and MTAs, and CPEs… and lets customers make sure their own QoS is satisfied  by either accepting what is given  or by paying a premium for it if they want their QoS to be better.. but at the same time know that 911/000 and other emergency services always have the right QoS

 

The other point is opt in… If I want QoS voice and/ or internet standard multi media – on what parts of the system would my services be applied?    As I still want single view  all my services

 

SDPs can with 10 million accounts,  10 million secondary users, 8 million access devices, parental controls, VoIP TNs, infrastructure servers for email, web, UMS, …IMS…address books .and content of course,   may need  up to about 2 billion information items -  all managed in real time by the customers and product managers..

 

QoS   -  and QoS in IMS -  it all comes back to management systems and the infrastructure being managed … The difference is today is the operator’s customers are selecting what they want as well as managing it on demand.- according to their “entitlements”..

 

 

Best wishes alan

 

 

 

 

 

 

Ibrahim Dawood

unread,
Feb 23, 2009, 4:52:48 AM2/23/09
to imsg...@imsforum.org, banibra...@gmail.com, colin...@kpn.com
Hi Colin,

Yes, indeed there still many challenges ahead for technologies such as DPI to face. I have been following this technology since its early days in the market and have noticed significant development in its capabilities, even when it comes to proprietary protocols.

For regulated markets, where standards should be followed by service providers, DPI -in my opinion- provides a convenient solution for controlling traffic and providing visibility, QoS (at least enhancing it) and CoS, provided that standards are follwed.

The processing power is required for such function, thus hardware providers have come up with high processing hardware structures that are capable of handling 10's of Gig's per second, even NGN and IMS manufacturers are working on producing their own DPI components, that's of course is on paper, the products are there, but personally I haven't got the chance to see any of them in action yet, but I may be able to soon and I will share the experience with you.

I'm not claiming that DPI is the only or even the best option out there, but from what I see and based on my experience, this technology will help a lot in the future not in providing control only, but in creating more new value added services in new, unconventional ways; yet, this belief may be proven wrong

Thanks,
Ibrahim


--- On Mon, 2/23/09, colin...@kpn.com <colin...@kpn.com> wrote:

> From: colin...@kpn.com <colin...@kpn.com>
> Subject: RE: [IMS Group] A case of VoIP QoS and Net Neutrality

> To: ida...@vupoint.ca, imsg...@imsforum.org, banibra...@gmail.com
> Date: Monday, February 23, 2009, 12:47 PM
> Hi Ibrahim,
>
> There are a few things to say against DPI, such as that it
> requires
> processing and network capacity additional to the platforms
> handling the
> traffic. But one things in particular struck me as odd in
> your earlier
> statement, namely your remark on L2-L7 visibility. In
> addition to what
> Banibrate already said, protocols which encrypt/obfuscate
> traffic, are
> proprietary and/or have frequent protocol changes are very
> difficult/challenging to detect by DPI (currently they
> can't).
>
> Colin
>
> -----Oorspronkelijk bericht-----
> Van: imsgroup...@imsforum.org
> [mailto:imsgroup...@imsforum.org] Namens Ibrahim
> Dawood
> Verzonden: zondag 22 februari 2009 10:17
> Aan: imsg...@imsforum.org; Banibrata Dutta
> Onderwerp: Re: [IMS Group] A case of VoIP QoS and Net
> Neutrality
>

lucia

unread,
Feb 24, 2009, 1:07:51 AM2/24/09
to alan....@wwite.com, imsg...@imsforum.org
Aren't we stretching the SDP role a little bit too far?
An SDP should not manage the QoS of IMS transport/infrastructure, but only request a certain QoS for a certain application/service and then collect QoS related information from the application/service context. It can further expose this information in a management framework that correlates network, services and customer layers (if possible, real-time and on customerID).
 
This management framework is the most important and missing today. TM Forum started the Service Delivery Framework initiative sometime ago to crank this topic
 
 
Regarding what a real SDP is, there is a market analyst report that I recently published through Moriana (www.morianagroup.com) and it contains a good description of the SDP scope. More info is available here  

It's interesting to discuss SDP as part of the Telecom Services Layer, atop IMS, and net neutrality even though we shift a little bit the topic in the original thread. An SDP enables a Service Provider to offer Internet like services  (e.g. mixed content and advertising),  but now the service is owned and operated by the Service Provider. How is this service regulated: as telecommunications or as information service?
 
Lucia
 
_______________________________________________
IMSgroup mailing list
IMSg...@imsforum.org
http://lists.imsforum.org/mailman/listinfo/imsgroup




--
Lucia Gradinariu, PhD
mobile: +1.719.964.1446
skype: lgradina
http://www.lggsolutions.com

Terry Hearn

unread,
Feb 24, 2009, 10:52:28 AM2/24/09
to imsg...@imsforum.org, lucia

Hi Folks,

 

After reviewing the email chain below, I believe IMS policy control and charging functions are being addressed and converged by the standards bodies (3GPP, TISPAN, ATIS IIF, etc…).   Unfortunately, services provides (SP) can’t afford to wait and need to influence the direction of these standards.  As SPs continue to add functional value to their voice, data, and video service offerings, they will slowly converge their uniquely defined wireline and/or wirless infrastrucutres into an IMS architecuture where an aggregated QoS policy may be applied by a converged IMS policy server.

 

Consider looking at the differences of the policy components (RACF, RACS, PCC/PCRF) defined within these standards as they evolve.  Specifically with respect to 3GPP R8+, look at the Rx and Gx PCRF IMS interfaces.

Regards

Terry Hearn


From: imsgroup...@imsforum.org [mailto:imsgroup...@imsforum.org] On Behalf Of lucia
Sent: Tuesday, February 24, 2009 1:08 AM
To: alan....@wwite.com
Cc: imsg...@imsforum.org
Subject: Re: [IMS Group] A case of VoIP QoS and Net Neutrality

 

Aren't we stretching the SDP role a little bit too far?

Duane Wright

unread,
Feb 24, 2009, 1:02:56 PM2/24/09
to Terry Hearn, imsg...@imsforum.org, lucia

Hello,

 

I’ve been following the e-mail chain with interest as well and would like to add a few comments on the perceived ways of enforcing QOS on IMS platforms.

Given that there are many interpretations as to how to enforce QOS and what QOS is, it could be difficult to define.

However there are given methods for this in the current releases of Packet cable and DSL for fixed services.

MPLS-RSVP-TE and DSCP appear to be the way to ensure path selection and PE to PE integrity.

In 3GPP it would have to used DSCP GTP within the SGSN/GGSN before it even reaches the policy server within the IMS layers.

In packet cable they have the added advantage of using IGMP for multicasting traffic which is used for the delivery of on demands services.

 

The question will be can there be an agreed policy similar to Service Provider MPLS RSVP-TE.

Would any service provider ‘honour’ any traffic classes and how would you charge for it?

 

QoS can be applied and enforced on any number of protocols already in use in various elements.

IMS is and always will be a service enabler not and as such, should be flexible enough to offer various policy enforcement types.

From a neutral point of view I’d expect some form of MPLS-RSVP-TE with DSCP to deployed and managed within the fixed line environment.

How you pass that on to the mobile elements such as the RAN SGSN GGSN without any ‘throttling’ or downgrade will be a major challenge.

Whether you’d use the Policy server at the IMS layer to enforce for standard ISP services it is questionable.

 

 

Regards,

 

Duane

 

 


alan lloyd

unread,
Feb 24, 2009, 8:17:55 AM2/24/09
to lucia, imsg...@imsforum.org

Hi Lucia -    I don’t have the morianagroup report -  but I often wonder what might be in it.  Can I get the scope as I have my own views.

 I have worked on identity / large scale directories since the mid 1980s.. 15 years before IDM became an issue. I have been building large scale convergence platforms and SDPs using directories and identity engineering for about 10 years now. There are not to many doing this work I beleive .  I have seen “specific service” SDPs for mobiles but not too many for large scale converged self care complex service delivery systems – using directories. And I havnt had any industry body agree with me yet that such complex systems are almost impossible to build using existing transactional data methodologies.. But there are quite a few systems engineers and managers that have seen this very issue and agree that big changes are needed in the way IT  service management systems are  “sold and deployed”.

 

As a contributor to wiki SDPs  and even introduced virtual private SDP functions into the SDP  language as this is a requirement I have received in discussions with an operator

 

As to QoS management – what will manage it then.? 

We have had discussions some time ago with seriously large infrastructure builders about entitlement based network edge management functions at broadband speed -   based on a user/service profile entitlements. That is, in the event of a large emergency situation, any one online  not involved with services marked as critical are backed off or switched off.  – These are all very much SDP functions I feel.

That is a SDP must understand the operational elements of the delivery infrastructure and communicate with it for service management and service assignment reasons .. The SDP must be able to rank events such as Emergency messages or Flash traffic (military) as ours does.   Service assignment issues - That is do I put a user in New York on a presence and mail server in Los Angeles and vice verca.. Additionally when a user logs in under non pay conditions – It’s the SDP that lets them use the QoS for emergency services, but they wont get HDTV streamed QoS.

 

 

My old war cry is – we have to move on from technology frameworks and connectivity architectures as they not very useful for engineering event driven complex systems.. We have to build systems based on what users do, how many there are of them, how they manage themselves and what service entitlements they have in the retail, personalized event driven world…and from this transcribe these needs on to the management functions associated with the server and network infrastructure. Systems in which everything has an identity and a behaviour and can come and go individually or all at once in seconds.

 

 

Best wishes alan

 

 

 


From: lucia [mailto:lucia.gr...@gmail.com]
Sent: Tuesday, February 24, 2009 5:08 PM
To: alan....@wwite.com
Cc: Tom Nolle Public; Banibrata Dutta; imsg...@imsforum.org
Subject: Re: [IMS Group] A case of VoIP QoS and Net Neutrality

 

Aren't we stretching the SDP role a little bit too far?

Reply all
Reply to author
Forward
0 new messages