Bob,
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.
The problem I think is that we may not be talking about a single network. The Internet may be regarded this way but this is unlikely to be the situation with commercially owned, traffic engineered networks, intranets, extranets etc that will be used for quality controlled VoIP and other applications. Here the media stream passes through a series of separate networks each with its own policies, QoS mechanisms and possibly address spaces. Separating these network domains are firewalls, NATs and policy enforcement elements. Application layer routing will select the sequence of these transport domains through which the media stream will pass. End to end QoS in such situations is as likely to be controlled by the application as it is by service level agreements between IP transport network operators. If the application is selecting the sequence of transport networks then it is logical that establishing end to end QoS will also be in the hands of the application.
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.
As far as I know there is no standard way of signalling QoS between the application (service provider) and IP transport network (network operator). TIPHON have started to try and specify requirements for this. We need a common interface here which is transport mechanism independent. There is no reason why this should not be achievable as the laws of physics require the same parameters to be controlled in the transport domain irrespective of transport technology or QoS mechanisms. i.e. delay, jitter and packet loss. There will need to be a mapping within the transport domain between this common interface and the QoS mechanisms and technologies in this domain.
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.)
From the H.323 multimedia application point of view, there are following
This is fine where SLAs exist between transport operators and the inter-routing is under the control of the IP transport operators. Where this is under the control of a series of service providers the interface between the access service provider and access network operator needs to be duplicated between intermediate service providers and intermedia operators. This approach avoids mapping of QoS mechanisms between network domains, provides a framework for policy enforcement in each domain and allows the use of NATs and firewalls. This is the preferred approach that has been adopted in TIPHON. In short it puts control for QoS with the service providers. Thus if a particular network domain does not support the level of QoS required, the service provider can look for an alternative network operator that can deliver the appropriate QoS guarantees. Having said all this, this approach does not preclude the simplified approach you describe where the responsibility is passed to the access network operator. This is just a special case. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley@44comms.com ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan@ICN.SIEMENS.COM> To: <ITU-SG16@MAILBAG.INTEL.COM> Sent: Monday, August 14, 2000 2:07 PM 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] 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] 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. 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