Subject: Re: MG and DiffServ

From: "Petros N. Mouchtaris" <[email-masked]>
Date: Fri, 4 Aug 2000 09:46:20 -0400

I have a specific case that your approach does not support. I may have
misunderstood your comments so please let me know if I'm incorrect. TI think
this case is reasonable and should be supported:

I'd like all my voice to receive premium quality except for my calls to Greece
where I'm willing to accept best effort quality so that those calls to Greece
are virtually free. This will help me keep up with all my friends and family
there.

I expect that the MGC will maintain this policy and not my phone.  Let me know
what you think.

Petros

"James M. Polk" <[email-masked]> on 08/04/2000 09:28:26 AM

Please respond to "James M. Polk" <[email-masked]>

To:   [email-masked]
cc:    (bcc: Petros N. Mouchtaris/Telcordia)
Subject:  Re: MG and DiffServ

All

Shouldn't this be defined by other mechanisms by default?

For example, typically the MG is dumb and requires a config image from some
TFTP server. A template config is usually utilized that should set the default
DSCP to a value that likely won't change. This isn't a Protocol issue, I don't
think, it's a semantics issue.

Another example, the port the MG is physically connected to on the Enet Switch
sets the traffic to a specific Voice VLAN. Again, this isn't a Protocol issue.

Another example, the Enet Switch knows that a MG is what's attached to a
specific port and sets all incoming traffic to a defined DSCP value -- again,
not a Protocol issue.

I think, typically, a Protocol deals with things that are negotiated. I yet
don't see why a MG (IP Phone) which is almost always getting its config file(s)
from a Server (MGC?) that it will yet need to have anything other than the one
default value (even if that is EF marked) which that Domain Administrator
assigns to all Voice traffic within that Domain.

I believe the same should apply to a MG that's a PSTN to IP Gateway. There
actually cannot be a priority change from the PSTN to the IP network in this
example by law, if that IP Network is providing a Telecommunications Service
(although I'm not sure that 'law' is the right word -- I just know MLPP cannot
be run on the PSTN or like network-types). Therefore, all inbound IP Voice
related traffic must have the same value as all other Voice traffic to those
types of providers.

I know Fred Baker is very resistant to the idea of Voice traffic having
multiple Forwarding queue behaviors within an internetworking device (i.e.
multiple levels of EF for dropping), so this would suggest the DSCP other than
EF isn't preferred by him (and others). His belief - and I'm not yet sure it's
correct in the long term - is that this is a session issue, not a forwarding
issue; therefore this is an RSVP/COPS Prioritization issue, isn't it?

At 06:01 PM 8/3/2000 -0700, Bill Foster wrote:
>Given that the MGC is often defining policy and QoS use is an important
>policy, it would be useful to have the capability.
>
>At 04:34 PM 8/3/00 -0700, S KA N wrote:
>>Hi There,
>>
>>If you can recall the meaning of DiffServ, its for
>>implementing differentiated services in the Internet.
>>Which basically means giving QoS to specially marked
>>data traffic. Now if you look at the requirements
>>specified in Section 5.5 of RFC2805, it says that
>>the MGCP protocol should support the ability to
>>specify QoS for the connection between MGs, etc.
>>
>>Any comment.
>>
>>...SKAN
>>
>>
>>
>> > There's a difference between an operator's RFP
>> > requiring that their MGs
>> > support DiffServ and a protocol dependency on such
>> > support.  Megaco has no
>> > such dependency.
>> >
>> > > -----Original Message-----
>> > > From:       S KA N [SMTP:[email-masked]]
>> > > Sent:       Wednesday, August 02, 2000 3:26 PM
>> > > To: [email-masked]
>> > > Subject:    MG and DiffServ
>> > >
>> > > Hi,
>> > >
>> > > Can you think of any relation between the MG and
>> > > DiffServ?
>> > >
>> > > If a privately managed IP network is DiffServ
>> > > compliant and suppose if the same network
>> > > is going to be used for VoIP purposes also. Don't
>> > > we require the MGs to be DiffServ compliant?
>> > >
>> > > Any help/comment would be appreciated.
>> > >
>> > > ...SKAN
>>
>>
>>__________________________________________________
>>Do You Yahoo!?
>>Kick off your party with Yahoo! Invites.
>>http://invites.yahoo.com/
>
>-----------------------------
>Bill Foster
>Phone: (408) 527-8791
>Page:   (800) 365-4578
>Fax:     (781) 998-6492
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 4 Aug 2000 09:12:54 -0500

Petros

