H.323 QOS

[Roy, Radhika R, ALCOO]

Mike:

I clearly understand your points.

As I suggested earlier, we are differing how we can reach that goal. Please
see my response provided below [RRR].

I appreciate your bigger concerns.

Best regards,
Radhika R. Roy
AT&T

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


Radhika,

I still think we are missing each others point.

I sense that you are saying that we can regard the transport network as a
cloud of heterogeneous domains that will work togewther to sort the problem
of end to end QoS out for you once you have figured out the end to end QoS
parameters required. e.g. delay jitter and packet loss.
[RRR] Yes, more or less you are right. Please note that H.323 has the
negotiation capability. That is, if a request from endpoint is not
acceptable to the other endpoint, the other endpoint can still signal what
it needs to support. Why and how an endpoint will accept or reject an H.323
QOS request will depend on a lot of criteria. As you have mentioned that it
can be: Network layer QOS constraints, policy/security/pricing issues, etc.
We are not addressing from H.323 point of view for now. but you are right
that these are very important issues. I hope that we should do this, but do
we have a charter for doing this?

Their are two basic problems with this approach:

1.  The application needs to signal its QoS needs to the transport network
and provide authorities for policy enforcement.  We have no standard way of
doing this.
[RRR] The policy enforcement is the second step and is not within the
framework of H.323. H.323 QOS is providing only a common sets of QOS
messages for signaling end-to-end. Now the network or networks need to
translate this according to its needs based on policy, preferences,
security, etc. the network may or may not agree on this requirements. That
is, why there is a negotiation in the H.323 layer that is done using H.245.
Please note that there is a lot of standard work in each area: Policy,
Network layer QOS, Billing, Security, and others. We can make a complete
list of it. We, in H.323, will not be addressing these items for now. Each
area is so big that we cannot dig our head from H.323 point of view only.
However, one can use H.323 QOS to link it with policy when the policy
standard is available. For example, a TIPHON/IMTC implementation agreement
can made how policy standard is used for H.323 QOS when both H.323 QOS and
Policy standard are developed independently. In this way, we can complete
our limited charter in a timely fashion.

2.  The transport network may not be homogeneous in that an ISP can talk to
its access network provider and magically the media stream will be delivered
the other side of the globe with the degree of QoS guarantees requested.
There are no mechanisms today for working across different technologies and
QoS mechanisms, firewalls, NATs etc.  These are not just implementation
issues they are fundamental difficulties of  incompatibility.  The Internet
will deliver the seamlessness you are looking for but unfortunatley it won't
deliver the quality or the guarantees.  We have to look for a way round
these difficulties.
[RRR] I understand your points and also thought about this. I am also
observing the efforts of other SGs and IETF in this regard. For example,
NATs are the network layer addressing problems, firewall touches the
application layer as well, there are many mechanisms for the network layer
QOS signaling schemes. For all practical purposes, they will remain and we
cannot do anything unless standard in each area evolve independently. So, we
have our limited charter to define how to signal H.323 QOS on end-to-end
basis. Once we do this, we will be doing our first step in H.323. No one is
addressing the H.323 QOS per se. The next step is how to use H.323 QOS
signaling messages for actual implementation over the lower transport layer.
I understand that there is also a lot of standard work. I call it as the
implementation of H.323 QOS over the lower layer: NATs, Policy knowing the
network layer QOS conditions, Billing constraints for certain network layer
QOS criteria, Security criteria based on firewalls and others, etc. I have a
clear vision how we can work to reach that point as soon as we do our job
that is not done anywhere: H.323 QOS signaling messages for expressing the
application layer QOS on end-to-end basis that remains the same no matter
what the underlying transport mechanism(s) is.

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:19 PM
Subject: Re: H.323 QOS


Hi, Mike:

Please see my reply embedded in you email [Roy, Radhika R.].

My general comment is that H.323 QOS is the application layer because H.323
is an application. Any transport network can use H.323 to implement its
abstraction over its specific transport mechanisms. For example, a network
address can be translated into an IP or ATM address. Or, open logical
channel (OLC) can be translated into ATM or other network layer connection.
This is called the abstraction in the H.323 application layer in a transport
independent way.

