- sg16-avd - lists.packetizer.com

Communication from TTC
by Sakae OKUBO 16 Aug '00

16 Aug '00

Dear Q12-14/16 experts, Q14 has received a communication from TTC (The Telecommunication Technology Committee, Japan) in response to our communication from Osaka. This has been uploaded to /0008_Por as follows: APC-1948 TTC Chairman of Technical Assembly Reply to report on H.246 Annex E1, Annex E2, Annex E3 and Annex E4 - H.323 and PLMN Interworking Please also note that APC-1921 (Cisco Systems) has been updated to APC-1921a. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1934 uploaded
by $BL'Ln＠paris.packetizer.local 15 Aug '00

15 Aug '00

I have uploaded the APC-1934.zip ("Comments to H.323 Annex K(APC-1811)") file to the Incoming directory of the avc-site. The file have already moved to the Portland directory. Satoshi Minono ------------------------------------------------------------------------------ Oki Electric Industry Co.,Ltd. Tel:3-3454-2111(Ext:45569) Fax:81-3-3798-7684 e-mail:minono888@oki.co.jp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Network at Portland Meeting
by Meyer, Greg W 15 Aug '00

15 Aug '00

Q.11 - 15 Experts: As a reminder, the Portland meeting will be a paperless meeting; there will be no copier services nor mailboxes. This reminder is to insure that attendees bring the proper equipment with them for a successful meeting. Intel will provide the following for connectivity: * 10/100Mbps LAN (switches & hubs) * Windows2000 Server with DHCP, NAT and file services * Internet access through fractional T1 * 802.11b Wireless access points * 120VAC and US power strips The meeting attendees will provide the following: * Computer equipment (laptop, etc.) and peripherals * Power plug adapters * LAN cables, Cat5 with RJ-45 connectors, 25ft/8m in length * 802.11 or 802.11b PC card (optional) * 10/100Mbps PC card Q.11 Experts: You will not have wireless LAN available during your meeting on Thursday and Friday, August 24th & 25th. Please bring a PC card for wired LAN access (10/100Mbps) and a Cat5 cable. We fully expect VPN services to work. We've tested a few different types of VPN clients in this meeting's configuration (Win2K NAT, etc.) without any issues. Please let me know if you have any questions. Greg Meyer Intel Corporation mailto:greg.w.meyer@intel.com +1.503.264.9506 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323 QOS
by Roy, Radhika R, ALCOO 15 Aug '00

15 Aug '00

