H.323 QOS
Mike Buckley
mikebuckley at 44COMMS.COM
Tue Aug 15 13:49:35 EDT 2000
Bob,
This is most certainly allowed. The QoS requirements and peak bit rate
requirements for each media stream will in general be different. So the QoS
for each media stream has to be handled separately. Aggregation could be
used to tie all media streams to a particular route but this need not be the
case in general. It would be very reasonable to put your date over the non
QoS guaranteed Internet and your voice and video over a QoS engineered and
guaranteed network such as an intranet.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley at 44comms.com
----- Original Message -----
From: "Callaghan, Robert" <Robert.Callaghan at icn.siemens.com>
To: "'Mike Buckley'" <mikebuckley at 44comms.com>
Cc: "'Mailing list for parties associated with ITU-T Study Group 16'"
<ITU-SG16 at mailbag.cps.intel.com>
Sent: Tuesday, August 15, 2000 6:38 PM
Subject: RE: H.323 QOS
> Mike,
>
> As long as this is done individually during the opening of each media
> stream, then I agree. If this is done using an umbrella protocol, then I
> don't agree. I want the ability to use multiple service providers and to
> route each stream independently for reliability and optimization.
>
> 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: Mike Buckley [mailto:mikebuckley at 44comms.com]
> Sent: Tuesday, August 15, 2000 1:00 PM
> To: Callaghan, Robert
> Cc: 'Mailing list for parties associated with ITU-T Study Group 16'
> Subject: Re: H.323 QOS
>
> Bob,
>
> I am not sure that the TIPHON model is that different from what you have
> described.
>
> The TIPHON model has the negotiation on QoS between the User and the
access
> service provider (I define service provider here as the IP Telephony SP).
> There are then a number of possibilities.
>
> 1. The initiating IPTSP negotiates the required end to end QoS parameters
> with other IPTSPs involved in providing end to end service. Each of these
> requests a QoS guaranteed bearer from a generic IP transport provider. The
> inter IPTSP negotiations may not require QoS signalling if a priori SLAs
> exist defining QoS parameter limits.
>
> 2. The initiating IPTSP requests QoS guaranteed bearers with all the IP
> transport providers involved in carrying the media stream end to end.
>
> 3. The initiating IPTSP requests an end to end QoS guaranteed bearer from
> an IP transport provider who proceeds to route the call through
intermediate
> carriers with whom he has QoS SLAs. MPLS fits into this model quite well.
>
> TIPHON regards the first as the general case but this does not prclude any
> of the other approaches listed. Other issues such as NATS, firewalls and
> commercial considerations between ITSPs will dicatate the preferrred
> approach.
>
> In all cases the IP transport provider has no idea that the media stream
is
> speech. And in fact none of the other IPTSPs (other than the initiating
one
> with who the end user has a contract) need know either, all they need to
> know are the QoS parameters associated with the media stream i.e. maximum
> delay, jitter and packet loss. They would also need to know peak bit rate
> for signalling to the transport operators for bandwidth allocation and
> policy enforcement if they were not party to the codec/packetisation
> arrangements.
>
>
> Mike
>
> Mike Buckley
> +44-1457-877718 (T)
> +44-1457-877721 (F)
> mikebuckley at 44comms.com
>
>
> ----- Original Message -----
> From: "Callaghan, Robert" <Robert.Callaghan at icn.siemens.com>
> To: "'Mike Buckley'" <mikebuckley at 44COMMS.COM>
> Cc: "'Mailing list for parties associated with ITU-T Study Group 16'"
> <ITU-SG16 at mailbag.cps.intel.com>
> Sent: Tuesday, August 15, 2000 2:17 PM
> Subject: RE: H.323 QOS
>
>
> > Mike,
> >
> > There is difference between the TIPHON work and what I think is needed:
> >
> > * TIPHON proposes a solution where the originator negotiates with all
> > service providers along the path. This allows each service provider to
> > change for the QoS individually.
> >
> > * My proposal is that the QoS is only negotiated with the original
service
> > provider and that the QoS negotiation be performed between service
> > providers. Only the original service provider charges the user for the
> > service and this charge is split among the other service provider using
a
> > process similar to that used by public telephone carriers today. All
ISPs
> > do this today for basic service, so extending it to enhanced services is
> > reasonable.
> >
> > The other difference is in the information given to the service
providers.
> > I do no want the service providers to know that this is a voice call.
> > Therefore, I do not want to use service provider gatekeepers. I only
want
> > the service providers to provide the requested QoS for any given
> connection
> > without regards to the information content of the connection.
> >
> > You will be missed in Portland. It will be hard to have a comprehensive
> > discussion of the topic with a major participant absent. This is true
as
> > the TIPHON leader, but also you personally.
> >
> > 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: Mike Buckley [mailto:mikebuckley at 44COMMS.COM]
> > Sent: Tuesday, August 15, 2000 8:16 AM
> > To: ITU-SG16 at mailbag.cps.intel.com
> > Subject: Re: H.323 QOS
> >
> > Bob,
> >
> > I agree with your analysis.
> >
> > >Yes, our work is limited to H.323. This limits our ability to create a
> > >general solution. On the other hand, if we consider H.323 QoS
transport
> to
> > >be a value added service, then the service providers can change a
special
> > >value added service charge for H.323 transport. A general solution is
an
> > >advantage to the H.323 solutions in that the QoS service charge is a
> > general
> > >change and not specific to H.323. (Sorry, for some people this is
> heresy.)
> >
> > This is very much the philosophy behind the TIPHON work. QoS will be
> > charged for and there is a need for appropriate mechanisms to guarantee
> what
> > is charged for, to monitor that what has been paid for has been
delivered,
> > and to account and bill. No one in TIPHON expects the Internet will be
> the
> > medium for such value added services.
> >
> > Mike
> >
> >
> > Mike Buckley
> > +44-1457-877718 (T)
> > +44-1457-877721 (F)
> > mikebuckley at 44comms.com
> >
> >
> > ----- Original Message -----
> > From: "Callaghan, Robert" <Robert.Callaghan at ICN.SIEMENS.COM>
> > To: <ITU-SG16 at MAILBAG.INTEL.COM>
> > Sent: Monday, August 14, 2000 7:16 PM
> > Subject: Re: H.323 QOS
> >
> >
> > Roy,
> >
> > Let me summaries my position, then we can talk next week.
> >
> > 1. I agree that H.323 is (mostly) transport independent. I also want
the
> > transport to be application independent. Another words, I do not want
to
> > tell the service provider that I am sending voice or any other media. I
> > only want to tell the service provider that I need a given QoS for the
> data
> > stream.
> >
> > 2. I agree that the QoS needs depend on the needs of a given data
stream.
> > It would be good if this can be specified. However, the means to
specify
> > this should be independent of the transported data (voice).
> >
> > 3. We definitely need a means to specify the end-to-end QoS on a demand
> > basis. I would think that the originating service provider should be
able
> > to receive this and forward it to subsequent service providers based on
> the
> > available and selected route.
> >
> > 4. I agree that the means used to specify the desired QoS should be
> > independent of the transport layer. It should also be independent of
the
> > application.
> >
> > 5. Yes, our work is limited to H.323. This limits our ability to create
a
> > general solution. On the other hand, if we consider H.323 QoS transport
> to
> > be a value added service, then the service providers can change a
special
> > value added service charge for H.323 transport. A general solution is
an
> > advantage to the H.323 solutions in that the QoS service charge is a
> general
> > change and not specific to H.323. (Sorry, for some people this is
> heresy.)
> >
> > Maybe there is a balance between your method of specifying in detail the
> > desired QoS and the fact that it is H.323 specific.
> >
> > 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: Monday, August 14, 2000 11:29 AM
> > To: ITU-SG16 at mailbag.cps.intel.com
> > Subject: Re: H.323 QOS
> >
> > Hi, Bob:
> >
> > I have provide my reply embedded in your email [RRR].
> >
> > In addition, I am providing some general explanation.
> >
> > The fundamental problem is that the network layer QOS signaling schemes
> are
> > different because these are transport dependent. In olden days, we have
> also
> > made application specific to the particular transport mechanism. For
> > example, H.320, H.321, etc.
> >
> > However, the application like H.323 has changed the landscape. It is
> > transport independent although it can be sent over any transport network
> > specific to meets its specific needs. For example, we change the
> abstraction
> > of network address into IP, ATM, etc. as needed. So, this simple example
> > shows how H.323 is transported in a specific network while the "network
> > address" is the universal abstraction for both IP and ATM.
> >
> > If people want to solve having the service level agreement in a specific
> way
> > without using any standards, it is their choice. In fact, many service
> > providers are doing this in a proprietary manner toady. There is no
common
> > standard to express the QOS in a universal way that remains the same on
> > end-to-end basis and there are so many translations in the network layer
> > without having a common reference. As I explained above, if we want to
> make
> > H.323 IP specific, we could do this as well. In this case, we do NOT
need
> to
> > make it transport independent. But the question is: Why did we make
H.323
> > transport independent?
> >
> > We have discussed this a lot in the past while we have been developing
> Annex
> > H.323 N, and have come to the same conclusion that we do need to make
> H.323
> > QOS transport independent so that it can be implemented for any network
or
> a
> > combination of networks or a combination of network layer QOS.
> >
> > It also bridges the fundamental gap that the application (audio codecs,
> > video codecs, data) has its own intrinsic needs to express its QOS
because
> > it is the application whose needs to be satisfied no matter what the
> > underlying transport network or networks may be. The beauty of H.245 is
> that
> > it provides a negotiation capability on end-to-end basis and the same
can
> > also used for QOS (in fact, it is also used to day for RSVP, and ATM QOS
> in
> > a monolithic network).
> >
> > The beauty of H.323 QOS Annex N is that it helps to implement all
> > heterogeneous network layer QOS (RSVP, DiffServ, MPLS, ATM QOS, etc) in
> any
> > combination that people may like to implement.
> >
> > Hope this will clarify your points further.
> >
> > Best regards,
> > Radhika R. Roy
> > AT&T
> >
> > -----Original Message-----
> > From: Callaghan, Robert [mailto:Robert.Callaghan at ICN.SIEMENS.COM]
> > Sent: Monday, August 14, 2000 10:17 AM
> > To: ITU-SG16 at MAILBAG.INTEL.COM
> > Subject: Re: H.323 QOS
> >
> >
> > Roy,
> >
> > I have two points:
> >
> > 1) For me, it is the responsibility of my service provider to provide
the
> > service agreed to in my service level agreement. This may require the
> > existence of service level agreements between service providers; so be
it.
> > This should not be my problem.
> > [RRR] Yes, that is why a service provider needs to have a common set of
> > H.323 QOS that remains the same on end-to-end basis so that H.323
services
> > can be provided transparently. My primary reference point is H.323
service
> > providers, not transport network service providers. A transport network
> > service provider may or may not need H.323 QOS. If a transport service
> > provider may also use H.323 QOS a common basis for mapping among RSVP,
> > DiffServ, MPLS, and ATM QOS at the network layer if they think that
H.323
> > QOS is a good reference based on "standard." Please note that a service
> > provider may have IP, ATM, and/or other networks to provide H.323
> services.
> > So, H.323 QOS will provide to have a common basis for translation in
this
> > heterogeneous networking environment.
> >
> > 2) The interface needed to obtain a given service level should be
> > independent of the application, even when multi-service providers are
> > involved on an end-to-end basis. That is, the interface should work for
> any
> > application. Therefore there should not be any H.323 specific signaling
> > required to obtain the requested QOS.
> > [RRR] We are wearing the "Hat" of H.323. That is, we are NOT talking
about
> > only IP, ATM, etc. We are dealing with the H.323 application and the
> > services related to H.323. So, H.323 QOS needs to be translated as
needed
> in
> > the transport layer.
> >
> > 3) The interface required to signal RSVP, DiffServ, MPLS, ATM QOS, etc.
> are
> > all different. This is recognized today in H.245 in that RSVP and ATM
QOS
> > are handled differently. H.245 should be extended to handle all variant
> of
> > QOS based on the needs of the individual specifications.
> > [RRR] Yes, it is all different QOS in the network layer, but the H.323
> > application is "only one" and remains the same on end-to-end basis, and
> its
> > QOS needs (what we call H.323 QOS end-to-end) is also the same and does
> not
> > change not matter whether the network supports RSVP, DiffServ, MPLS,
> and/or
> > ATM QOS. This is the problem that we have solved in H.323 QOS (you can
see
> > appendix of H.323 Annex N). If you go through appendix of H.323 Annex N,
> you
> > can easily see how this problem has been solved. Please go through this
> > annex N, ask me or others who worked for this annex specific questions
if
> > you have any.
> >
> > 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: Monday, August 14, 2000 9:37 AM
> > To: ITU-SG16 at mailbag.cps.intel.com
> > 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
More information about the sg16-avd
mailing list