So, appendix of H.323 Annex N does the same for the application layer OQS on
an end-to-end basis.

Let us take the simple view so that we can address the H.323 QOS on
end-to-end basis where there is no network related issues, because the
network layer is transparent to the H.323 application layer. The application
H.323 QOS is only deals with the application like audio codecs, video
codecs, and data application. They have their intrinsic QOS needs at the
application layer from endusers' point of view. Let us not jump into NAT,
service providers, ISPs and other issues. Let us assume that nothing like
this exist and see how we can address the simple problem. NATs, ISPs, etc
are the implementation issues and forums like IMTC, TIPHON, and others may
be the right place where those issues can be addressed.

I would appreciate if you would bring contributions against the exiting
appendix of H.323 Annex N explaining where you are disagreeing with and why,
and what you like see to be there keeping the existing framework of H.323
QOS intact where one can implement RSVP and ATM QOS in the network layer if
needed with the help of H.245.

Best regards,
Radhika R. Roy
AT&T

> -----Original Message-----
> From: Mike Buckley [SMTP:mikebuckley at 44COMMS.COM]
> Sent: Sunday, August 13, 2000 10:48 PM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Re: H.323 QOS
>
> Hi Radhika,
>
> See comments below.
>
> 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:48 AM
> Subject: Re: H.323 QOS
>
>
> >Hi, Mike:
>
> >Further to my earlier (enclosed) email, I like to mention that H.323 QOS
> is
> >also addressing problems where a single network may have different kinds
> of
> >network layer QOS signaling schemes. For example, an IP network may have
> >different domains where one domain implements RSVP, the other domain
> >implements DiffServ, and the another domain implements MPLS, etc.
>
> I agree.  A single network (one ownership/administration) can have several
> domains.  This is a particular case of the general case where the call
> passes through many domains with different policies, QoS mechanisms and
> different ownerships also possibly NATs between domains.  I believe this
> is
> the situation for which we have to provide an end to end QoS solution.
        [Roy, Radhika R]  Again, let us address the first one - H.323 QOS
end-to-end independent of the network layer. NATs and domains, etc. are
implementation issues. Other forums like TIPHON, IMTC, etc are bettwe place
to address the implementation related issue.

> >H.323 QOS will provide the end-to-end "application" layer QOS signaling
> >mechanism that is universal from end users' point of view no matter
> whether
> >there are multiple networks (e.g., IP, ATM), or whether one network that
> >implements heterogeneous "network" layer QOS (e.g., RSVP, DiffServ, MPLS,
> >etc.) schemes.
>
> Totally agree.
>
> >By the way, the Appendix of H.323 Annex N has almost all the answers. I
> >strongly believe, as explained in the earlier email per your questions
> >(enclosed), that we have all the solution ready to use. If you have any
> >questions, please also ask me, the past editor Rich Bowen, or others who
> >have been working bringing contributions related to H.323 QOS problems.
>
> I still have not understood why you are signalling transport QoS mechanism
> in H.323 (the application)?  Particularly when you agree the application
> has
> to be transport mechanism independent.  This seems to be the main area we
> disagree on.
        [Roy, Radhika R]  Please see my general comments stated above.
Please also see the existing Appendix of H.323 Annex N. Many comapnies along
with AT&T brought many contributions over the last two years. Accordingly,
Appendix of H.323 Annex N has been created. This mechansim already exist in
H.323 QOS where RSVP and ATM QOS are supported when the QOS mechanism is
supported either for the single IP or for the ATM network individually with
the help of H.245. There is nothing to disgree with, it is alread there in
H.323 standard. Appendix of H.323 Annex N has extended it over multiple
networks or any other combinations that may exist in the lower trnasport
network making the H.323 mechanism indpendent of the transport layer. I like
to see that you bring contributions what you like to see happen explaining
your thoughts.

