Hi, All:
We have two parts of H.323 QOS:
1. Pre-call setup phase
2. Call setup phase (where H.245 comes in)
We have done item 1 only so far in H.323 QOS Annex N.
One of the suggestions has been to limit the scope of Annex N in two phases
(AT&T contribution APC-1765):
Phase 1: Item 1 (Pre-call setup phase)
Phase 2: Item 2 (Call setup phase)
Now H.323 supports RSVP and ATM QOS. If there are problems in certain areas,
we like to see how these can be fixed. Contributions will help us how we can
go from there to improve this.
The bottom line is this: We need to work on H.323 Annex N to support QOS.
All suggestion to fix the problems are welcome.
Best regards,
Radhika R. Roy
AT&T
-----Original Message-----
From: Francois Audet [mailto:audet@NORTELNETWORKS.COM]
Sent: Monday, August 14, 2000 2:37 PM
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
I would strongly agree with Mike on this point.
We have a little bit of QoS negotiation in H.245, and it is an unfortuate
mistake that we did so. When you dig a little bit into it, it is pretty
obvious that they don't make much sense. The ATM parameters still have
and editor's note in the actual ASN.1 saying that they are supposed to
be changed to match ITU terminology. That tells me that not many
implementations use this. The RSVP parameters in the ASN.1 basically don't
make any sense. Also, our description of RSVP is really outdated and
tied with RSVP/Intserv and doesn't talk about RSVP/Diffserv.
Let's not do even more damage...
-----Original Message-----
From: Mike Buckley [ mailto:mikebuckley@44COMMS.COM
<mailto:mikebuckley@44COMMS.COM> ]
Sent: Monday, August 14, 2000 10:22 AM
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: H.323 QOS
Radhika,
I agree with everything you say except:
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).
I maintain that H.245 should not be concerning itself with transport domain
issues. All these mechanisms listed are transport domain matters and should
be hidden from the application. In fact they will in general be hidden from
the application.
Mike
Mike Buckley
+44-1457-877718 (T)
+44-1457-877721 (F)
mikebuckley@44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy@ATT.COM>
To: <ITU-SG16@MAILBAG.INTEL.COM>
Sent: Monday, August 14, 2000 4:29 PM
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@ICN.SIEMENS.COM
<mailto:Robert.Callaghan@ICN.SIEMENS.COM> ]
Sent: Monday, August 14, 2000 10:17 AM
To: ITU-SG16@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@ICN.Siemens.com
------------------------------------------------------------------
-----Original Message-----
From: Roy, Radhika R, ALCOO [ mailto:rrroy@ATT.COM <mailto:rrroy@ATT.COM>
]
Sent: Monday, August 14, 2000 9:37 AM
To: ITU-SG16@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@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@ICN.Siemens.com
------------------------------------------------------------------
-----Original Message-----
From: Roy, Radhika R, ALCOO [ mailto:rrroy@ATT.COM
<mailto:rrroy@ATT.COM> ]
Sent: Friday, August 11, 2000 7:59 AM
To: ITU-SG16@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@44COMMS.COM
<mailto:mikebuckley@44COMMS.COM> ]
Sent: Thursday, August 10, 2000 10:19 PM
To: ITU-SG16@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@44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy@ATT.COM>
To: <ITU-SG16@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@att.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com