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@44COMMS.COM]
Sent: Friday, August 11, 2000 9:01 AM
To: ITU-SG16(a)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(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)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@44COMMS.COM]
Sent: Thursday, August 10, 2000 10:19 PM
To: ITU-SG16(a)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(a)44comms.com
----- Original Message -----
From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM>
To: <ITU-SG16(a)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(a)att.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