> Regards,
>
> Mike
>
> >Best regards,
> >Radhika R. Roy
> >AT&T
>
> -----Original Message-----
> From: Roy, Radhika R, ALCOO
> Sent: Friday, August 11, 2000 2:47 PM
> To: 'Mailing list for parties associated with ITU-T Study Group 16'
> Subject: RE: H.323 QOS
>
>
> Hi, Mike:
>
> Please see my response stated below [RRR].
>
> Best regards,
> Radhika
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley at 44COMMS.COM]
> Sent: Friday, August 11, 2000 1:24 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> Sorry , I am not following your arguments here.  I thought your Table 1
> was
> a description of the QoS requirements and media stream properties that
> would
> be signalled by the application/service provider to the network operator.
> This is transport QoS mechansm independent.
> [RRR] Certainly it is NOT the case. It is H.323, and nothing to do with
> service providers or network operators. H.323 spec only deals with the
> application on end-to-end basis.
>
> I maintain that the media statistic parameters can not in general be
> signalled on a per media stream basis.  Only peak bit rate has any meaning
> to the application and derives from the choice of codec and packetisation
> arrangements.
> [RRR] It is NOT true. Please see H.245 spec how each medium is signaled
> along with QOS parameters (e.g., RSVP, ATM QOS). It already exits in
> H.323/H.245 on end-to-end basis if there is only one kind of network. We
> are
> just extending the same concept on end-to-end basis if there is one or
> multiple networks. If there is only one network either IP or ATM, H.323
> QOS
> does NOT need any additional work per se. For IP network, H.323 provides
> the
> support of RSVP and more work may be needed if DiffServ or MPLS needs to
> be
> supported. For ATM QOS, H.323 QOS spec is also complete. But if there are
> combinations of IP and ATM (and/or other networks), there is no end-to-end
> H.323 QOS signaling mechanism that can be used as an universal set across
> all networks. In fact, as I told before, we are SOLVING this problem in
> H..323 Annex N.
>
> In agree the values in the Table do not need to be specified in the
> protocol.  I am happy with YES/NO/Value with Value being optional in the
> case of YES.
> [RRR] I am glad to hear that we are in agreement here.
>
> >So, the first problem is to express performance/QOS parameters that do
> NOT
> >contain any values. That is, it will have only the parameters without any
> >value. For example, all audio/video codecs will have their parameters
> >expressed that will have only a limited set (in the previous case as can
> be
> >seen in Appendix of Annex N - there has been only 4 sets, etc.). These
> are
> >universal sets and does not matter what the codec type is.
>
> You have lost me here.  What is the point signalling empty sets?
> [RRR] Please see the Appendix of H.323 Annex N how the QOS classes and the
> corresponding signaling messages have been created, and how the signaling
> will be done. There are two stages of H.313 QOS signaling: 1. Pre-call
> setup
> phase and 2. Call setup phase. In pre-call setup, it is the empty
> signaling
> messages sets that will be sent to determine whether these kind of QOS
> classes are supported on end-to-end basis. It is called the discovery
> phase.
> So far, it has been the ONLY goal for H.323 QOS.
>
> [RRR] For the call setup phase, the actual values of all those parameters
> are needed. We expect that the values can be chosen by endusers if there
> are
> no standards. However, if other SGs or forums (e.g., TIPHON, IMTC, SLA
> agreements, etc.) define those values, people can also use those specific
> values. Then the H.323 QOS signaling messages can use those implementation
> specific values. H.323 QOS will only have the place holder for those
> values.
>
> The order
> of events must surely be: [RRR] the order of events are shown in Appendix
> of
> H.323 Annex N.
>
> a) User requests QoS level of service provider: gold, silver etc.
> [RRR] Again, this is implementation specific and SG16 is not the right
> place
> to define gold, silver, etc. for H.323.
>
> b) Application uses H.225.0 and H.245 to establish compatible codecs and
> packetisation arrangements consistent with a),
> [RRR] H.245 is currently using RSVP and ATM QOS and we will use the
> similar
> approach. No new work is needed here.
>
> c)  Application computes  delay, delay variation and bit error rate
> required
> of transport network and signalls these to transport network operator.
> [RRR] We do not need to do anything NEW other than the similar thing what
> H.245 is doing currently for RSVP and ATM QOS.
>
> H.225.0 and h.245 will be used to:
>
> a) register a terminal's QoS characteristics with the service provider
> (gatekeeper).
> [RRR] H.323 does not define anything related to service providers,
> application providers, or network providers. It is implementation
> specific.
> It will only deal with the H.323 QOS signaling messages on end-to-end
> basis
> as it has been dong for RSVP and ATM QOS. Let other SGs or forums do some
> implementation specific agreement/standard for H.323 QOS.
>
> b) for user to request gold, silver or bronze or the end to end QoS
> parameters from a service provider (gatekeeper),
> [RRR] Again, it is an implementation issue, not a H.323 QOS protocol
> issue:
> gold, silver, etc. My response for item a is applicable.
>
> c) for service providers (gatekeepers) to signal QoS parameters to each
> other to enable end to end QoS levels to be achieved.
> [RRR] Again a GK can signal QOS parameters, but H.323 does not recognize
> service providers, applications providers, or network providers. However,
> the GK will signal using the H.323 QOS messages. The QOS signaling
> messages
> will contain many parameters (I do not think that it will contain QOS
> level
> per se).
>
> d) to establish compatible codecs and packetisation at both ends of a
> media
> stream.
> [RRR] H.245 has well established negotiation capabilities. We do not need
> to
> do any additional work here.
>
> Registration will take place prior to call set up.  The rest of the QoS
> information flows must take place at call set up.
> [RRR] Please see my answers provided above. Currently, Appendix of H.323
> Annex N has it completed how the pre-call setup signaling messages can be
> exchanged. The call setup phase will use the same mechanism as it exists
> today for RSVP and ATM QOS. We will only augment this using NEW parameters
> of H.323 QOS.
>
> We need a new protocol for signalling QoS requirements and authorisations
> to
> the network operator.
> [RRR] The pre-call setup and call setup phase that will use H.323 QOS
> messages (as shown in Appendix of H.323 QOS) will meet the QOS
> requirements.
> I do not think that we should "INVENT" any new security mechanisms ONLY
> specific to H.323 QOS. Security should be dealt for H.323 in general. This
> work MUST be de-coupled from H.323 QOS.
>
>
> Let's continue the debate on this lists - this is the best way of arriving
> at an agreed approach.  Documenting it once we have agreement on what the
> problem is and how we are going to solve it should be quite
> straightforward.
> I hope we will have something to determine in November.
> [RRR] Yes, this has been the main purpose of my email. Moreover, emails go
> to all people throughout the whole world. Each one of us can participate.
> This is the MOST convenient way for resolving issues. I appreciate your
> response.
>
> 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: Friday, August 11, 2000 5:09 PM
> Subject: Re: H.323 QOS
>
>
> Hi, Mike:
>
> Please note the following:
>
> Table 1 shows all parameters that are observed in digitization form.
> (There
> may be similarity with some transport level parameters, but these are
> expressed in a transport independent way.)
>
> A given codec/data (appln.) may or may have all the parameters. If not,
> those parameters will be NOT be used.
>
> Each parameter contain: Yes/No and Value.
>
> So, the first problem is to express performance/QOS parameters that do NOT
> contain any values. That is, it will have only the parameters without any
> value. For example, all audio/video codecs will have their parameters
> expressed that will have only a limited set (in the previous case as can
> be
> seen in Appendix of Annex N - there has been only 4 sets, etc.). These are
> universal sets and does not matter what the codec type is.
>
> In H.323, we are NOT defining values of the parameters because values are
> subjective and implementation dependent. The values of any given QOS
> parameter or a set of QOS parameters are beyond the scope of H.323
> (Q.13/16). The values are being defined in other SGs or organizations
> (e.g.,
> TIPHON, IMTC, etc.).
>
> You are right that the values for each codec will be different. People may
> define many classes based on values as well. For example, 100ms delay is
> gold service, 150ms delay is silver service, etc. In Annex N, we will not
> be
> addressing those values.
>
> The same is also true for data.
>
> Defining of QOS values of any given parameters is OUT of scope of H.323.
>
> It appears that there is a mis-understanding. I do not any intention for
> any
> personal attack other than to complete the work on time (if it appears so,
> I
> apologize for this).
>
> Hope this clarifies your questions.
>
> Best regards,
> Radhika R. Roy
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley at 44COMMS.COM]
> Sent: Friday, August 11, 2000 11:08 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> >The basic problem is to express the end-to-end H.323 QOS parameters of
> each
> >medium (audio, video, data) that are applicable no matter what the
> >underlying transport network (or networks) is.
>
> >The answer of this problem is Table 1 that I have provided.
>
> We agree on the first paragraph.  The problem I have with your Table 1
> relates to media statistics (see my earlier comments).  Incidentally the
> columns are the properties of transport media streams.  the values  will
> be
> dependent on media type, codec, packetisation etc.  So I am not sure what
> the relevance of codec or T.120 is in the heading.  The parameters in each
> column are what I regard as the generic bearer descriptor.
>
> >Now we have to group those parameters in different combinations for each
> >medium that makes sense from the enduser point of view to satisfy their
> >requirements.
>
> >This is the simple problem.
>
> The values follow from the users QoS service request, and the choices made
> by the application in achieving this (codec type, packetisation, jitter
> buffer design).  Once the application has figured out what these
> parameters
> are then the entries in your table can be computed by the application and
> flagged to the transport operator on a domain by domain basis or
> end-to-end
> if there is one homogeneous transport space.
>
> >A by-product of this solution needs to satisfy RSVP and ATM QOS as
> >H.323v2/v3/v4 spec is doing today.
>
> I see no conflict with the use of these transport mechanisms in the
> transport plane. You seem terribly worried about this.  What is the
> problem?
>
> >I am surprised to see that you are still saying that your are NOT
> familiar
> >with H.323. If it is so, we have problems. An editor needs to be on the
> top
> >of everything because the last editor did a good amount of job in a very
> >short period of time addressing all issues. We are now going backward and
> >losing our valuable time just because the editor is NOT familiar with
> H.323.
> >If you ask questions,  I would be happy to answer as much as I can.
>
> You are putting words into my mouth here that I never used.   Why the
> personal attack?  I thought the discussion  had been quite constructive up
> to this point.
>
> 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: Friday, August 11, 2000 2:41 PM
> Subject: Re: H.323 QOS
>
>
> Hi, Mike:
>
> The basic problem is to express the end-to-end H.323 QOS parameters of
> each
> medium (audio, video, data) that are applicable no matter what the
> underlying transport network (or networks) is.
>
> The answer of this problem is Table 1 that I have provided.
>
> Now we have to group those parameters in different combinations for each
> medium that makes sense from the enduser point of view to satisfy their
> requirements.
>
> This is the simple problem.
>
> A by-product of this solution needs to satisfy RSVP and ATM QOS as
> H.323v2/v3/v4 spec is doing today.
>
> I am surprised to see that you are still saying that your are NOT familiar
> with H.323. If it is so, we have problems. An editor needs to be on the
> top
> of everything because the last editor did a good amount of job in a very
> short period of time addressing all issues. We are now going backward and
> losing our valuable time just because the editor is NOT familiar with
> H.323.
> If you ask questions,  I would be happy to answer as much as I can.
>
> I like to see other members also provide comments on this.
>
> Best regards,
> Radhika
>
> -----Original Message-----
> From: Mike Buckley [mailto:mikebuckley at 44COMMS.COM]
> Sent: Friday, August 11, 2000 9:01 AM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: H.323 QOS
>
>
> Radhika,
>
> I think we are in total agreement until your last two paragraphs.  Lets
> figure out what problem we are solving and what we need to do to achieve
> this, then examine the issues of backward compatibility.
>
> You are a lot more familiar than I am with the existing H.323 mechansims.
> Why are these not transport mechansm independent as per your model?
>
> 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: Friday, August 11, 2000 12:58 PM
> 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