Who is providing the Service for you Voice traffic? If that is a
Telecommunications Service Provider (as defined by the US FCC), then you won't
have that choice across their network (I don't believe). If that is from an
Enterprise-based Call Agent (MGC), then I'd be surprised if that were legally
allowed to separate this traffic if that Enterprise has the MGC or Call Agent
for Signaling to/from your MG.

I think you'll have to somehow get the traffic you want to be EF marked across
a Telecom SP and have your Greece-bound traffic across some other network
entirely, then this will work. But (I think) the same MGC cannot signal both
your Greece destination traffic and the rest of your Voice traffic (as they
would be separate networks for signaling).

One way around that is a Peer-to-Peer signaling Protocol like H.323 or SIP from
a computer (NetMeeting for example) going best effort to the Internet for that
best effort traffic, and your phones remain on that Telecom SP's MGC and of EF
marked packets and high quality.

James M. Polk

---

From: Rajeev Gupta <[email-masked]>
Date: Fri, 4 Aug 2000 18:00:20 -0700

Presumably different QoS may be applied to each voice call depending on
parameters such as codec, VAD, customer's tolerance for quality. This is
dynamically determined by the MGC, and can be indicated to the MG, so the MG
can select a suitable QoS path. It is not clear who is setting up the QoS
path - one model is that the MGC simply indicates to the MG the required
QoS, and leaves it to the MG to select the correct mechanism to get the
required QoS e.g. if the MGs are connected over an MPLS network, the MG may
use RSVP to setup the QoS/label for the voice path. In a trunking
application, the MGs may have (MPLS) trunks setup among themselves, perhaps
different trunks for different QoS types, and the MG directs the RTP stream
to the trunk that matches the QoS for the call.
Rajeev Gupta
empowerTel Networks
475 Sycamore Drive, Milpitas, CA 95035
Phone: +1 408 519 7136
Fax: +1 408 519 7420
mailto:[email-masked]
http://www.empowertel.com

  -----Original Message-----
  From: Media Gateway Control (megaco)
[mailto:[email-masked]]On Behalf Of James M. Polk
  Sent: Friday, August 04, 2000 7:13 AM
  To: [email-masked]
  Subject: Re: MG and DiffServ

  Petros

  Who is providing the Service for you Voice traffic? If that is a
Telecommunications Service Provider (as defined by the US FCC), then you
won't have that choice across their network (I don't believe). If that is
from an Enterprise-based Call Agent (MGC), then I'd be surprised if that
were legally allowed to separate this traffic if that Enterprise has the MGC
or Call Agent for Signaling to/from your MG.

  I think you'll have to somehow get the traffic you want to be EF marked
across a Telecom SP and have your Greece-bound traffic across some other
network entirely, then this will work. But (I think) the same MGC cannot
signal both your Greece destination traffic and the rest of your Voice
traffic (as they would be separate networks for signaling).

  One way around that is a Peer-to-Peer signaling Protocol like H.323 or SIP
from a computer (NetMeeting for example) going best effort to the Internet
for that best effort traffic, and your phones remain on that Telecom SP's
MGC and of EF marked packets and high quality.

  James M. Polk

---

From: Mike Buckley <[email-masked]>
Date: Mon, 7 Aug 2000 16:25:02 +0100

ETSI TIPHON have been looking at the problem of end to end QoS control in a mixed IP/circuit switched environment, in particular the general case where a number of separate transport domains and service providers are involved in the call; each transport domain possibly supporting a different QoS mechanism.
 
Within the TIPHON architecture a clear distinction is drawn between application and transport.  The former being IP telephony and the latter IP (or ATM/frame relay) transport.  The required QoS is clearly an issue for the application, in particular the agreement between user and service provider.  However the speech QoS required has to be translated to parameters that can be controlled in the transport domain. e.g. delay, jitter and packet loss.  Diff Serv, RSVP/Intserv, MPLS are generic transport domain mechanism that help deliver the delay, jitter and packet loss requirements required by the application.

The MGC is entirely in the application domain and it is at this level that required end to end QoS is established and authorised.  The MG however spans both transport and application domains.  Media conversion, and possibly RTP, are part of the application, but IP and UDP termination and the QoS mechanisms that go with them are definitely transport.  So within the TIPHON architecture there would be no need to signal issues related to the particular transport QoS mechanism in Megaco (these would be internal to the MG), however delay, jitter and packet loss parameters would be required.  Further details of the TIPHON model can be found in.

http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/07-drafts/wg5/DTS05003/V0.8.1/DTS-5003v0.8.1.zip

Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
[email-masked]

  ----- Original Message ----- 
  From: Rajeev Gupta 
  To: [email-masked] 
  Sent: Saturday, August 05, 2000 2:00 AM
  Subject: Re: MG and DiffServ

  Presumably different QoS may be applied to each voice call depending on parameters such as codec, VAD, customer's tolerance for quality. This is dynamically determined by the MGC, and can be indicated to the MG, so the MG can select a suitable QoS path. It is not clear who is setting up the QoS path - one model is that the MGC simply indicates to the MG the required QoS, and leaves it to the MG to select the correct mechanism to get the required QoS e.g. if the MGs are connected over an MPLS network, the MG may use RSVP to setup the QoS/label for the voice path. In a trunking application, the MGs may have (MPLS) trunks setup among themselves, perhaps different trunks for different QoS types, and the MG directs the RTP stream to the trunk that matches the QoS for the call.
  Rajeev Gupta 
  empowerTel Networks 
  475 Sycamore Drive, Milpitas, CA 95035 
  Phone: +1 408 519 7136 
  Fax: +1 408 519 7420 
  mailto:[email-masked] 
  http://www.empowertel.com 

    -----Original Message-----
    From: Media Gateway Control (megaco) [mailto:[email-masked]]On Behalf Of James M. Polk
    Sent: Friday, August 04, 2000 7:13 AM
    To: [email-masked]
    Subject: Re: MG and DiffServ

    Petros

    Who is providing the Service for you Voice traffic? If that is a Telecommunications Service Provider (as defined by the US FCC), then you won't have that choice across their network (I don't believe). If that is from an Enterprise-based Call Agent (MGC), then I'd be surprised if that were legally allowed to separate this traffic if that Enterprise has the MGC or Call Agent for Signaling to/from your MG.

    I think you'll have to somehow get the traffic you want to be EF marked across a Telecom SP and have your Greece-bound traffic across some other network entirely, then this will work. But (I think) the same MGC cannot signal both your Greece destination traffic and the rest of your Voice traffic (as they would be separate networks for signaling).

    One way around that is a Peer-to-Peer signaling Protocol like H.323 or SIP from a computer (NetMeeting for example) going best effort to the Internet for that best effort traffic, and your phones remain on that Telecom SP's MGC and of EF marked packets and high quality.

    James M. Polk