H.323 QOS
James Dam
James.Dam at CWO.COM.AU
Wed Aug 16 22:04:57 EDT 2000
Hi Mike,
I am new to this forum, i may be wrong, the following is my offering:
>From a carrier/operator point of view , we need standard body addressing the
end-to-end QoS problems, Echo issues....
We need specs/standards to discuss with other carrier/operator....right now.
So much debate between SIP and H.323 but no real progress on this subject
end-to-end QoS.
As far as i know to date , H.323 is probably in front in many aspects. Why
not going beyond the call.
Best Regards
James Dam
+61 29342 8195
James.Dam at cwo.com.au
> ----------
> From: Mike Buckley
> Reply To: Mailing list for parties associated with ITU-T Study Group
> 16
> Sent: Wednesday, 16 August 2000 11:55 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
> Hi Radhika,
>
> The problem is I don't see a framework in SG16 for how H.323 will be used
> in
> the real world to solve the general end to end QoS problem.
>
> It's no good putting fields in protocols without some idea of how they are
> going to be used in practice. This doesn't mean you want to tie down the
> implementer to go down one particular route but you have to have an
> architecture in mind when you develop a protocol. The IETFs architecture
> is
> clear - it is the Internet. I would submit that this is not necessarily
> what we are doing in SG16.
>
> Let's define the framework of the problem we are going to solve. Much of
> it
> has been covered in this recent thread. But it needs documenting and
> general agreement.
>
> TIPHON is developing a framework for VoIP. SG16 is developing a suite of
> protocols for VoIP. Both need an agreed architecture. The early
> discussions on architecture in TIPHON lead to gateway decomposition and
> the
> birth of H.248. The logical conclusion of this work has lead to the
> present
> TIPHON architecture. Just as the gateway decomposition exercise lead to a
> set of requirements and architecture for H.248, the latest TIPHON
> architecture leads to a set of requirements for QoS control and a QoS
> architecture. See DTS 5003. I want to get general agreement on the
> problem
> we are solving and the roadmap of how we are going to get there. Then we
> can start on the ASN.1.
>
> We should not be considering SIP/SDP in SG16 - neither of these protocols
> are needed if we do our job right with H.323. Policy in the IETF is
> exclusively transport domain policy. Again it has nothing to do with the
> policies we may adopt on application level QoS. As far as I understand
> the
> MCI work this is all about the Internet and makes no recognition of H.323
> or
> other applications. So lets not get lead astray by orthogonal activities
> to
> those we are engaged on. Our job is application level QoS and defining
> the
> services we need from the transport domain to deliver it. We are not
> solving problems in the transport domain. But we can draw up a set of
> requirements for an interface and feed this to the IETF.
>
> Let's get our problem statement clear and our TORs and architecture
> documented and agreed.
>
> 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: Wednesday, August 16, 2000 2:08 PM
> Subject: Re: H.323 QOS
>
>
> Hi, Mike:
>
> Our aim is to extend H.323 for supporting QOS. The framework is already
> there.
>
> Please see H.323 and H.225.0 Annex G specs how the general framework is
> done
> in the context of H.323.
>
> Again, we are dealing with Q.13/16 and TIPHON exceeds the charter of
> Q.13/16. It goes beyond H.323 and involves almost all SGs of ITU-T and
> IETF
> that are dealing with QOS.
>
> I understand what TIPHON is trying to do and TIPHON is just NOT limited to
> Q.13/16. The same problem has been in the IETF when TIPHON presented its
> QOS
> model for extending SIP. It appears that it exceeds the charter of SIP.
>
> Please note that people are NOT saying that TIPHON's work is NOT needed.
> All
> they are saying: Let us divide the work in different items and each item
> will have its place in the corresponding WGs. For example, policy will be
> addressed in the Policy WG, if any particular messages in SIP needs to be
> extended to support QOS following the SIP charter that work may be
> addressed
> in the SIP WG, if any particular item needs to extend in SDP to support
> QOS
> that work needs to be done in the MMUSIC.
>
> From end-to-end call point of view, people will need SIP, SDP, Policy,
> Security, Billing, firewalls, NATs, and others. when the standards in all
> areas are done, people just use them. This is the second step. I have also
> been working with Joon Maeng of VTEL in this area because Joon submitted a
> contribution in Q.13/16 last Feb'99 meeting. We are waiting to complete
> the
> H.323 QOS work first.
>
> You can also see an IETF contribution from MCI WorldCom how the
> interdomain
> QOS can be used by SIP using Policy, Security, etc. This work is dependent
> on the standard work of Policy WG, and others. Again, this contribution
> for
> supporting interdomain QOS by SIP using Policy, etc. does NOT need any
> additional standard work is SIP, it is, rather, an implementation that
> shows
> how an end-to-end call can use all those standards including QOS that have
> been developed in different WGs.
>
> Appendix of H.323 QOS Annex N has the general framework. Now you can go
> through those items and please let us know where you like to see changes
> and
> why.
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley at 44COMMS.COM]
> Sent: Tuesday, August 15, 2000 7:51 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> My aim here is to come up with a general QoS framework in H.323 that will
> handle all these situatioins not just special cases. I think we agree on
> this.
>
> I would be reluctant to solve a special case without an idea of how we are
> going to solve the general case. This can only lead to backward
> compatibility issues.
>
> I believe the TIPHON approach is totally general. However I agree it need
> some new interfaces defining.
>
> 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: Tuesday, August 15, 2000 8:21 PM
> Subject: Re: H.323 QOS
>
>
> Hi, Mike:
>
> Yes, you are right that NATs and firewalls problems are yet to be solved
> with complete satisfaction from address translation point of view. This
> may
> be a separate work item all by itself.
>
> I do not think that we will bring H.245 to address those problems. In
> fact,
> I have not seen any proposal in that direction.
>
> We have to separate our works step by step.
>
> I would not like to include those general problems as a part of H.323 OQS
> for now. Let a separate group or annexes deal with those special problems
> so
> that we can use those solutions for QOS as well, if needed.
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley at 44COMMS.COM]
> Sent: Tuesday, August 15, 2000 1:13 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Hi Radhika,
>
> This model is only valid I think when you have end to end address
> transparency as in the Internet. When different transport network domains
> are present this doesn't necessarily work. NATs and firewalls will mean
> that IP addresses and port numbers in different domains will be different
> for the same media stream. Terminating IP and port numbers may well be
> different at each end of the call. This is one reason why H.323 will not
> work through firewalls. To fix this gatekeepers will have to perform a
> mediating function with the H.323 domain and the transport domains. This
> mediation will not be via H.245.
>
> SIP has the same problems by the way.
>
> 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: Tuesday, August 15, 2000 2:15 PM
> Subject: Re: H.323 QOS
>
>
> Hi, Mike:
>
> Just for information, H.245 does many things. As I indicated earlier, one
> of
> the most important things of H.245 is the opening and closing of the
> logical
> channels that binds the application layer's logical connection
> abstractions
> to all transport network connections (e.g., ATM, etc).
>
> So, this is the fundamental mission of H.245 to provide the continuity
> between the application layer and the lower layer in a transport
> independent
> way using the universal abstractions. These abstractions can be for
> anything
> that we can think of.
>
> Hope this helps.
>
> Best regards,
> Radhika R. Roy
> AT&T
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley at 44COMMS.COM]
> Sent: Tuesday, August 15, 2000 8:22 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Hi Radhika,
>
> This use of H.245 as a bridging mechanism is where I have difficulties.
> The
> original intenmt behind H.245 was media control and negociation.
> Transport
> mechanisms should not be signalled in H.245 or elsewhere in the
> application.
> This is entirely the business of the transport network provider.
>
> Unfortunately I will not be present in Portland, however, I am happy to
> continue this productive dialogue on the list with a view to providing a
> new
> draft in the next few weeks.
>
> Regards,
>
> 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 7:29 PM
> Subject: Re: H.323 QOS
>
>
> 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
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 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
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000817/fdaa62ce/attachment-0004.html>
More information about the sg16-avd
mailing list