H.323 QOS

Roy, Radhika R, ALCOO rrroy at ATT.COM
Mon Aug 14 14:29:29 EDT 2000


Hi, Mike:

I guess that we have agreement on the fundamental basis. However, I have
problems when you translate this in signaling terms. As  I have explained
earlier that we are following the exiting framework of H.323 which is the
application layer, and H.323 is transported over one or different transport
networks. H.323 uses H.245 as a common mechanism that helps to transports
the abstraction of H.323 application signaling messages over any networks
(e.g., IP, ATM, etc).

You may look to the H.245 spec very carefully instead of making any
generalized statement.

H.245 provides the bridging between the application layer and transport
layer mechanism. For example, H.245's OLC abstraction is the link for ATM
network layer logical connection as well as for other transport networks.

In the same token, H.323 QOS abstraction may also provide link to the lower
transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM
QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now.

Please also see my reply embedded in you email [RRR].

Again, I would suggest to bring contributions explaining the solution and we
will go from there. In absence of your contributions, I would suggest to
provide comments on Appendix of H.323 QOS Annex N. We can then answer your
questions step by step.

Best regards,
Radhika R. Roy
AT&T

-----Original Message-----
From: Mike Buckley [mailto:mikebuckley at 44COMMS.COM]
Sent: Monday, August 14, 2000 12:56 PM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: H.323 QOS


Radhika,

>However, this is only good for the single network. For example,
>end-to-end RSVP or end-to-end ATM QOS.

>If there are multiple networks or if a single IP network implements RSVP in
>one domain, DiffServ in another domain, and MPLS in another domain, there
is
>no transparent H.323 QOS signaling mechanism that is universal on
end-to-end
>basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
>transparently

This is the nub of the problem and I am afraid why this approach is flawed.
[RRR] I am NOT afraid of anything. Rather we are solving all problems
including the above as well. No one should be afraid of anything. The only
thing that I can suggest is to bring contributions. We will go from there.
Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST provide
backward compatibility. We will be waiting to see contributions from you to
prove your points whether things are flawed or not. Please read Appnedix of
H.323 QOS Annex N  very carefully along with exiting H.323 and H.245
standard how they support H.323 QOS for RSVP and ATM QOS.

>We have shown how the H.323 QOS can
>be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed.