Hi, Mike: I understand what your concerns. Items 1-4 mentioned by you may also be true for H.323 in general. That is, these items true for any H.323 signaling messages that people want to send across different domains when multiple service/transport providers are there. Our first step is very simple: We will only consider the H.323 level where signaling messages are sent to all H.323 entities. This is our first work item as we do for all H.323 specs. For example, we have seen how H.225.0 Annex G is sending signaling messages across multiple domains. The second step is: How an H.323 service provider and can interwork with a network provider. This area falls into the category of implementation of H.323 over the transport layer including policy, billing, pricing, preferences, etc. TIPHON, IMTC, and other forums may the right place to work in this area. So, I see that we are in agreement. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Tuesday, August 15, 2000 1:29 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, I agree, but I am having some difficulty here with terminology. I differentiate between a service provider (application) and network operator (transport). One (the SP) has a contract with the user the other (IPTO) has a contract with the service provider. Of course they may be the same entity e.g AT&T, but this special case should not be allowed to negate the generality of the model. A service provider owns a box, the network operator a network to which the box is connected. Thus: 1. The user gets authority to send data from the SP, 2. The SP has an agreement with the IPNO to carry authorised data traffic, 3. The SP authorises the IPTO to establish a connection to pass the users traffic. 4. The IPTO applies policy enforcement in line with the SPs policy decision. I accept that a user may also in certain cases have a contract directly with an IPTO i.e a corporate network with a bulk agreement with an IPTO. In this case the user has to look like a service provider to the IPTO. Hope this clarification helps dispel some confusion. 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: Tuesday, August 15, 2000 2:44 PM Subject: Re: H.323 QOS Hi, Bob & Mike: As I mentioned in my earlier emails with respect to Bob questions: Bob wants that a service provider does not like to know whether it is a voice, video, or data call. It is a very simple requirement and one of the subsets that has been stated in Appendix of H.323 QOS Annex N. So, Bob will get his requirement satisfied. However, Appendix of H.323 QOS Annex N does more that. It can also provide differentiated QOS for each medium of H.323 within a given call, if needed. Let us separate two things: 1. What the H.323 QOS signaling messages are in the application layer and 2. What a service provider wants to do in the transport layer. Item 1 is our charter in H.323. We have to see whether item 2 falls into our charter in H.323 layer or it falls into the charter of network layer QOS or it is an implementation aspect of H.323 QOS over the transport layer. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, August 15, 2000 9:18 AM To: ITU-SG16(a)MAILBAG.INTEL.COM 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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Tuesday, August 15, 2000 8:16 AM To: ITU-SG16(a)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(a)44comms.com ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan(a)ICN.SIEMENS.COM> To: <ITU-SG16(a)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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Monday, August 14, 2000 11:29 AM To: ITU-SG16(a)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@ICN.SIEMENS.COM] Sent: Monday, August 14, 2000 10:17 AM To: ITU-SG16(a)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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Monday, August 14, 2000 9:37 AM To: ITU-SG16(a)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(a)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(a)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(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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

2 1

Re: H.323 QOS
by Roy, Radhika R, ALCOO 15 Aug '00

15 Aug '00

Hi, Mike: Yes, you are right that NATs and firewalls problems are yet to be solved with complete satisfaction from address translation point of view. This may be a separate work item all by itself. I do not think that we will bring H.245 to address those problems. In fact, I have not seen any proposal in that direction. We have to separate our works step by step. I would not like to include those general problems as a part of H.323 OQS for now. Let a separate group or annexes deal with those special problems so that we can use those solutions for QOS as well, if needed. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Tuesday, August 15, 2000 1:13 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Hi Radhika, This model is only valid I think when you have end to end address transparency as in the Internet. When different transport network domains are present this doesn't necessarily work. NATs and firewalls will mean that IP addresses and port numbers in different domains will be different for the same media stream. Terminating IP and port numbers may well be different at each end of the call. This is one reason why H.323 will not work through firewalls. To fix this gatekeepers will have to perform a mediating function with the H.323 domain and the transport domains. This mediation will not be via H.245. SIP has the same problems by the way. 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: Tuesday, August 15, 2000 2:15 PM Subject: Re: H.323 QOS Hi, Mike: Just for information, H.245 does many things. As I indicated earlier, one of the most important things of H.245 is the opening and closing of the logical channels that binds the application layer's logical connection abstractions to all transport network connections (e.g., ATM, etc). So, this is the fundamental mission of H.245 to provide the continuity between the application layer and the lower layer in a transport independent way using the universal abstractions. These abstractions can be for anything that we can think of. Hope this helps. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Tuesday, August 15, 2000 8:22 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Hi Radhika, This use of H.245 as a bridging mechanism is where I have difficulties. The original intenmt behind H.245 was media control and negociation. Transport mechanisms should not be signalled in H.245 or elsewhere in the application. This is entirely the business of the transport network provider. Unfortunately I will not be present in Portland, however, I am happy to continue this productive dialogue on the list with a view to providing a new draft in the next few weeks. Regards, 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: Monday, August 14, 2000 7:29 PM Subject: Re: H.323 QOS Hi, Mike: I guess that we have agreement on the fundamental basis. However, I have problems when you translate this in signaling terms. As I have explained earlier that we are following the exiting framework of H.323 which is the application layer, and H.323 is transported over one or different transport networks. H.323 uses H.245 as a common mechanism that helps to transports the abstraction of H.323 application signaling messages over any networks (e.g., IP, ATM, etc). You may look to the H.245 spec very carefully instead of making any generalized statement. H.245 provides the bridging between the application layer and transport layer mechanism. For example, H.245's OLC abstraction is the link for ATM network layer logical connection as well as for other transport networks. In the same token, H.323 QOS abstraction may also provide link to the lower transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now. Please also see my reply embedded in you email [RRR]. Again, I would suggest to bring contributions explaining the solution and we will go from there. In absence of your contributions, I would suggest to provide comments on Appendix of H.323 QOS Annex N. We can then answer your questions step by step. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Monday, August 14, 2000 12:56 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, >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 This is the nub of the problem and I am afraid why this approach is flawed. [RRR] I am NOT afraid of anything. Rather we are solving all problems including the above as well. No one should be afraid of anything. The only thing that I can suggest is to bring contributions. We will go from there. Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST provide backward compatibility. We will be waiting to see contributions from you to prove your points whether things are flawed or not. Please read Appnedix of H.323 QOS Annex N very carefully along with exiting H.323 and H.245 standard how they support H.323 QOS for RSVP and ATM QOS. >We have shown how the H.323 QOS can >be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. This mapping must be done within the transport plane not by the application. All the application needs to specify are the entries in your Table 1. i.e delay, jitter. packet loss and peak bit rate (the latter parameter for policy enforcement and resource reservation). [RRR] Please see my generalized clarification how H.245 provides translation between H.323 signaling schemes over the lower layer transport networks (e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is the beauty of the transport independent H.323 application. Now there are two separate things: one is what the calling side of the application demands and what the called side of the application agrees on. This is called negotiation capability (e.g., choosing a particular type codec that has a certain bandwidth, jitter, and other requirements). How the choosing criteria is determined, the H.323 application is NOT aware of those things. It may depend on many criteria (e.g., policy, bandwidth, type of network [e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323 is not involved. These are separate issues and we are NOT addressing at the H.323 layer. I am still not clkear how you propose to signal these parameters to the transport plane. [RRR] It is NOT new in H.323, and this mechanism already exits. Please see the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very carefully, you will find how it happening (whether you call it as transport plane or something else, it does not matter). I think we are getting loser to a common understanding. 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: Monday, August 14, 2000 2:37 PM 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(a)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(a)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(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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

2 1

Documents uploaded.
by Logan Modahala 15 Aug '00

15 Aug '00

Hi, apc-1942.zip and td-06_2nd_try.zip have been uploaded to /avc-site/Incoming directory for APC-1942 and TD-06 respectively. I had problems with uploading td-06 and hence the second try. -- Logan Modahala lmodahal(a)cisco.com, logan(a)cisco.com 7025 Kit Creek Road, P.O. Box 14987 Research Triangle Park, NC 27709 (919) 392-6561 fax: (919) 392-6801 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC number request for H.248 Annex F status
by Sakae OKUBO 15 Aug '00

15 Aug '00

Dear Mr. Hellstrom, APC-1945 has been allocated to your contribution. >Title: H.248 Annex F fax/text/call discrimination, status and white >draft. > >Source: Editor ( Gunnar Hellstr $BSN (B, Ericsson ) > >Document for: Information Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: H.323 QOS
by Roy, Radhika R, ALCOO 15 Aug '00

15 Aug '00

Hi, Bob: Yes, you are right that "this is done individually during the opening of each media stream." Please see Appendix of H.323 QOS Annex N. You are also right that the by-product solution of H.323 QOS Annex N will provide "the ability to use multiple service providers and to route each stream independently for reliability and optimization." I guess that we are in full agreement. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, August 15, 2000 1:38 PM To: ITU-SG16(a)MAILBAG.INTEL.COM 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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Mike Buckley [mailto:mikebuckley@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(a)44comms.com ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> To: "'Mike Buckley'" <mikebuckley(a)44COMMS.COM> Cc: "'Mailing list for parties associated with ITU-T Study Group 16'" <ITU-SG16(a)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(a)ICN.Siemens.com > ------------------------------------------------------------------ > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Tuesday, August 15, 2000 8:16 AM > To: ITU-SG16(a)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(a)44comms.com > > > ----- Original Message ----- > From: "Callaghan, Robert" <Robert.Callaghan(a)ICN.SIEMENS.COM> > To: <ITU-SG16(a)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(a)ICN.Siemens.com > ------------------------------------------------------------------ > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Monday, August 14, 2000 11:29 AM > To: ITU-SG16(a)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@ICN.SIEMENS.COM] > Sent: Monday, August 14, 2000 10:17 AM > To: ITU-SG16(a)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(a)ICN.Siemens.com > ------------------------------------------------------------------ > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Monday, August 14, 2000 9:37 AM > To: ITU-SG16(a)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(a)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(a)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(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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

1 0

Re: H.323 QOS
by Roy, Radhika R, ALCOO 15 Aug '00

15 Aug '00

Hi, Bob and Chip: We can also support SG3's model (items 1 and 2) in our H.323 QOS model (H.323 Annex N) as a special case. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, August 15, 2000 1:34 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Chip, I agree that the current situation is byzantine. However I think that SG3 has only two choices: 1) Pretend that nothing has changed, attempt to continue the past, and wonder why separations revenues are down. 2) Find a workable solution for the new world where voice is only funny data. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Chip Sharp [mailto:chsharp@cisco.com] Sent: Tuesday, August 15, 2000 12:55 PM To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 QOS At 09:17 AM 8/15/00 -0400, Callaghan, Robert wrote: ...snip... >* 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. ...snip... Settlements in the ISP world are fairly byzantine and don't follow the model used by public telephone carriers today (possible exceptions are some of the arrangements for roaming and wholesale dial). Note the objections to draft Recommendation D.iii in SG3. What you suggest here would require a new business model, billing systems, OSS, etc. in the Service Providers(not to mention supporting the QOS in the first place). However, this is true for the alternatives proposed as well. :-) Chip ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

1 0

Re: H.323 QOS
by Callaghan, Robert 15 Aug '00

15 Aug '00

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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Mike Buckley [mailto:mikebuckley@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(a)44comms.com ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> To: "'Mike Buckley'" <mikebuckley(a)44COMMS.COM> Cc: "'Mailing list for parties associated with ITU-T Study Group 16'" <ITU-SG16(a)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(a)ICN.Siemens.com > ------------------------------------------------------------------ > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Tuesday, August 15, 2000 8:16 AM > To: ITU-SG16(a)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(a)44comms.com > > > ----- Original Message ----- > From: "Callaghan, Robert" <Robert.Callaghan(a)ICN.SIEMENS.COM> > To: <ITU-SG16(a)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(a)ICN.Siemens.com > ------------------------------------------------------------------ > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Monday, August 14, 2000 11:29 AM > To: ITU-SG16(a)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@ICN.SIEMENS.COM] > Sent: Monday, August 14, 2000 10:17 AM > To: ITU-SG16(a)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(a)ICN.Siemens.com > ------------------------------------------------------------------ > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: Monday, August 14, 2000 9:37 AM > To: ITU-SG16(a)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(a)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(a)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(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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

2 1

Re: H.323 QOS
by Roy, Radhika R, ALCOO 15 Aug '00

15 Aug '00

Hi, Skip: Yes, I agree with you. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Chip Sharp [mailto:chsharp@CISCO.COM] Sent: Tuesday, August 15, 2000 12:55 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS At 09:17 AM 8/15/00 -0400, Callaghan, Robert wrote: ...snip... >* 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. ...snip... Settlements in the ISP world are fairly byzantine and don't follow the model used by public telephone carriers today (possible exceptions are some of the arrangements for roaming and wholesale dial). Note the objections to draft Recommendation D.iii in SG3. What you suggest here would require a new business model, billing systems, OSS, etc. in the Service Providers(not to mention supporting the QOS in the first place). However, this is true for the alternatives proposed as well. :-) Chip ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

1 0

Re: H.323 QOS
by Callaghan, Robert 15 Aug '00

15 Aug '00

Chip, I agree that the current situation is byzantine. However I think that SG3 has only two choices: 1) Pretend that nothing has changed, attempt to continue the past, and wonder why separations revenues are down. 2) Find a workable solution for the new world where voice is only funny data. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Chip Sharp [mailto:chsharp@cisco.com] Sent: Tuesday, August 15, 2000 12:55 PM To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 QOS At 09:17 AM 8/15/00 -0400, Callaghan, Robert wrote: ...snip... >* 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. ...snip... Settlements in the ISP world are fairly byzantine and don't follow the model used by public telephone carriers today (possible exceptions are some of the arrangements for roaming and wholesale dial). Note the objections to draft Recommendation D.iii in SG3. What you suggest here would require a new business model, billing systems, OSS, etc. in the Service Providers(not to mention supporting the QOS in the first place). However, this is true for the alternatives proposed as well. :-) Chip ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323 QOS
by Roy, Radhika R, ALCOO 15 Aug '00

15 Aug '00

Hi, Bob & Mike: As I mentioned in my earlier emails with respect to Bob questions: Bob wants that a service provider does not like to know whether it is a voice, video, or data call. It is a very simple requirement and one of the subsets that has been stated in Appendix of H.323 QOS Annex N. So, Bob will get his requirement satisfied. However, Appendix of H.323 QOS Annex N does more that. It can also provide differentiated QOS for each medium of H.323 within a given call, if needed. Let us separate two things: 1. What the H.323 QOS signaling messages are in the application layer and 2. What a service provider wants to do in the transport layer. Item 1 is our charter in H.323. We have to see whether item 2 falls into our charter in H.323 layer or it falls into the charter of network layer QOS or it is an implementation aspect of H.323 QOS over the transport layer. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, August 15, 2000 9:18 AM To: ITU-SG16(a)MAILBAG.INTEL.COM 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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Tuesday, August 15, 2000 8:16 AM To: ITU-SG16(a)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(a)44comms.com ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan(a)ICN.SIEMENS.COM> To: <ITU-SG16(a)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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Monday, August 14, 2000 11:29 AM To: ITU-SG16(a)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@ICN.SIEMENS.COM] Sent: Monday, August 14, 2000 10:17 AM To: ITU-SG16(a)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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Monday, August 14, 2000 9:37 AM To: ITU-SG16(a)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(a)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(a)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(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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

2 1

Re: H.323 QOS
by Roy, Radhika R, ALCOO 15 Aug '00

15 Aug '00

Hi, Mike: Just for information, H.245 does many things. As I indicated earlier, one of the most important things of H.245 is the opening and closing of the logical channels that binds the application layer's logical connection abstractions to all transport network connections (e.g., ATM, etc). So, this is the fundamental mission of H.245 to provide the continuity between the application layer and the lower layer in a transport independent way using the universal abstractions. These abstractions can be for anything that we can think of. Hope this helps. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Tuesday, August 15, 2000 8:22 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Hi Radhika, This use of H.245 as a bridging mechanism is where I have difficulties. The original intenmt behind H.245 was media control and negociation. Transport mechanisms should not be signalled in H.245 or elsewhere in the application. This is entirely the business of the transport network provider. Unfortunately I will not be present in Portland, however, I am happy to continue this productive dialogue on the list with a view to providing a new draft in the next few weeks. Regards, 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: Monday, August 14, 2000 7:29 PM Subject: Re: H.323 QOS Hi, Mike: I guess that we have agreement on the fundamental basis. However, I have problems when you translate this in signaling terms. As I have explained earlier that we are following the exiting framework of H.323 which is the application layer, and H.323 is transported over one or different transport networks. H.323 uses H.245 as a common mechanism that helps to transports the abstraction of H.323 application signaling messages over any networks (e.g., IP, ATM, etc). You may look to the H.245 spec very carefully instead of making any generalized statement. H.245 provides the bridging between the application layer and transport layer mechanism. For example, H.245's OLC abstraction is the link for ATM network layer logical connection as well as for other transport networks. In the same token, H.323 QOS abstraction may also provide link to the lower transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now. Please also see my reply embedded in you email [RRR]. Again, I would suggest to bring contributions explaining the solution and we will go from there. In absence of your contributions, I would suggest to provide comments on Appendix of H.323 QOS Annex N. We can then answer your questions step by step. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Monday, August 14, 2000 12:56 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, >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 This is the nub of the problem and I am afraid why this approach is flawed. [RRR] I am NOT afraid of anything. Rather we are solving all problems including the above as well. No one should be afraid of anything. The only thing that I can suggest is to bring contributions. We will go from there. Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST provide backward compatibility. We will be waiting to see contributions from you to prove your points whether things are flawed or not. Please read Appnedix of H.323 QOS Annex N very carefully along with exiting H.323 and H.245 standard how they support H.323 QOS for RSVP and ATM QOS. >We have shown how the H.323 QOS can >be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. This mapping must be done within the transport plane not by the application. All the application needs to specify are the entries in your Table 1. i.e delay, jitter. packet loss and peak bit rate (the latter parameter for policy enforcement and resource reservation). [RRR] Please see my generalized clarification how H.245 provides translation between H.323 signaling schemes over the lower layer transport networks (e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is the beauty of the transport independent H.323 application. Now there are two separate things: one is what the calling side of the application demands and what the called side of the application agrees on. This is called negotiation capability (e.g., choosing a particular type codec that has a certain bandwidth, jitter, and other requirements). How the choosing criteria is determined, the H.323 application is NOT aware of those things. It may depend on many criteria (e.g., policy, bandwidth, type of network [e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323 is not involved. These are separate issues and we are NOT addressing at the H.323 layer. I am still not clkear how you propose to signal these parameters to the transport plane. [RRR] It is NOT new in H.323, and this mechanism already exits. Please see the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very carefully, you will find how it happening (whether you call it as transport plane or something else, it does not matter). I think we are getting loser to a common understanding. 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: Monday, August 14, 2000 2:37 PM 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(a)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(a)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(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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

2 1

URL to support Number Portability [was: draft-yu-tel-url-00.txt]
by Orit Levin 15 Aug '00

15 Aug '00

James! After reviewing your draft, below are my comments. As in regards to H.323, H.323 doesn't currently have an explicit notion of two different fields carrying the exact meaning of "current destination" and "the final recipient", using SIP language. On the other hand, the definition of H.323 URL potentially allows for cascading of URLs of different kinds. This concept appear in the last draft of "Annex O" to be discussed next week. Therefore, tel url can be placed in the "user" part of H.323 URL. Since, in your proposal, the original "final recipient" information (i.e. the phone number itself) is preserved in the tel url after the NPDB deep is performed, I don't see a technical problem for using the proposed algorithm within H.323. I will bring your work to the attention of H.323 community next week, including the H.323 mobility WG. My question (and that of the H.323 community) would be: what level of consensus does the approach, presented in your draft, currently have within SIP and IPTEL working groups? Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: James Yu <james.yu(a)neustar.com> To: 'Orit Levin' <orit(a)radvision.com>; IPTEL WG <iptel(a)lists.bell-labs.com> Date: Monday, August 14, 2000 1:24 PM Subject: RE: [IPTEL] A draft of H323-URL to be presented during the IPTEL session >Orit, > >Please review the attached draft-yu-tel-url-00.txt, titled "Extensions to >the tel and fax URL to support Number Portability." It is intended for the >SIP to carry number portability (NP) information in the Request URI field. >It may be carried by H.225.0 directly or may be mapped to the proposed H.323 >URL to support NP in H.323. > >There has not been lots of discussion on this I-D. Comments from you and >others are welcome. > >James > > > >-----Original Message----- >From: Orit Levin [mailto:orit@radvision.com] >Sent: Monday, July 31, 2000 9:05 PM >To: IPTEL WG >Subject: [IPTEL] A draft of H323-URL to be presented during the IPTEL >session > > >Hello! >I have submitted the attached draft 3 weeks ago. >Unfortunately, the document doesn't appear on the IETF Drafts site. >Since this topic is going to be presented during the IPTEL session on >Thursday morning, I am attaching the draft for you review. >Best Regards, >Orit Levin >RADVision Inc. >575 Corporate Drive Suite 420 >Mahwah, NJ 07430 >Tel: 1 201 529 4300 (230) >Fax: 1 201 529 3516 >www.radvision.com <http://www.radvision.com> >orit(a)radvision.com <mailto:orit@radvision.com> >-----Original Message----- >From: Orit Levin < orit(a)radvision.com <mailto:orit@radvision.com> > >To: internet-drafts(a)ietf.org <mailto:internet-drafts@ietf.org> < >internet-drafts(a)ietf.org <mailto:internet-drafts@ietf.org> > >Date: Tuesday, July 11, 2000 1:59 AM >Subject: Request for Draft Submission > > >Hello! >I would like to submit the attached paper as the first drafts to become an >Informational RFC. >Thank you, >Orit Levin >RADVision Inc. >575 Corporate Drive Suite 420 >Mahwah, NJ 07430 >Tel: 1 201 529 4300 (230) >Fax: 1 201 529 3516 >www.radvision.com <http://www.radvision.com> >orit(a)radvision.com <mailto:orit@radvision.com> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323 QOS
by Callaghan, Robert 15 Aug '00

15 Aug '00

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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Tuesday, August 15, 2000 8:16 AM To: ITU-SG16(a)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(a)44comms.com ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan(a)ICN.SIEMENS.COM> To: <ITU-SG16(a)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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Monday, August 14, 2000 11:29 AM To: ITU-SG16(a)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@ICN.SIEMENS.COM] Sent: Monday, August 14, 2000 10:17 AM To: ITU-SG16(a)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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Monday, August 14, 2000 9:37 AM To: ITU-SG16(a)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(a)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(a)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(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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

2 1

Re: H.323 QOS
by Chip Sharp 15 Aug '00

15 Aug '00

At 09:17 AM 8/15/00 -0400, Callaghan, Robert wrote: ...snip... >* 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. ...snip... Settlements in the ISP world are fairly byzantine and don't follow the model used by public telephone carriers today (possible exceptions are some of the arrangements for roaming and wholesale dial). Note the objections to draft Recommendation D.iii in SG3. What you suggest here would require a new business model, billing systems, OSS, etc. in the Service Providers(not to mention supporting the QOS in the first place). However, this is true for the alternatives proposed as well. :-) Chip ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323 QOS
by Roy, Radhika R, ALCOO 15 Aug '00

15 Aug '00

Hi, Bob: H.323 QOS is only good for H.323 entities (e.g., terminals, GKs/BEs, MCUs, MCs, GWs, etc.) and signaling is done among these entities. This QOS spec is just another spec in H.323. So, H.323 QOS only sees what is happening in the H.323/H.225.0/H.245 level. Now there are implementation issues in the lower layer. For example, routers that need to transfer media between the terminals or between the GKs/BEs, etc are the functions of the lower network layer. These standards or implementation agreements/policies, etc. are separate from the H.323 layer. If the domains are created using the IP routers , H.323 will NOT see those. If domains are created including GKs, and BEs and media is routed via those GKs/BEs, those GKs/BEs will ONLY be involved for transferring of H.323 QOS information, not the media routing via the routers. So, there are well defined processes how intra-domain and inter-domain QOS will be implemented. Many works are going on in many standard organization to deal with the routing of media to meet the specific network layer QOS: IETF and other organizations. We are progressing step by step. Hope this will help. Best regards, Radhika R. Roy -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Tuesday, August 15, 2000 10:31 AM To: Roy, Radhika R, ALCOO Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: RE: H.323 QOS Roy, What you say about H.245 is true is a serious limitation. H.245 is signaled end-to-end. There is no requirement that H.245 pass through the network in a route with any relationship with the media channels. Therefore, it will be difficult to extend H.245 for the control in intermediate domains along the path used by the media channels. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Tuesday, August 15, 2000 9:16 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 QOS Hi, Mike: Just for information, H.245 does many things. As I indicated earlier, one of the most important things of H.245 is the opening and closing of the logical channels that binds the application layer's logical connection abstractions to all transport network connections (e.g., ATM, etc). So, this is the fundamental mission of H.245 to provide the continuity between the application layer and the lower layer in a transport independent way using the universal abstractions. These abstractions can be for anything that we can think of. Hope this helps. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Tuesday, August 15, 2000 8:22 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Hi Radhika, This use of H.245 as a bridging mechanism is where I have difficulties. The original intenmt behind H.245 was media control and negociation. Transport mechanisms should not be signalled in H.245 or elsewhere in the application. This is entirely the business of the transport network provider. Unfortunately I will not be present in Portland, however, I am happy to continue this productive dialogue on the list with a view to providing a new draft in the next few weeks. Regards, 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: Monday, August 14, 2000 7:29 PM Subject: Re: H.323 QOS Hi, Mike: I guess that we have agreement on the fundamental basis. However, I have problems when you translate this in signaling terms. As I have explained earlier that we are following the exiting framework of H.323 which is the application layer, and H.323 is transported over one or different transport networks. H.323 uses H.245 as a common mechanism that helps to transports the abstraction of H.323 application signaling messages over any networks (e.g., IP, ATM, etc). You may look to the H.245 spec very carefully instead of making any generalized statement. H.245 provides the bridging between the application layer and transport layer mechanism. For example, H.245's OLC abstraction is the link for ATM network layer logical connection as well as for other transport networks. In the same token, H.323 QOS abstraction may also provide link to the lower transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now. Please also see my reply embedded in you email [RRR]. Again, I would suggest to bring contributions explaining the solution and we will go from there. In absence of your contributions, I would suggest to provide comments on Appendix of H.323 QOS Annex N. We can then answer your questions step by step. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Monday, August 14, 2000 12:56 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, >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 This is the nub of the problem and I am afraid why this approach is flawed. [RRR] I am NOT afraid of anything. Rather we are solving all problems including the above as well. No one should be afraid of anything. The only thing that I can suggest is to bring contributions. We will go from there. Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST provide backward compatibility. We will be waiting to see contributions from you to prove your points whether things are flawed or not. Please read Appnedix of H.323 QOS Annex N very carefully along with exiting H.323 and H.245 standard how they support H.323 QOS for RSVP and ATM QOS. >We have shown how the H.323 QOS can >be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. This mapping must be done within the transport plane not by the application. All the application needs to specify are the entries in your Table 1. i.e delay, jitter. packet loss and peak bit rate (the latter parameter for policy enforcement and resource reservation). [RRR] Please see my generalized clarification how H.245 provides translation between H.323 signaling schemes over the lower layer transport networks (e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is the beauty of the transport independent H.323 application. Now there are two separate things: one is what the calling side of the application demands and what the called side of the application agrees on. This is called negotiation capability (e.g., choosing a particular type codec that has a certain bandwidth, jitter, and other requirements). How the choosing criteria is determined, the H.323 application is NOT aware of those things. It may depend on many criteria (e.g., policy, bandwidth, type of network [e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323 is not involved. These are separate issues and we are NOT addressing at the H.323 layer. I am still not clkear how you propose to signal these parameters to the transport plane. [RRR] It is NOT new in H.323, and this mechanism already exits. Please see the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very carefully, you will find how it happening (whether you call it as transport plane or something else, it does not matter). I think we are getting loser to a common understanding. 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: Monday, August 14, 2000 2:37 PM 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(a)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(a)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(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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

1 0

Re: H.323 QOS
by Callaghan, Robert 15 Aug '00

15 Aug '00

Roy, What you say about H.245 is true is a serious limitation. H.245 is signaled end-to-end. There is no requirement that H.245 pass through the network in a route with any relationship with the media channels. Therefore, it will be difficult to extend H.245 for the control in intermediate domains along the path used by the media channels. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Tuesday, August 15, 2000 9:16 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 QOS Hi, Mike: Just for information, H.245 does many things. As I indicated earlier, one of the most important things of H.245 is the opening and closing of the logical channels that binds the application layer's logical connection abstractions to all transport network connections (e.g., ATM, etc). So, this is the fundamental mission of H.245 to provide the continuity between the application layer and the lower layer in a transport independent way using the universal abstractions. These abstractions can be for anything that we can think of. Hope this helps. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Tuesday, August 15, 2000 8:22 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Hi Radhika, This use of H.245 as a bridging mechanism is where I have difficulties. The original intenmt behind H.245 was media control and negociation. Transport mechanisms should not be signalled in H.245 or elsewhere in the application. This is entirely the business of the transport network provider. Unfortunately I will not be present in Portland, however, I am happy to continue this productive dialogue on the list with a view to providing a new draft in the next few weeks. Regards, 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: Monday, August 14, 2000 7:29 PM Subject: Re: H.323 QOS Hi, Mike: I guess that we have agreement on the fundamental basis. However, I have problems when you translate this in signaling terms. As I have explained earlier that we are following the exiting framework of H.323 which is the application layer, and H.323 is transported over one or different transport networks. H.323 uses H.245 as a common mechanism that helps to transports the abstraction of H.323 application signaling messages over any networks (e.g., IP, ATM, etc). You may look to the H.245 spec very carefully instead of making any generalized statement. H.245 provides the bridging between the application layer and transport layer mechanism. For example, H.245's OLC abstraction is the link for ATM network layer logical connection as well as for other transport networks. In the same token, H.323 QOS abstraction may also provide link to the lower transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now. Please also see my reply embedded in you email [RRR]. Again, I would suggest to bring contributions explaining the solution and we will go from there. In absence of your contributions, I would suggest to provide comments on Appendix of H.323 QOS Annex N. We can then answer your questions step by step. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Monday, August 14, 2000 12:56 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, >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 This is the nub of the problem and I am afraid why this approach is flawed. [RRR] I am NOT afraid of anything. Rather we are solving all problems including the above as well. No one should be afraid of anything. The only thing that I can suggest is to bring contributions. We will go from there. Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST provide backward compatibility. We will be waiting to see contributions from you to prove your points whether things are flawed or not. Please read Appnedix of H.323 QOS Annex N very carefully along with exiting H.323 and H.245 standard how they support H.323 QOS for RSVP and ATM QOS. >We have shown how the H.323 QOS can >be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. This mapping must be done within the transport plane not by the application. All the application needs to specify are the entries in your Table 1. i.e delay, jitter. packet loss and peak bit rate (the latter parameter for policy enforcement and resource reservation). [RRR] Please see my generalized clarification how H.245 provides translation between H.323 signaling schemes over the lower layer transport networks (e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is the beauty of the transport independent H.323 application. Now there are two separate things: one is what the calling side of the application demands and what the called side of the application agrees on. This is called negotiation capability (e.g., choosing a particular type codec that has a certain bandwidth, jitter, and other requirements). How the choosing criteria is determined, the H.323 application is NOT aware of those things. It may depend on many criteria (e.g., policy, bandwidth, type of network [e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323 is not involved. These are separate issues and we are NOT addressing at the H.323 layer. I am still not clkear how you propose to signal these parameters to the transport plane. [RRR] It is NOT new in H.323, and this mechanism already exits. Please see the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very carefully, you will find how it happening (whether you call it as transport plane or something else, it does not matter). I think we are getting loser to a common understanding. 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: Monday, August 14, 2000 2:37 PM 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(a)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(a)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(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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

1 0

Re: H.323 QOS
by Roy, Radhika R, ALCOO 15 Aug '00

15 Aug '00

Hi, Mike: I guess that we have agreement on the fundamental basis. However, I have problems when you translate this in signaling terms. As I have explained earlier that we are following the exiting framework of H.323 which is the application layer, and H.323 is transported over one or different transport networks. H.323 uses H.245 as a common mechanism that helps to transports the abstraction of H.323 application signaling messages over any networks (e.g., IP, ATM, etc). You may look to the H.245 spec very carefully instead of making any generalized statement. H.245 provides the bridging between the application layer and transport layer mechanism. For example, H.245's OLC abstraction is the link for ATM network layer logical connection as well as for other transport networks. In the same token, H.323 QOS abstraction may also provide link to the lower transport layer QOS signaling mechanisms (e.g., RSVP, DiffServ, MPLS, ATM QOS, etc), if needed. H.323 DOES support RSVP and ATM QOS now. Please also see my reply embedded in you email [RRR]. Again, I would suggest to bring contributions explaining the solution and we will go from there. In absence of your contributions, I would suggest to provide comments on Appendix of H.323 QOS Annex N. We can then answer your questions step by step. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Monday, August 14, 2000 12:56 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, >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 This is the nub of the problem and I am afraid why this approach is flawed. [RRR] I am NOT afraid of anything. Rather we are solving all problems including the above as well. No one should be afraid of anything. The only thing that I can suggest is to bring contributions. We will go from there. Please remember that H.323 QOS supports RSVP and ATM QOS and we MUST provide backward compatibility. We will be waiting to see contributions from you to prove your points whether things are flawed or not. Please read Appnedix of H.323 QOS Annex N very carefully along with exiting H.323 and H.245 standard how they support H.323 QOS for RSVP and ATM QOS. >We have shown how the H.323 QOS can >be mapped over the RSVP, DiffServ, ATM QOS, etc. if needed. This mapping must be done within the transport plane not by the application. All the application needs to specify are the entries in your Table 1. i.e delay, jitter. packet loss and peak bit rate (the latter parameter for policy enforcement and resource reservation). [RRR] Please see my generalized clarification how H.245 provides translation between H.323 signaling schemes over the lower layer transport networks (e.g., IP, ATM, etc). The mechanism already exists in H.323 and this is the beauty of the transport independent H.323 application. Now there are two separate things: one is what the calling side of the application demands and what the called side of the application agrees on. This is called negotiation capability (e.g., choosing a particular type codec that has a certain bandwidth, jitter, and other requirements). How the choosing criteria is determined, the H.323 application is NOT aware of those things. It may depend on many criteria (e.g., policy, bandwidth, type of network [e.g., IP, ATM], pricing, security, personal preferences, etc.), but H.323 is not involved. These are separate issues and we are NOT addressing at the H.323 layer. I am still not clkear how you propose to signal these parameters to the transport plane. [RRR] It is NOT new in H.323, and this mechanism already exits. Please see the support of RSVP and ATM QOS in H.323/H.245 spec. We are not inventing anything NEW here. Then, if you read Appendix of H.323 QOS Annex N very carefully, you will find how it happening (whether you call it as transport plane or something else, it does not matter). I think we are getting loser to a common understanding. 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: Monday, August 14, 2000 2:37 PM 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(a)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(a)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(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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: H.323 QOS
by Callaghan, Robert 15 Aug '00

15 Aug '00

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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Monday, August 14, 2000 11:29 AM To: ITU-SG16(a)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@ICN.SIEMENS.COM] Sent: Monday, August 14, 2000 10:17 AM To: ITU-SG16(a)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(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] Sent: Monday, August 14, 2000 9:37 AM To: ITU-SG16(a)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(a)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(a)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(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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

2 1

Re: TD for H.225.0 open issues
by Sakae OKUBO 15 Aug '00

15 Aug '00

Dear Mr. Bowen, >Please allocate a TD for a contribution "Open Issues in the H.225.0 v4 >White Contribution" from the H.225.0 editor. TD-07 has been allocated to your contribution. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Documents for the Portland meeting
by Sakae OKUBO 15 Aug '00

15 Aug '00

Dear Q12-14/16 experts, Please find attached a current list of contributions for the next week meeting in Portland. Somehow I cannot find those with * (1884, 1900, 1901, 1902, 1905, 1906, 1924, 1925, 1931, 1940, 1941, 1942) at the ftp site. Please upload them as soon as possible for the member's review, or advise me if my understanding is incorrect. Otherwise they will be dealt with as late arrival contributions whose consideration is subject to the agreement of the meeting. Please also note the following: - APC-1919 has been withdrawn. - Source of APC-1944 has been changed to Editor from Cisco. - APC-1946 has been uploaded to /Incoming in its provisional form. It needs some reformatting without touching the content. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Contributions for the Q12-14/16 Rapporteur meeting in Portland (21 -25 August 2000) * yet to be uploaded ------< carried over from the Osaka meeting >------ APC-1765 AT&T Scope of H.323 QOS APC-1766 AT&T Requirements of H.323 QOS APC-1767 AT&T Architecture of H.323 QOS APC-1768 AT&T Specification of H.323 QOS Characteristics APC-1796 Editor (M Fortinsky) H.225.0 Annex G version1 - with corrections ------< registration for the Portland meeting >------ APC-1872 Q22/11 Liaison to SG16 On Interaction Between Intelligent Network Systems and H.248 APC-1873 Q22/11 Liaison to SG16 On Interworking Between H.323 Systems and Intelligent Network Systems APC-1874 Editor (P Jones) Draft H.323 version 4 APC-1875 Editor (P Jones) H.323-series Implementers Guide APC-1876 Editor (K Klaghofer) Draft Call Offer Supplementary Service for H.323 APC-1877 Editor (K Klaghofer) Draft Call Intrusion Supplementary Service for H.323 APC-1878 Editor (T Anderson) Draft H.323 Annex R (Robustness) APC-1879 Lucent Technologies Reference Points for the Use of Annex G APC-1880 Editor (F Audet) H.323 Annex M.1 "Tunnelling of signalling protocols (QSIG) in H.323" APC-1881 Nortel Networks Enforcing symmetric operation in the context of slow start for H.323v4 APC-1882 Nortel Networks Minor correction to H.323 Annex M.1 APC-1883 Columbia University CPL: A Language for User Control of Internet Telephony Services *APC-1884 SONUS Decomposition of Gatekeeper Functions inside a Domain APC-1885 Hughes Software Systems Enabling H.323-based IVRs in the intelligent network APC-1886 Columbia University RFC-2824: Call Processing Language Framework and Requirements APC-1887 Siemens AG H.450.12 - Common Information Additional Network Feature for H.323 APC-1888 Siemens AG M.3 - Tunneling of DSS1 in H.323 APC-1889 Q4/8 Voice/fax switching in draft H.323 Annex D v2 APC-1890 Q4/8 Facsimile related work on draft H.248 Annex F APC-1891 Q4/8 Draft T.38 Appendix V H.248 Call Establishment Procedure Examples APC-1892 Q4/8 Proposed Edits to H.248 Annex F APC-1893 PictureTel Proposed H.242/H.245 text for dynamicPictureResizingByFour APC-1894 ALCATEL Modification to H.323 annex H APC-1895 ETSI TIPHON WG8 Liaison statement subject: "H.235 Hybrid Security Profile" APC-1896 BT Use of the Generic Framework during Registration and other RAS Messaging APC-1897 BT Additional Data Types for GenericData APC-1898 BT Clarification on the Handling of Unknown conferenceGoals APC-1899 Lucent Technologies Fast Channel Open for H.245 *APC-1900 Editor (P Reddy) H.246 Annex E.1 Interworking between H.225.0 and PLMN's Mobile Application Parts *APC-1901 Editor (P Reddy) H.246 Annex E.2 Interworking between H.225.0 and ANSI-41 PLMN Mobile Application Part *APC-1902 Intel H.323 Mobility services using IETF's Mobile IP and new extended protocols APC-1903 Editor (M Fortinsky) H.225.0 Annex G version 2 - draft APC-1904 Avaya DES with Output Feedback for Audio Encryption in H.235v3 *APC-1905 UCLA Draft text for "Generic Uneven Level Protection (ULP)" for Annex I of H.323 *APC-1906 UCLA Simulation results of ULP for transmission over error prone channels APC-1907 Editor (M Euchner) New Draft H.235 Version 3 APC-1908 Editor (M Euchner) Resolution of an inconsistency in Draft H.235 Version 2 regarding the use of the initial value APC-1909 Editor (J Sundquist) H.323 Annex H Draft APC-1910 LM Ericsson Addition to Implementor's guide to H.248 APC-1911 LM Ericsson Change of Capabilities indicated in H.248 ServiceChange APC-1912 LM Ericsson H.248 Annex L - Error Code and Service Change Reason Description APC-1913 LM Ericsson Improved Auditing in H.248 Version 2 APC-1914 LM Ericsson Comments to H.248 Annex K APC-1915 Editor (P Jones) Fast Connect SDLs Issues APC-1916 Editor (P Jones) Corrections to the H.323v4 White Paper Contribution APC-1917 Cisco Systems JAIN APIs for Integrated Networks APC-1918 Cisco Systems Interworking with Different Versions of H.323 Entities APC-1919 withdrawn APC-1920 Cisco Systems Third Party Re-Routing of a Fast Connect Initiated Call APC-1921 Cisco Systems Early Termination of Fast Connect APC-1922 Trillium Digital Systems, VocalTec Communications Correction to the H.225.0 Annex G UsageSpecification APC-1923 Editor (J Segers) Errors and unclarities in Recommendation H.248 *APC-1924 Editor (T Taylor) Draft H.248 Annex M: Advanced Audio Server Packages *APC-1925 Megaco Chair (T Taylor) IETF Megaco Comments On H.248 Annexes F, G, and H APC-1926 AT&T H.323 Intra-Zone Mobility Management using AuF and HLF APC-1927 Cisco Systems Reserving Resources for Calls APC-1928 Cisco Systems LRQ Forwarding APC-1929 Cisco Systems Alternate Gatekeeper Clarifications APC-1930 Siemens, Intel H.323 Mobility Service Descriptions *APC-1931 Siemens, Intel Interaction of H.323 Mobility with H.450 Supplementary Services APC-1932 AT&T Comments on H.323 Annex H: User, Terminal and Service Mobility (MTD 101b - Editor's Contribution) APC-1933 BT Apply the Generic Framework to Annex G APC-1934 INTEC Web and Genome Informatics Corp., Oki Electric Industry Comments to H.323 Annex K APC-1935 Editor (O Levin) Draft of H.323 Annex O APC-1936 RADVision Expansion of McuInfo field definition in H.225.0 APC-1937 Siemens Security for H.323 Mobile Scenarios - Security for H.323 Annex H/H.235v3 Annex G APC-1938 Editor (D Walker) Draft H.323 Annex L Stimulus Signalling APC-1939 Editor (R Bowen) Draft H.225.0 v4 *APC-1940 Editor (B Aronson) Draft H.323 Annex I *APC-1941 Cisco Systems Enhancements to H.245 Replacement For procedure *APC-1942 Cisco Systems Implementors Guide Recommendations for Tunneling Support in H323 version 2 and H323 version 3 entities APC-1943 Nortel Networks Use of inband tones in H.323 using special RTP payload types APC-1944 Editor (P Jones) Issues with Processing Unsolicited IRRs APC-1945 Editor (G Hellstrom) H.248 Annex F fax/text/call discrimination, status and white draft APC-1946 Surf Communication Solution Procedures for Real-Time Voice Band Modem Communication Over Packet Networks (Modem Relay) APC-1947 ECMA IP Telephony and CSTA --------------- TD-06 Cisco Systems Support for ISUP variants in H.323 Annex M.2 --------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1939 (Draft H.225.0 v4) has been uploaded
by Rich Bowen 15 Aug '00

15 Aug '00

APC-1939 (Draft H.225.0 v4) has been uploaded to the Incoming directory. Regards, Rich Bowen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Late APC for Annex M.2 comments
by Sakae OKUBO 14 Aug '00

14 Aug '00

Dear Mr. Bowen, In the light of application date, let me register your contribution as TD: TD-06 Cisco Systems Support for ISUP variants in H.323 Annex M.2 Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0