This mapping must be done within the transport plane not by the application.
All the application needs to specify are the entries in your Table 1.  i.e
delay, jitter. packet loss and peak bit rate (the latter parameter for
policy enforcement and resource reservation).
[RRR] Please see my generalized clarification how H.245 provides translation
between H.323 signaling schemes over the lower layer transport networks
(e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is the
beauty of the transport independent H.323 application. Now there are two
separate things: one is what the calling side of the application demands and
what the called side of the application agrees on. This is called
negotiation capability (e.g., choosing a particular type codec that has a
certain bandwidth, jitter, and other requirements). How the choosing
criteria is determined, the H.323 application is NOT aware of those things.
It may depend on many criteria (e.g., policy, bandwidth, type of network
[e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323
is not involved. These are separate issues and we are NOT addressing at the
H.323 layer.

I am still not clkear how you propose to signal these parameters to the
transport plane.
[RRR] It is NOT new in H.323, and this mechanism already exits. Please see
the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing
anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very
carefully, you will find how it happening (whether you call it as transport
plane or something else, it does not matter).

I think we are getting loser to a common understanding.

Mike

Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley at 44comms.com


----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy at ATT.COM>
To: <ITU-SG16 at MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 2:37 PM
Subject: Re: H.323 QOS


Hi, Bob:

I agree completely agree with you.

In fact, we are all trying to achieve the same goal. For example, H.323 does
supports QOS today via H.245. You can easily see that RSVP and ATM QOS are
supported using H.245. The beauty of this approach is that H.245 is still
transport independent. All we have done here is: the abstraction of H.245
has been used to support the RSVP and ATM QOS to implement the network layer
QOS. However, this is only good for the single network. For example,
end-to-end RSVP or end-to-end ATM QOS.

If there are multiple networks or if a single IP network implements RSVP in
one domain, DiffServ in another domain, and MPLS in another domain, there is
no transparent H.323 QOS signaling mechanism that is universal on end-to-end
basis so that it can be mapped over the RSVP, DiffServ, MPLS, ATM QOS, etc
transparently.

In Appendix of H.323 Annex N, we have done the same. We have the abstraction
of H.323 QOS in the application layer. We have shown how the H.323 QOS can
be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. It also provides
the backward compatibility with the existing H.323 standard. However, we
have done only for the pre-call setup signaling part. We have not done the
call setup part yet. In the call setup part, we will include H.245 in a
similar way what H.323 is supporting RSVP and ATM QOS today in a monolithic
network.

I appreciate your email.

Best regards,
Radhika R. Roy
AT&T

> -----Original Message-----
> From: Callaghan, Robert [SMTP:Robert.Callaghan at icn.siemens.com]
> Sent: Monday, August 14, 2000 9:08 AM
> To:   Roy, Radhika R, ALCOO
> Cc:   'Mailing list for parties associated with ITU-T Study Group 16'
> Subject:      RE: H.323 QOS
>
> Roy,
>
> In my view, the network, as a minimum,  needs only provide transport.
> H.323
> is an application using this transport and is not different from any other
> application being transported.  Any application may request a desired
> quality of service that the network may grant based on policies, service
> level agreements, and availability.  Each data connection used by an
> application may request a different QOS.  Most likely H.323 is such an
> application as needing an enhanced QOS.  This simple case should work.
> This
> is all that is required.
>
> In addition to transport, the network may optionally provide other
> additional services.  These services may include application layer
> routing.
> These optional services should be configured and indicated independently
> from the basic transport QOS.
>
> It is correct that H.323, as an application, is (mostly) transport
> independent.  However, the interface between the application and the
> transport layer is not transport independent.  The interface specification
> used to request a given QOS is totally dependant on the standards body
> that
> specified the transport layer; and for this there has been little or no
> coordination.
>
> Because transport QOS over IP is based on IETF specifications, it is
> necessary that the interface used to request a given QOS conform to the
> appropriate IETF specification.  If such an interface specification is not
> available, that input might be provided to the appropriate IETF body as to
> the requirements.
>
> I can see the endpoints negotiating the desired QOS base on need, price,
> and
> other considerations.  For me, this is the limit to the application layer
> involvement in QOS negotiation.  At this point, the application
> negotiations
> with the transport provider as to the desired and available QOS.  It is up
> to the transport provider to arrange for the end-to-end QOS.  (Again, it
> is
> not necessary for the transport network to know that H.323 is involved in
> the transported data.  In fact it may be encrypted in order to mask the
> presence of voice transport.)
>
> For me, this is simple.
>
> Bob
>
> ------------------------------------------------------------------
> Robert Callaghan
> Siemens Enterprise Networks
> Tel: +1.561.923.1756  Fax: +1.561.923.1403
> Email:        Robert.Callaghan at ICN.Siemens.com
> ------------------------------------------------------------------
>
>  -----Original Message-----
> From:         Roy, Radhika R, ALCOO [mailto:rrroy at ATT.COM]
> Sent: Friday, August 11, 2000 7:59 AM
> To:   ITU-SG16 at mailbag.cps.intel.com
> Subject:      Re: H.323 QOS
>
> Hi, Mike:
>
> Let me try again.
>
> What is the reference point of H.323 QOS? Is it not H.323? If it is so,
> what
> do we mean by H.323?
>
> The answer is: Audio (different codecs), Video (different codecs), and
> Data
> (T.120 applications) that are used by H.323.
>
> What are the QOS/performance characteristics of audio, video, and data
> from
> the application point of view that is generated by audio codecs, video
> codecs, and data (T.120) applications?
>
> These QOS/performance characteristics come from the SOURCE codecs and data
> applications. Per transport independent H.323 specifications, an enduser
> express their QOS/performance requirements on end-to-end basis purely from
> application point of view irrespective of the transport network (e.g., IP,
> ATM, etc.).
>
> Moreover, H.323 is meant for the packet network, not for any
> circuit-switched network like PSTN or ISDN.
>
> Let us NOT go beyond this before we start debating transport layer QOS or
> service provider requirements. These are NOT the concern of H.323. H.323
> is
> the transport independent application.
>
> H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be
> used
> for H.323 audio, video, and data. So, H.323 QOS that will be defined in
> H.323 Annex N MUST provide mapping for the backward compatibility. It is a
> requirement that MUST be met per the norm of ITU-T.
>
> So, what is left for mapping? Mapping is simply  a by-product of the above
> requirement. Mapping is simply a table, nothing else.
>
> Did I miss anything?
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley at 44COMMS.COM]
> Sent: Thursday, August 10, 2000 10:19 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> Thanks for the input which I welcome as I will unfortunately not be
> present
> at Portland.
>
> Let me ask a few questions and make a few comments hopefully with the
> intent
> of opening up the debate.
>
> 1.  I am not sure I understand your concept of a mapping table between the
> H.323 QOS and the transport layer QoS.  My understanding is that QoS is on
> three levels:
>
> a)  that specified from a service point of view between the user and
> service
> provider (e.g PSTN quality, conference quality etc)  This is the domain of
> the speech experts and can be characterised by Listener Speech Quaklity
> (MOS), end to end delay, and absolute category rating, R.
>
> b) application specific parameters,  (e.g. equipment delays, codec choice
> and performance, codec frame size, packetisation arrangements, jitter
> buffer
> design, overall packet loss etc.)  Optimisation of all these will
> determine
> what can be delivered in a).
>
> c)  transport parameters for a given choice of application parameters.
> This
> boils down only to three parameters as far as I cna see:  tranport network
> delay, packet delay variation  in the transport network and packet loss in
> the transport network.  Again these parameters will determine the results
> in
> a) for a given choice of the parameters in b).  These parameters are
> generic
> from the perspective of the transport network.  i.e the transport network
> does not need to know the details of the application.
>
> So the sequence of cause and effect and control is:
>
> a)  User requests QoS class from service provider,
> b)  Service provider determines application specific parameters in
> conjunction with users equipment and other service providers,
> c)  Service provider requests required delay, delay variation and packet
> loss from network provider.
>
> I see no need for mapping here.  The only QoS info flows within the
> application are specific to the application and those between the
> application (service provider) and the transport network are generic. i.e.
> delay, jitter and packet loss.  Have I missed something?
>
> 2.  The issue of bit rate and media stream statistics I think need to be
> decoupled from QoS.  These are specified to enable optimisation of
> resources
> within the transport network.  They have no QoS significance from an
> application point of view.  i.e the apllication does not care about the
> media stream bit rate and statistics but the transport network provider
> does
> as it eats up his resource.  They may be used for policy enforcement
> however
> in the transport network so they do need to be agreed between service
> provider and network operator.  i.e the network operator agrees to provide
> a
> given QoS level (delay, jitter, packet loss) provided the media properties
> are within an agreed profile (bit rate,  flow statistics).
>
> 3.  The next point is how can the service provider know the statistics of
> a
> particular VBR stream?  These can only be specified over a large number of
> similar calls and will depend, for instance, on who is speaking, the
> nature
> of the speech interaction  etc etc.  They can only be measured not
> calculated.  The service provider is in no better position to measure
> these
> than the transport network operator and, in fact, where no gateways are
> involved, may not be able to. On the other hand the class of signal would
> have to be signalled to the network operator for him to be able to
> distinguish which class a particular measurement belonged to.  e.g
> voice/speech/data, codec type, conference, multicast etc.  So I see no
> purpose in trying to exchange statistics between the service provider
> (application) and transport operator. I think peak bit rate is all that
> can
> be meaningfully excanged. The specification of media  class is however
> perhaps worth exploring.
>
> 4.  The controlled category has always puzzled me.  I only see two
> possibilities.  Either the requested QoS level is guaranteed (on a
> statistical basis e.g 95% of all connections over a specified period) or
> not
> guaranteed.  Is your controlled category a way of saying guaranteed,  not
> to
> 95% but to some lower figure?  If you can't put a percentage on it then it
> seems it is plain and simple not guaranteed.  Anything that is not
> guaranteed to some specified statistical level is best effort and you
> can't
> say anything more about it.   So I only see two categories here.
>
> In summary, I think we need to do three things in Annex N.
>
> a)  Figure out the QoS information to be exchanged within the Application
> between service providers and end users.  This will go in H.225.0 and
> H.245.
>
> b) Figure out how we are going to signal QoS and media information between
> the application (service providers) and transport domains (IP or ATM
> networks etc).  The info is basically delay, jitter, packet loss
> requirements and peak bit rate.  We need a protocol for this.
>
> c)  we need to work out the interactions between the application QoS
> signal
> flows and  the application/transport signal flows.  I don't think we need
> worry about how the transport network mechanisms assure the requested QoS
> paramerters.  RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all
> possibilities.
>
> Would welcome comments and views on the above.
>
> Mike
>
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley at 44comms.com
>
>
> ----- Original Message -----
> From: "Roy, Radhika R, ALCOO" <rrroy at ATT.COM>
> To: <ITU-SG16 at MAILBAG.INTEL.COM>
> Sent: Thursday, August 10, 2000 10:15 PM
> Subject: H.323 QOS
>
>
> Hi, Mike and All:
>
> It is time to discuss about H.323 QOS.
>
> I believe that we have an agreement as follows:
>
> · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it
> exists for H.323v2/v3/v4
> · Like H.323 spec, the application level H.323 QOS MUST be independent of
> the transport layer QOS and should support all transport networks (e.g.,
> IP,
> ATM)
> · A mapping table between the H.323 QOS and the transport layer QOS (e.g.,
> IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.])
> should be provided.
>
> From the H.323 multimedia application point of view, there are following
> performance parameters can be used to characterize the traffic
> characteristics:
>
> · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR),
> Sustained
> bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum
> rate
> (MR), and mean bust size (MBS)
> · Delay and loss characteristics: end-to-end delay (EED) or delay,
> end-to-end delay variation (EEDV) or delay variation (DV), and
> bit-error-rate (BER) or (packet) loss rate (LR)
>
> We can now form a table with all parameters as follows:
>
> Table 1: H.323 Multimedia Application Performance Matrix
>                 Audio (codecs)---       Video (codecs)---       Data
> (T.120)
> PBR/PR  Yes/No/Value    Yes/No/Value    Yes/No/value
> SBR/AR  Yes/No/Value    Yes/No/Value    Yes/No/value
> MBR/MR  Yes/No/Value    Yes/No/Value    Yes/No/value
> MBS             Yes/No/Value    Yes/No/Value    Yes/No/value
> EED/Delay       Yes/No/Value    Yes/No/Value    Yes/No/value
> EEDV/DV Yes/No/Value    Yes/No/Value    Yes/No/value
> BER/LR  Yes/No/Value    Yes/No/Value    Yes/No/value
>
> From the above table we will have the opportunity to choose each parameter
> for each medium (audio, video, data) that makes sense from the
> application's
> and enduser's point of view. Again, these parameters can be specified as
> follows:
>
> · Guaranteed: The value specified for each parameter MUST be guaranteed.
> · Controlled: The value specified for each parameter MAY be satisfied as
> far
> as practicable (possibly with certain range), but definitely NOT
> guaranteed.
> · Best effort: No commitment will be made.
>
> Now each medium (e.g., audio, video, or data) will have different
> categories
> of performance matrix depending on its selection criteria and this can
> also
> be mapped to RSVP, ATM QOS, and others, if needed.
>
> Once we agree on this format, the next step is to create H.323 QOS
> signaling
> messages.
>
> This is my input for discussion in the upcoming Portland Q.13 meeting for
> H.323 QOS.
>
> I like to see the comments from other members as well.
>
> Best regards,
> Radhika R. Roy
> AT&T
> +1 732 420 1580
> rrroy at att.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list