- sg16-avd - lists.packetizer.com

Subscribe
by Aggarwal, Mitu 14 Aug '00

14 Aug '00

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 14 Aug '00

14 Aug '00

Mike: I clearly understand your points. As I suggested earlier, we are differing how we can reach that goal. Please see my response provided below [RRR]. I appreciate your bigger concerns. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Monday, August 14, 2000 12:46 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, I still think we are missing each others point. I sense that you are saying that we can regard the transport network as a cloud of heterogeneous domains that will work togewther to sort the problem of end to end QoS out for you once you have figured out the end to end QoS parameters required. e.g. delay jitter and packet loss. [RRR] Yes, more or less you are right. Please note that H.323 has the negotiation capability. That is, if a request from endpoint is not acceptable to the other endpoint, the other endpoint can still signal what it needs to support. Why and how an endpoint will accept or reject an H.323 QOS request will depend on a lot of criteria. As you have mentioned that it can be: Network layer QOS constraints, policy/security/pricing issues, etc. We are not addressing from H.323 point of view for now. but you are right that these are very important issues. I hope that we should do this, but do we have a charter for doing this? Their are two basic problems with this approach: 1. The application needs to signal its QoS needs to the transport network and provide authorities for policy enforcement. We have no standard way of doing this. [RRR] The policy enforcement is the second step and is not within the framework of H.323. H.323 QOS is providing only a common sets of QOS messages for signaling end-to-end. Now the network or networks need to translate this according to its needs based on policy, preferences, security, etc. the network may or may not agree on this requirements. That is, why there is a negotiation in the H.323 layer that is done using H.245. Please note that there is a lot of standard work in each area: Policy, Network layer QOS, Billing, Security, and others. We can make a complete list of it. We, in H.323, will not be addressing these items for now. Each area is so big that we cannot dig our head from H.323 point of view only. However, one can use H.323 QOS to link it with policy when the policy standard is available. For example, a TIPHON/IMTC implementation agreement can made how policy standard is used for H.323 QOS when both H.323 QOS and Policy standard are developed independently. In this way, we can complete our limited charter in a timely fashion. 2. The transport network may not be homogeneous in that an ISP can talk to its access network provider and magically the media stream will be delivered the other side of the globe with the degree of QoS guarantees requested. There are no mechanisms today for working across different technologies and QoS mechanisms, firewalls, NATs etc. These are not just implementation issues they are fundamental difficulties of incompatibility. The Internet will deliver the seamlessness you are looking for but unfortunatley it won't deliver the quality or the guarantees. We have to look for a way round these difficulties. [RRR] I understand your points and also thought about this. I am also observing the efforts of other SGs and IETF in this regard. For example, NATs are the network layer addressing problems, firewall touches the application layer as well, there are many mechanisms for the network layer QOS signaling schemes. For all practical purposes, they will remain and we cannot do anything unless standard in each area evolve independently. So, we have our limited charter to define how to signal H.323 QOS on end-to-end basis. Once we do this, we will be doing our first step in H.323. No one is addressing the H.323 QOS per se. The next step is how to use H.323 QOS signaling messages for actual implementation over the lower transport layer. I understand that there is also a lot of standard work. I call it as the implementation of H.323 QOS over the lower layer: NATs, Policy knowing the network layer QOS conditions, Billing constraints for certain network layer QOS criteria, Security criteria based on firewalls and others, etc. I have a clear vision how we can work to reach that point as soon as we do our job that is not done anywhere: H.323 QOS signaling messages for expressing the application layer QOS on end-to-end basis that remains the same no matter what the underlying transport mechanism(s) is. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(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:19 PM Subject: Re: H.323 QOS Hi, Mike: Please see my reply embedded in you email [Roy, Radhika R.]. My general comment is that H.323 QOS is the application layer because H.323 is an application. Any transport network can use H.323 to implement its abstraction over its specific transport mechanisms. For example, a network address can be translated into an IP or ATM address. Or, open logical channel (OLC) can be translated into ATM or other network layer connection. This is called the abstraction in the H.323 application layer in a transport independent way. So, appendix of H.323 Annex N does the same for the application layer OQS on an end-to-end basis. Let us take the simple view so that we can address the H.323 QOS on end-to-end basis where there is no network related issues, because the network layer is transparent to the H.323 application layer. The application H.323 QOS is only deals with the application like audio codecs, video codecs, and data application. They have their intrinsic QOS needs at the application layer from endusers' point of view. Let us not jump into NAT, service providers, ISPs and other issues. Let us assume that nothing like this exist and see how we can address the simple problem. NATs, ISPs, etc are the implementation issues and forums like IMTC, TIPHON, and others may be the right place where those issues can be addressed. I would appreciate if you would bring contributions against the exiting appendix of H.323 Annex N explaining where you are disagreeing with and why, and what you like see to be there keeping the existing framework of H.323 QOS intact where one can implement RSVP and ATM QOS in the network layer if needed with the help of H.245. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Mike Buckley [SMTP:mikebuckley@44COMMS.COM] > Sent: Sunday, August 13, 2000 10:48 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > Hi Radhika, > > See comments below. > > Mike > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(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:48 AM > Subject: Re: H.323 QOS > > > >Hi, Mike: > > >Further to my earlier (enclosed) email, I like to mention that H.323 QOS > is > >also addressing problems where a single network may have different kinds > of > >network layer QOS signaling schemes. For example, an IP network may have > >different domains where one domain implements RSVP, the other domain > >implements DiffServ, and the another domain implements MPLS, etc. > > I agree. A single network (one ownership/administration) can have several > domains. This is a particular case of the general case where the call > passes through many domains with different policies, QoS mechanisms and > different ownerships also possibly NATs between domains. I believe this > is > the situation for which we have to provide an end to end QoS solution. [Roy, Radhika R] Again, let us address the first one - H.323 QOS end-to-end independent of the network layer. NATs and domains, etc. are implementation issues. Other forums like TIPHON, IMTC, etc are bettwe place to address the implementation related issue. > >H.323 QOS will provide the end-to-end "application" layer QOS signaling > >mechanism that is universal from end users' point of view no matter > whether > >there are multiple networks (e.g., IP, ATM), or whether one network that > >implements heterogeneous "network" layer QOS (e.g., RSVP, DiffServ, MPLS, > >etc.) schemes. > > Totally agree. > > >By the way, the Appendix of H.323 Annex N has almost all the answers. I > >strongly believe, as explained in the earlier email per your questions > >(enclosed), that we have all the solution ready to use. If you have any > >questions, please also ask me, the past editor Rich Bowen, or others who > >have been working bringing contributions related to H.323 QOS problems. > > I still have not understood why you are signalling transport QoS mechanism > in H.323 (the application)? Particularly when you agree the application > has > to be transport mechanism independent. This seems to be the main area we > disagree on. [Roy, Radhika R] Please see my general comments stated above. Please also see the existing Appendix of H.323 Annex N. Many comapnies along with AT&T brought many contributions over the last two years. Accordingly, Appendix of H.323 Annex N has been created. This mechansim already exist in H.323 QOS where RSVP and ATM QOS are supported when the QOS mechanism is supported either for the single IP or for the ATM network individually with the help of H.245. There is nothing to disgree with, it is alread there in H.323 standard. Appendix of H.323 Annex N has extended it over multiple networks or any other combinations that may exist in the lower trnasport network making the H.323 mechanism indpendent of the transport layer. I like to see that you bring contributions what you like to see happen explaining your thoughts. > Regards, > > Mike > > >Best regards, > >Radhika R. Roy > >AT&T > > -----Original Message----- > From: Roy, Radhika R, ALCOO > Sent: Friday, August 11, 2000 2:47 PM > To: 'Mailing list for parties associated with ITU-T Study Group 16' > Subject: RE: H.323 QOS > > > Hi, Mike: > > Please see my response stated below [RRR]. > > Best regards, > Radhika > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Friday, August 11, 2000 1:24 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > > Radhika, > > Sorry , I am not following your arguments here. I thought your Table 1 > was > a description of the QoS requirements and media stream properties that > would > be signalled by the application/service provider to the network operator. > This is transport QoS mechansm independent. > [RRR] Certainly it is NOT the case. It is H.323, and nothing to do with > service providers or network operators. H.323 spec only deals with the > application on end-to-end basis. > > I maintain that the media statistic parameters can not in general be > signalled on a per media stream basis. Only peak bit rate has any meaning > to the application and derives from the choice of codec and packetisation > arrangements. > [RRR] It is NOT true. Please see H.245 spec how each medium is signaled > along with QOS parameters (e.g., RSVP, ATM QOS). It already exits in > H.323/H.245 on end-to-end basis if there is only one kind of network. We > are > just extending the same concept on end-to-end basis if there is one or > multiple networks. If there is only one network either IP or ATM, H.323 > QOS > does NOT need any additional work per se. For IP network, H.323 provides > the > support of RSVP and more work may be needed if DiffServ or MPLS needs to > be > supported. For ATM QOS, H.323 QOS spec is also complete. But if there are > combinations of IP and ATM (and/or other networks), there is no end-to-end > H.323 QOS signaling mechanism that can be used as an universal set across > all networks. In fact, as I told before, we are SOLVING this problem in > H..323 Annex N. > > In agree the values in the Table do not need to be specified in the > protocol. I am happy with YES/NO/Value with Value being optional in the > case of YES. > [RRR] I am glad to hear that we are in agreement here. > > >So, the first problem is to express performance/QOS parameters that do > NOT > >contain any values. That is, it will have only the parameters without any > >value. For example, all audio/video codecs will have their parameters > >expressed that will have only a limited set (in the previous case as can > be > >seen in Appendix of Annex N - there has been only 4 sets, etc.). These > are > >universal sets and does not matter what the codec type is. > > You have lost me here. What is the point signalling empty sets? > [RRR] Please see the Appendix of H.323 Annex N how the QOS classes and the > corresponding signaling messages have been created, and how the signaling > will be done. There are two stages of H.313 QOS signaling: 1. Pre-call > setup > phase and 2. Call setup phase. In pre-call setup, it is the empty > signaling > messages sets that will be sent to determine whether these kind of QOS > classes are supported on end-to-end basis. It is called the discovery > phase. > So far, it has been the ONLY goal for H.323 QOS. > > [RRR] For the call setup phase, the actual values of all those parameters > are needed. We expect that the values can be chosen by endusers if there > are > no standards. However, if other SGs or forums (e.g., TIPHON, IMTC, SLA > agreements, etc.) define those values, people can also use those specific > values. Then the H.323 QOS signaling messages can use those implementation > specific values. H.323 QOS will only have the place holder for those > values. > > The order > of events must surely be: [RRR] the order of events are shown in Appendix > of > H.323 Annex N. > > a) User requests QoS level of service provider: gold, silver etc. > [RRR] Again, this is implementation specific and SG16 is not the right > place > to define gold, silver, etc. for H.323. > > b) Application uses H.225.0 and H.245 to establish compatible codecs and > packetisation arrangements consistent with a), > [RRR] H.245 is currently using RSVP and ATM QOS and we will use the > similar > approach. No new work is needed here. > > c) Application computes delay, delay variation and bit error rate > required > of transport network and signalls these to transport network operator. > [RRR] We do not need to do anything NEW other than the similar thing what > H.245 is doing currently for RSVP and ATM QOS. > > H.225.0 and h.245 will be used to: > > a) register a terminal's QoS characteristics with the service provider > (gatekeeper). > [RRR] H.323 does not define anything related to service providers, > application providers, or network providers. It is implementation > specific. > It will only deal with the H.323 QOS signaling messages on end-to-end > basis > as it has been dong for RSVP and ATM QOS. Let other SGs or forums do some > implementation specific agreement/standard for H.323 QOS. > > b) for user to request gold, silver or bronze or the end to end QoS > parameters from a service provider (gatekeeper), > [RRR] Again, it is an implementation issue, not a H.323 QOS protocol > issue: > gold, silver, etc. My response for item a is applicable. > > c) for service providers (gatekeepers) to signal QoS parameters to each > other to enable end to end QoS levels to be achieved. > [RRR] Again a GK can signal QOS parameters, but H.323 does not recognize > service providers, applications providers, or network providers. However, > the GK will signal using the H.323 QOS messages. The QOS signaling > messages > will contain many parameters (I do not think that it will contain QOS > level > per se). > > d) to establish compatible codecs and packetisation at both ends of a > media > stream. > [RRR] H.245 has well established negotiation capabilities. We do not need > to > do any additional work here. > > Registration will take place prior to call set up. The rest of the QoS > information flows must take place at call set up. > [RRR] Please see my answers provided above. Currently, Appendix of H.323 > Annex N has it completed how the pre-call setup signaling messages can be > exchanged. The call setup phase will use the same mechanism as it exists > today for RSVP and ATM QOS. We will only augment this using NEW parameters > of H.323 QOS. > > We need a new protocol for signalling QoS requirements and authorisations > to > the network operator. > [RRR] The pre-call setup and call setup phase that will use H.323 QOS > messages (as shown in Appendix of H.323 QOS) will meet the QOS > requirements. > I do not think that we should "INVENT" any new security mechanisms ONLY > specific to H.323 QOS. Security should be dealt for H.323 in general. This > work MUST be de-coupled from H.323 QOS. > > > Let's continue the debate on this lists - this is the best way of arriving > at an agreed approach. Documenting it once we have agreement on what the > problem is and how we are going to solve it should be quite > straightforward. > I hope we will have something to determine in November. > [RRR] Yes, this has been the main purpose of my email. Moreover, emails go > to all people throughout the whole world. Each one of us can participate. > This is the MOST convenient way for resolving issues. I appreciate your > response. > > Mike > > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Friday, August 11, 2000 5:09 PM > Subject: Re: H.323 QOS > > > Hi, Mike: > > Please note the following: > > Table 1 shows all parameters that are observed in digitization form. > (There > may be similarity with some transport level parameters, but these are > expressed in a transport independent way.) > > A given codec/data (appln.) may or may have all the parameters. If not, > those parameters will be NOT be used. > > Each parameter contain: Yes/No and Value. > > So, the first problem is to express performance/QOS parameters that do NOT > contain any values. That is, it will have only the parameters without any > value. For example, all audio/video codecs will have their parameters > expressed that will have only a limited set (in the previous case as can > be > seen in Appendix of Annex N - there has been only 4 sets, etc.). These are > universal sets and does not matter what the codec type is. > > In H.323, we are NOT defining values of the parameters because values are > subjective and implementation dependent. The values of any given QOS > parameter or a set of QOS parameters are beyond the scope of H.323 > (Q.13/16). The values are being defined in other SGs or organizations > (e.g., > TIPHON, IMTC, etc.). > > You are right that the values for each codec will be different. People may > define many classes based on values as well. For example, 100ms delay is > gold service, 150ms delay is silver service, etc. In Annex N, we will not > be > addressing those values. > > The same is also true for data. > > Defining of QOS values of any given parameters is OUT of scope of H.323. > > It appears that there is a mis-understanding. I do not any intention for > any > personal attack other than to complete the work on time (if it appears so, > I > apologize for this). > > Hope this clarifies your questions. > > Best regards, > Radhika R. Roy > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Friday, August 11, 2000 11:08 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > > Radhika, > > >The basic problem is to express the end-to-end H.323 QOS parameters of > each > >medium (audio, video, data) that are applicable no matter what the > >underlying transport network (or networks) is. > > >The answer of this problem is Table 1 that I have provided. > > We agree on the first paragraph. The problem I have with your Table 1 > relates to media statistics (see my earlier comments). Incidentally the > columns are the properties of transport media streams. the values will > be > dependent on media type, codec, packetisation etc. So I am not sure what > the relevance of codec or T.120 is in the heading. The parameters in each > column are what I regard as the generic bearer descriptor. > > >Now we have to group those parameters in different combinations for each > >medium that makes sense from the enduser point of view to satisfy their > >requirements. > > >This is the simple problem. > > The values follow from the users QoS service request, and the choices made > by the application in achieving this (codec type, packetisation, jitter > buffer design). Once the application has figured out what these > parameters > are then the entries in your table can be computed by the application and > flagged to the transport operator on a domain by domain basis or > end-to-end > if there is one homogeneous transport space. > > >A by-product of this solution needs to satisfy RSVP and ATM QOS as > >H.323v2/v3/v4 spec is doing today. > > I see no conflict with the use of these transport mechanisms in the > transport plane. You seem terribly worried about this. What is the > problem? > > >I am surprised to see that you are still saying that your are NOT > familiar > >with H.323. If it is so, we have problems. An editor needs to be on the > top > >of everything because the last editor did a good amount of job in a very > >short period of time addressing all issues. We are now going backward and > >losing our valuable time just because the editor is NOT familiar with > H.323. > >If you ask questions, I would be happy to answer as much as I can. > > You are putting words into my mouth here that I never used. Why the > personal attack? I thought the discussion had been quite constructive up > to this point. > > Mike > > > > > > > > > > > > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Friday, August 11, 2000 2:41 PM > Subject: Re: H.323 QOS > > > Hi, Mike: > > The basic problem is to express the end-to-end H.323 QOS parameters of > each > medium (audio, video, data) that are applicable no matter what the > underlying transport network (or networks) is. > > The answer of this problem is Table 1 that I have provided. > > Now we have to group those parameters in different combinations for each > medium that makes sense from the enduser point of view to satisfy their > requirements. > > This is the simple problem. > > A by-product of this solution needs to satisfy RSVP and ATM QOS as > H.323v2/v3/v4 spec is doing today. > > I am surprised to see that you are still saying that your are NOT familiar > with H.323. If it is so, we have problems. An editor needs to be on the > top > of everything because the last editor did a good amount of job in a very > short period of time addressing all issues. We are now going backward and > losing our valuable time just because the editor is NOT familiar with > H.323. > If you ask questions, I would be happy to answer as much as I can. > > I like to see other members also provide comments on this. > > Best regards, > Radhika > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Friday, August 11, 2000 9:01 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > > Radhika, > > I think we are in total agreement until your last two paragraphs. Lets > figure out what problem we are solving and what we need to do to achieve > this, then examine the issues of backward compatibility. > > You are a lot more familiar than I am with the existing H.323 mechansims. > Why are these not transport mechansm independent as per your model? > > Mike > > > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Friday, August 11, 2000 12:58 PM > Subject: Re: H.323 QOS > > > Hi, Mike: > > Let me try again. > > What is the reference point of H.323 QOS? Is it not H.323? If it is so, > what > do we mean by H.323? > > The answer is: Audio (different codecs), Video (different codecs), and > Data > (T.120 applications) that are used by H.323. > > What are the QOS/performance characteristics of audio, video, and data > from > the application point of view that is generated by audio codecs, video > codecs, and data (T.120) applications? > > These QOS/performance characteristics come from the SOURCE codecs and data > applications. Per transport independent H.323 specifications, an enduser > express their QOS/performance requirements on end-to-end basis purely from > application point of view irrespective of the transport network (e.g., IP, > ATM, etc.). > > Moreover, H.323 is meant for the packet network, not for any > circuit-switched network like PSTN or ISDN. > > Let us NOT go beyond this before we start debating transport layer QOS or > service provider requirements. These are NOT the concern of H.323. H.323 > is > the transport independent application. > > H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be > used > for H.323 audio, video, and data. So, H.323 QOS that will be defined in > H.323 Annex N MUST provide mapping for the backward compatibility. It is a > requirement that MUST be met per the norm of ITU-T. > > So, what is left for mapping? Mapping is simply a by-product of the above > requirement. Mapping is simply a table, nothing else. > > Did I miss anything? > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Thursday, August 10, 2000 10:19 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > > Radhika, > > Thanks for the input which I welcome as I will unfortunately not be > present > at Portland. > > Let me ask a few questions and make a few comments hopefully with the > intent > of opening up the debate. > > 1. I am not sure I understand your concept of a mapping table between the > H.323 QOS and the transport layer QoS. My understanding is that QoS is on > three levels: > > a) that specified from a service point of view between the user and > service > provider (e.g PSTN quality, conference quality etc) This is the domain of > the speech experts and can be characterised by Listener Speech Quaklity > (MOS), end to end delay, and absolute category rating, R. > > b) application specific parameters, (e.g. equipment delays, codec choice > and performance, codec frame size, packetisation arrangements, jitter > buffer > design, overall packet loss etc.) Optimisation of all these will > determine > what can be delivered in a). > > c) transport parameters for a given choice of application parameters. > This > boils down only to three parameters as far as I cna see: tranport network > delay, packet delay variation in the transport network and packet loss in > the transport network. Again these parameters will determine the results > in > a) for a given choice of the parameters in b). These parameters are > generic > from the perspective of the transport network. i.e the transport network > does not need to know the details of the application. > > So the sequence of cause and effect and control is: > > a) User requests QoS class from service provider, > b) Service provider determines application specific parameters in > conjunction with users equipment and other service providers, > c) Service provider requests required delay, delay variation and packet > loss from network provider. > > I see no need for mapping here. The only QoS info flows within the > application are specific to the application and those between the > application (service provider) and the transport network are generic. i.e. > delay, jitter and packet loss. Have I missed something? > > 2. The issue of bit rate and media stream statistics I think need to be > decoupled from QoS. These are specified to enable optimisation of > resources > within the transport network. They have no QoS significance from an > application point of view. i.e the apllication does not care about the > media stream bit rate and statistics but the transport network provider > does > as it eats up his resource. They may be used for policy enforcement > however > in the transport network so they do need to be agreed between service > provider and network operator. i.e the network operator agrees to provide > a > given QoS level (delay, jitter, packet loss) provided the media properties > are within an agreed profile (bit rate, flow statistics). > > 3. The next point is how can the service provider know the statistics of > a > particular VBR stream? These can only be specified over a large number of > similar calls and will depend, for instance, on who is speaking, the > nature > of the speech interaction etc etc. They can only be measured not > calculated. The service provider is in no better position to measure > these > than the transport network operator and, in fact, where no gateways are > involved, may not be able to. On the other hand the class of signal would > have to be signalled to the network operator for him to be able to > distinguish which class a particular measurement belonged to. e.g > voice/speech/data, codec type, conference, multicast etc. So I see no > purpose in trying to exchange statistics between the service provider > (application) and transport operator. I think peak bit rate is all that > can > be meaningfully excanged. The specification of media class is however > perhaps worth exploring. > > 4. The controlled category has always puzzled me. I only see two > possibilities. Either the requested QoS level is guaranteed (on a > statistical basis e.g 95% of all connections over a specified period) or > not > guaranteed. Is your controlled category a way of saying guaranteed, not > to > 95% but to some lower figure? If you can't put a percentage on it then it > seems it is plain and simple not guaranteed. Anything that is not > guaranteed to some specified statistical level is best effort and you > can't > say anything more about it. So I only see two categories here. > > In summary, I think we need to do three things in Annex N. > > a) Figure out the QoS information to be exchanged within the Application > between service providers and end users. This will go in H.225.0 and > H.245. > > b) Figure out how we are going to signal QoS and media information between > the application (service providers) and transport domains (IP or ATM > networks etc). The info is basically delay, jitter, packet loss > requirements and peak bit rate. We need a protocol for this. > > c) we need to work out the interactions between the application QoS > signal > flows and the application/transport signal flows. I don't think we need > worry about how the transport network mechanisms assure the requested QoS > paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all > possibilities. > > Would welcome comments and views on the above. > > Mike > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Thursday, August 10, 2000 10:15 PM > Subject: H.323 QOS > > > Hi, Mike and All: > > It is time to discuss about H.323 QOS. > > I believe that we have an agreement as follows: > > · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it > exists for H.323v2/v3/v4 > · Like H.323 spec, the application level H.323 QOS MUST be independent of > the transport layer QOS and should support all transport networks (e.g., > IP, > ATM) > · A mapping table between the H.323 QOS and the transport layer QOS (e.g., > IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.]) > should be provided. > > From the H.323 multimedia application point of view, there are following > performance parameters can be used to characterize the traffic > characteristics: > > · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR), > Sustained > bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum > rate > (MR), and mean bust size (MBS) > · Delay and loss characteristics: end-to-end delay (EED) or delay, > end-to-end delay variation (EEDV) or delay variation (DV), and > bit-error-rate (BER) or (packet) loss rate (LR) > > We can now form a table with all parameters as follows: > > Table 1: H.323 Multimedia Application Performance Matrix > Audio (codecs)--- Video (codecs)--- Data > (T.120) > PBR/PR Yes/No/Value Yes/No/Value Yes/No/value > SBR/AR Yes/No/Value Yes/No/Value Yes/No/value > MBR/MR Yes/No/Value Yes/No/Value Yes/No/value > MBS Yes/No/Value Yes/No/Value Yes/No/value > EED/Delay Yes/No/Value Yes/No/Value Yes/No/value > EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value > BER/LR Yes/No/Value Yes/No/Value Yes/No/value > > From the above table we will have the opportunity to choose each parameter > for each medium (audio, video, data) that makes sense from the > application's > and enduser's point of view. Again, these parameters can be specified as > follows: > > · Guaranteed: The value specified for each parameter MUST be guaranteed. > · Controlled: The value specified for each parameter MAY be satisfied as > far > as practicable (possibly with certain range), but definitely NOT > guaranteed. > · Best effort: No commitment will be made. > > Now each medium (e.g., audio, video, or data) will have different > categories > of performance matrix depending on its selection criteria and this can > also > be mapped to RSVP, ATM QOS, and others, if needed. > > Once we agree on this format, the next step is to create H.323 QOS > signaling > messages. > > This is my input for discussion in the upcoming Portland Q.13 meeting for > H.323 QOS. > > I like to see the comments from other members as well. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 14 Aug '00

14 Aug '00

Hi, Mike and Bob: Please see my reply [[RRR]]. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Monday, August 14, 2000 1:08 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Bob, >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. [Mike] I can't see why H.245 is involved in specifying or signalling the transport QoS mechanism. This is entirely an issue for the transport network operator. H.245 is end to end, transport QoS mechanisms generally are not. [[RRR]] Please note that each end is connected to a transport network. However, H.245 goes to end-to-end among H.323 entities although the transport network will do its own translation of QOS in the network layer. Please see how present H.245 signaling supports RSVP and ATM QOS. 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 3:16 PM 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. 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. 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. 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

1 0

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

14 Aug '00

Hi, All: We have two parts of H.323 QOS: 1. Pre-call setup phase 2. Call setup phase (where H.245 comes in) We have done item 1 only so far in H.323 QOS Annex N. One of the suggestions has been to limit the scope of Annex N in two phases (AT&T contribution APC-1765): Phase 1: Item 1 (Pre-call setup phase) Phase 2: Item 2 (Call setup phase) Now H.323 supports RSVP and ATM QOS. If there are problems in certain areas, we like to see how these can be fixed. Contributions will help us how we can go from there to improve this. The bottom line is this: We need to work on H.323 Annex N to support QOS. All suggestion to fix the problems are welcome. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Sent: Monday, August 14, 2000 2:37 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS I would strongly agree with Mike on this point. We have a little bit of QoS negotiation in H.245, and it is an unfortuate mistake that we did so. When you dig a little bit into it, it is pretty obvious that they don't make much sense. The ATM parameters still have and editor's note in the actual ASN.1 saying that they are supposed to be changed to match ITU terminology. That tells me that not many implementations use this. The RSVP parameters in the ASN.1 basically don't make any sense. Also, our description of RSVP is really outdated and tied with RSVP/Intserv and doesn't talk about RSVP/Diffserv. Let's not do even more damage... -----Original Message----- From: Mike Buckley [ mailto:mikebuckley@44COMMS.COM <mailto:mikebuckley@44COMMS.COM> ] Sent: Monday, August 14, 2000 10:22 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, I agree with everything you say except: >The beauty of H.245 is that >it provides a negotiation capability on end-to-end basis and the same can >also used for QOS (in fact, it is also used to day for RSVP, and ATM QOS in >a monolithic network). I maintain that H.245 should not be concerning itself with transport domain issues. All these mechanisms listed are transport domain matters and should be hidden from the application. In fact they will in general be hidden from the application. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(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 4:29 PM Subject: Re: H.323 QOS Hi, Bob: I have provide my reply embedded in your email [RRR]. In addition, I am providing some general explanation. The fundamental problem is that the network layer QOS signaling schemes are different because these are transport dependent. In olden days, we have also made application specific to the particular transport mechanism. For example, H.320, H.321, etc. However, the application like H.323 has changed the landscape. It is transport independent although it can be sent over any transport network specific to meets its specific needs. For example, we change the abstraction of network address into IP, ATM, etc. as needed. So, this simple example shows how H.323 is transported in a specific network while the "network address" is the universal abstraction for both IP and ATM. If people want to solve having the service level agreement in a specific way without using any standards, it is their choice. In fact, many service providers are doing this in a proprietary manner toady. There is no common standard to express the QOS in a universal way that remains the same on end-to-end basis and there are so many translations in the network layer without having a common reference. As I explained above, if we want to make H.323 IP specific, we could do this as well. In this case, we do NOT need to make it transport independent. But the question is: Why did we make H.323 transport independent? We have discussed this a lot in the past while we have been developing Annex H.323 N, and have come to the same conclusion that we do need to make H.323 QOS transport independent so that it can be implemented for any network or a combination of networks or a combination of network layer QOS. It also bridges the fundamental gap that the application (audio codecs, video codecs, data) has its own intrinsic needs to express its QOS because it is the application whose needs to be satisfied no matter what the underlying transport network or networks may be. The beauty of H.245 is that it provides a negotiation capability on end-to-end basis and the same can also used for QOS (in fact, it is also used to day for RSVP, and ATM QOS in a monolithic network). The beauty of H.323 QOS Annex N is that it helps to implement all heterogeneous network layer QOS (RSVP, DiffServ, MPLS, ATM QOS, etc) in any combination that people may like to implement. Hope this will clarify your points further. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [ mailto:Robert.Callaghan@ICN.SIEMENS.COM <mailto:Robert.Callaghan@ICN.SIEMENS.COM> ] Sent: Monday, August 14, 2000 10:17 AM To: ITU-SG16(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 <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 <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 <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

1 0

APC-1893 uploaded
by Patrick Luthi 14 Aug '00

14 Aug '00

Dear experts, The following contribution has been uploaded to the AVC-site/incoming. Title: Proposed H.242/H.245 text for dynamicPictureResizingByFour Source: PictureTel (Q. Gu/P. Luthi) Questions: 11 (Q11-M-03), 14 (APC-1893), and 15 (Q15-K-14) See you in Portland ! Regards, Patrick Luthi PictureTel Corp. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 14 Aug '00

14 Aug '00

Hi, Bob: I guess that we are in agreement, but did you have the chance to read Appendix of H.323 QOS Annex N? You will be surprised to see that your requirements are also satisfied. All people have agreed to work on H.323 QOS Annex N and we need you to point out where we can do something that you see that we are not addressing in this Annex. We have got one editor for this, and he is dedicated for this work. We are debating how we can further refine our approaches. And we want your suggestion how we can improve if anything is missing. I appreciate your response to clarify the points further. Please also see my reply embedded in your email [RRR]. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@icn.siemens.com] Sent: Monday, August 14, 2000 2:16 PM To: Roy, Radhika R, ALCOO Cc: 'Mailing list for parties associated with ITU-T Study Group 16' 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. [RRR] H.323 is sending media, and ,for each media, it has different QOS characteristics. So, the mechanism is already there to differentiate the requirements for each media type if one needs to use it. Now according to your needs, I think that the requirement is very simple. All you want is that we need to aggregate bandwidth for all media together. It is a choice and you can do that if you like to do it in H.323 QOS Annex N. Please read the annex very carefully and you will see how your requirements will be satisfied. However, this annex goes more than this. If I want to differentiate QOS for each medium, I can also do this in Annex N. Please remember that you can NOT expect that the "plain vanilla" aggregate bandwidth will also satisfy my requirements. Furthermore, present H.323/H.245 spec allows me to differentiate QOS for each medium using RSVP and ATM QOS. So, the mechanism already exists today in H.323/H.245. So, what is your point here? 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). [RRR] If you agree with your first statement, please see my reply on item 1. So, my reply in item 1 answers your concern in item 2. If you want to make it "plain vanilla" transport data, it is your choice. No one will force you to differentiate it for each medium if you think that it is your best interest. 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. [RRR] We do not address routing of data at the H.323 level. How a service provider will route H.323 streams is a separate issue. If you like, we can work on this routing issue as a separate Question either in the SG16 or in any other SGs. 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. [RRR] We cannot go too far. Our reference is H.323 application and it has different audio and video codecs and data (T.120). We are concerned how we can meet their requirements first. We are so not sure whether we can it beyond H.323 application because QOS signaling schemes have to satisfy H.323/H.225.0/H.245 protocol requirements as well. 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.) [RRR] Please see my reply for item 4. We are addressing the H.323 application only because the signaling mechanism is very specific to H.323/H.225.0/H.245 protocol. Maybe there is a balance between your method of specifying in detail the desired QoS and the fact that it is H.323 specific. [RRR] Please see my reply provided above. A lot of people have been working on H.323 QOS over two years and I am one of them. We are fortunate that we have got one full time editor on this and Mike comes from TIPHON where he has been leading a complete QOS WG. So, it is not only of my way of specifying the things, but the general guideline has also been supported by many. We are now debating how we can refine the approach. It is a healthy debate so that we can find the best solution based on common experiences that we can ever think of. 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

1 0

Re: H.323 QOS
by Francois Audet 14 Aug '00

14 Aug '00

I would strongly agree with Mike on this point. We have a little bit of QoS negotiation in H.245, and it is an unfortuate mistake that we did so. When you dig a little bit into it, it is pretty obvious that they don't make much sense. The ATM parameters still have and editor's note in the actual ASN.1 saying that they are supposed to be changed to match ITU terminology. That tells me that not many implementations use this. The RSVP parameters in the ASN.1 basically don't make any sense. Also, our description of RSVP is really outdated and tied with RSVP/Intserv and doesn't talk about RSVP/Diffserv. Let's not do even more damage... -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Monday, August 14, 2000 10:22 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, I agree with everything you say except: >The beauty of H.245 is that >it provides a negotiation capability on end-to-end basis and the same can >also used for QOS (in fact, it is also used to day for RSVP, and ATM QOS in >a monolithic network). I maintain that H.245 should not be concerning itself with transport domain issues. All these mechanisms listed are transport domain matters and should be hidden from the application. In fact they will in general be hidden from the application. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(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 4:29 PM Subject: Re: H.323 QOS Hi, Bob: I have provide my reply embedded in your email [RRR]. In addition, I am providing some general explanation. The fundamental problem is that the network layer QOS signaling schemes are different because these are transport dependent. In olden days, we have also made application specific to the particular transport mechanism. For example, H.320, H.321, etc. However, the application like H.323 has changed the landscape. It is transport independent although it can be sent over any transport network specific to meets its specific needs. For example, we change the abstraction of network address into IP, ATM, etc. as needed. So, this simple example shows how H.323 is transported in a specific network while the "network address" is the universal abstraction for both IP and ATM. If people want to solve having the service level agreement in a specific way without using any standards, it is their choice. In fact, many service providers are doing this in a proprietary manner toady. There is no common standard to express the QOS in a universal way that remains the same on end-to-end basis and there are so many translations in the network layer without having a common reference. As I explained above, if we want to make H.323 IP specific, we could do this as well. In this case, we do NOT need to make it transport independent. But the question is: Why did we make H.323 transport independent? We have discussed this a lot in the past while we have been developing Annex H.323 N, and have come to the same conclusion that we do need to make H.323 QOS transport independent so that it can be implemented for any network or a combination of networks or a combination of network layer QOS. It also bridges the fundamental gap that the application (audio codecs, video codecs, data) has its own intrinsic needs to express its QOS because it is the application whose needs to be satisfied no matter what the underlying transport network or networks may be. The beauty of H.245 is that it provides a negotiation capability on end-to-end basis and the same can also used for QOS (in fact, it is also used to day for RSVP, and ATM QOS in a monolithic network). The beauty of H.323 QOS Annex N is that it helps to implement all heterogeneous network layer QOS (RSVP, DiffServ, MPLS, ATM QOS, etc) in any combination that people may like to implement. Hope this will clarify your points further. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] 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

1 0

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

14 Aug '00

Hi, Mike: Please see my response [RRR]. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Monday, August 14, 2000 1:22 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, I agree with everything you say except: >The beauty of H.245 is that >it provides a negotiation capability on end-to-end basis and the same can >also used for QOS (in fact, it is also used to day for RSVP, and ATM QOS in >a monolithic network). I maintain that H.245 should not be concerning itself with transport domain issues. All these mechanisms listed are transport domain matters and should be hidden from the application. In fact they will in general be hidden from the application. [RRR] I am NOT inventing anything NEW. This mechanism is what exists in H.323/H.245 today no matter what people may call it. [By the way, H.323/H.245 does not define anything like transport domain, etc. although it is working in a way what I have explained.] 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 4:29 PM Subject: Re: H.323 QOS Hi, Bob: I have provide my reply embedded in your email [RRR]. In addition, I am providing some general explanation. The fundamental problem is that the network layer QOS signaling schemes are different because these are transport dependent. In olden days, we have also made application specific to the particular transport mechanism. For example, H.320, H.321, etc. However, the application like H.323 has changed the landscape. It is transport independent although it can be sent over any transport network specific to meets its specific needs. For example, we change the abstraction of network address into IP, ATM, etc. as needed. So, this simple example shows how H.323 is transported in a specific network while the "network address" is the universal abstraction for both IP and ATM. If people want to solve having the service level agreement in a specific way without using any standards, it is their choice. In fact, many service providers are doing this in a proprietary manner toady. There is no common standard to express the QOS in a universal way that remains the same on end-to-end basis and there are so many translations in the network layer without having a common reference. As I explained above, if we want to make H.323 IP specific, we could do this as well. In this case, we do NOT need to make it transport independent. But the question is: Why did we make H.323 transport independent? We have discussed this a lot in the past while we have been developing Annex H.323 N, and have come to the same conclusion that we do need to make H.323 QOS transport independent so that it can be implemented for any network or a combination of networks or a combination of network layer QOS. It also bridges the fundamental gap that the application (audio codecs, video codecs, data) has its own intrinsic needs to express its QOS because it is the application whose needs to be satisfied no matter what the underlying transport network or networks may be. The beauty of H.245 is that it provides a negotiation capability on end-to-end basis and the same can also used for QOS (in fact, it is also used to day for RSVP, and ATM QOS in a monolithic network). The beauty of H.323 QOS Annex N is that it helps to implement all heterogeneous network layer QOS (RSVP, DiffServ, MPLS, ATM QOS, etc) in any combination that people may like to implement. Hope this will clarify your points further. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] 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

1 0

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

14 Aug '00

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

2 1

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

14 Aug '00

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. 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. 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. 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

2 1

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

14 Aug '00

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

2 1

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

14 Aug '00

Hi, Mike: Please see my reply embedded in you email [Roy, Radhika R.]. My general comment is that H.323 QOS is the application layer because H.323 is an application. Any transport network can use H.323 to implement its abstraction over its specific transport mechanisms. For example, a network address can be translated into an IP or ATM address. Or, open logical channel (OLC) can be translated into ATM or other network layer connection. This is called the abstraction in the H.323 application layer in a transport independent way. So, appendix of H.323 Annex N does the same for the application layer OQS on an end-to-end basis. Let us take the simple view so that we can address the H.323 QOS on end-to-end basis where there is no network related issues, because the network layer is transparent to the H.323 application layer. The application H.323 QOS is only deals with the application like audio codecs, video codecs, and data application. They have their intrinsic QOS needs at the application layer from endusers' point of view. Let us not jump into NAT, service providers, ISPs and other issues. Let us assume that nothing like this exist and see how we can address the simple problem. NATs, ISPs, etc are the implementation issues and forums like IMTC, TIPHON, and others may be the right place where those issues can be addressed. I would appreciate if you would bring contributions against the exiting appendix of H.323 Annex N explaining where you are disagreeing with and why, and what you like see to be there keeping the existing framework of H.323 QOS intact where one can implement RSVP and ATM QOS in the network layer if needed with the help of H.245. Best regards, Radhika R. Roy AT&T > -----Original Message----- > From: Mike Buckley [SMTP:mikebuckley@44COMMS.COM] > Sent: Sunday, August 13, 2000 10:48 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > Hi Radhika, > > See comments below. > > Mike > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(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:48 AM > Subject: Re: H.323 QOS > > > >Hi, Mike: > > >Further to my earlier (enclosed) email, I like to mention that H.323 QOS > is > >also addressing problems where a single network may have different kinds > of > >network layer QOS signaling schemes. For example, an IP network may have > >different domains where one domain implements RSVP, the other domain > >implements DiffServ, and the another domain implements MPLS, etc. > > I agree. A single network (one ownership/administration) can have several > domains. This is a particular case of the general case where the call > passes through many domains with different policies, QoS mechanisms and > different ownerships also possibly NATs between domains. I believe this > is > the situation for which we have to provide an end to end QoS solution. [Roy, Radhika R] Again, let us address the first one - H.323 QOS end-to-end independent of the network layer. NATs and domains, etc. are implementation issues. Other forums like TIPHON, IMTC, etc are bettwe place to address the implementation related issue. > >H.323 QOS will provide the end-to-end "application" layer QOS signaling > >mechanism that is universal from end users' point of view no matter > whether > >there are multiple networks (e.g., IP, ATM), or whether one network that > >implements heterogeneous "network" layer QOS (e.g., RSVP, DiffServ, MPLS, > >etc.) schemes. > > Totally agree. > > >By the way, the Appendix of H.323 Annex N has almost all the answers. I > >strongly believe, as explained in the earlier email per your questions > >(enclosed), that we have all the solution ready to use. If you have any > >questions, please also ask me, the past editor Rich Bowen, or others who > >have been working bringing contributions related to H.323 QOS problems. > > I still have not understood why you are signalling transport QoS mechanism > in H.323 (the application)? Particularly when you agree the application > has > to be transport mechanism independent. This seems to be the main area we > disagree on. [Roy, Radhika R] Please see my general comments stated above. Please also see the existing Appendix of H.323 Annex N. Many comapnies along with AT&T brought many contributions over the last two years. Accordingly, Appendix of H.323 Annex N has been created. This mechansim already exist in H.323 QOS where RSVP and ATM QOS are supported when the QOS mechanism is supported either for the single IP or for the ATM network individually with the help of H.245. There is nothing to disgree with, it is alread there in H.323 standard. Appendix of H.323 Annex N has extended it over multiple networks or any other combinations that may exist in the lower trnasport network making the H.323 mechanism indpendent of the transport layer. I like to see that you bring contributions what you like to see happen explaining your thoughts. > Regards, > > Mike > > >Best regards, > >Radhika R. Roy > >AT&T > > -----Original Message----- > From: Roy, Radhika R, ALCOO > Sent: Friday, August 11, 2000 2:47 PM > To: 'Mailing list for parties associated with ITU-T Study Group 16' > Subject: RE: H.323 QOS > > > Hi, Mike: > > Please see my response stated below [RRR]. > > Best regards, > Radhika > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Friday, August 11, 2000 1:24 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > > Radhika, > > Sorry , I am not following your arguments here. I thought your Table 1 > was > a description of the QoS requirements and media stream properties that > would > be signalled by the application/service provider to the network operator. > This is transport QoS mechansm independent. > [RRR] Certainly it is NOT the case. It is H.323, and nothing to do with > service providers or network operators. H.323 spec only deals with the > application on end-to-end basis. > > I maintain that the media statistic parameters can not in general be > signalled on a per media stream basis. Only peak bit rate has any meaning > to the application and derives from the choice of codec and packetisation > arrangements. > [RRR] It is NOT true. Please see H.245 spec how each medium is signaled > along with QOS parameters (e.g., RSVP, ATM QOS). It already exits in > H.323/H.245 on end-to-end basis if there is only one kind of network. We > are > just extending the same concept on end-to-end basis if there is one or > multiple networks. If there is only one network either IP or ATM, H.323 > QOS > does NOT need any additional work per se. For IP network, H.323 provides > the > support of RSVP and more work may be needed if DiffServ or MPLS needs to > be > supported. For ATM QOS, H.323 QOS spec is also complete. But if there are > combinations of IP and ATM (and/or other networks), there is no end-to-end > H.323 QOS signaling mechanism that can be used as an universal set across > all networks. In fact, as I told before, we are SOLVING this problem in > H..323 Annex N. > > In agree the values in the Table do not need to be specified in the > protocol. I am happy with YES/NO/Value with Value being optional in the > case of YES. > [RRR] I am glad to hear that we are in agreement here. > > >So, the first problem is to express performance/QOS parameters that do > NOT > >contain any values. That is, it will have only the parameters without any > >value. For example, all audio/video codecs will have their parameters > >expressed that will have only a limited set (in the previous case as can > be > >seen in Appendix of Annex N - there has been only 4 sets, etc.). These > are > >universal sets and does not matter what the codec type is. > > You have lost me here. What is the point signalling empty sets? > [RRR] Please see the Appendix of H.323 Annex N how the QOS classes and the > corresponding signaling messages have been created, and how the signaling > will be done. There are two stages of H.313 QOS signaling: 1. Pre-call > setup > phase and 2. Call setup phase. In pre-call setup, it is the empty > signaling > messages sets that will be sent to determine whether these kind of QOS > classes are supported on end-to-end basis. It is called the discovery > phase. > So far, it has been the ONLY goal for H.323 QOS. > > [RRR] For the call setup phase, the actual values of all those parameters > are needed. We expect that the values can be chosen by endusers if there > are > no standards. However, if other SGs or forums (e.g., TIPHON, IMTC, SLA > agreements, etc.) define those values, people can also use those specific > values. Then the H.323 QOS signaling messages can use those implementation > specific values. H.323 QOS will only have the place holder for those > values. > > The order > of events must surely be: [RRR] the order of events are shown in Appendix > of > H.323 Annex N. > > a) User requests QoS level of service provider: gold, silver etc. > [RRR] Again, this is implementation specific and SG16 is not the right > place > to define gold, silver, etc. for H.323. > > b) Application uses H.225.0 and H.245 to establish compatible codecs and > packetisation arrangements consistent with a), > [RRR] H.245 is currently using RSVP and ATM QOS and we will use the > similar > approach. No new work is needed here. > > c) Application computes delay, delay variation and bit error rate > required > of transport network and signalls these to transport network operator. > [RRR] We do not need to do anything NEW other than the similar thing what > H.245 is doing currently for RSVP and ATM QOS. > > H.225.0 and h.245 will be used to: > > a) register a terminal's QoS characteristics with the service provider > (gatekeeper). > [RRR] H.323 does not define anything related to service providers, > application providers, or network providers. It is implementation > specific. > It will only deal with the H.323 QOS signaling messages on end-to-end > basis > as it has been dong for RSVP and ATM QOS. Let other SGs or forums do some > implementation specific agreement/standard for H.323 QOS. > > b) for user to request gold, silver or bronze or the end to end QoS > parameters from a service provider (gatekeeper), > [RRR] Again, it is an implementation issue, not a H.323 QOS protocol > issue: > gold, silver, etc. My response for item a is applicable. > > c) for service providers (gatekeepers) to signal QoS parameters to each > other to enable end to end QoS levels to be achieved. > [RRR] Again a GK can signal QOS parameters, but H.323 does not recognize > service providers, applications providers, or network providers. However, > the GK will signal using the H.323 QOS messages. The QOS signaling > messages > will contain many parameters (I do not think that it will contain QOS > level > per se). > > d) to establish compatible codecs and packetisation at both ends of a > media > stream. > [RRR] H.245 has well established negotiation capabilities. We do not need > to > do any additional work here. > > Registration will take place prior to call set up. The rest of the QoS > information flows must take place at call set up. > [RRR] Please see my answers provided above. Currently, Appendix of H.323 > Annex N has it completed how the pre-call setup signaling messages can be > exchanged. The call setup phase will use the same mechanism as it exists > today for RSVP and ATM QOS. We will only augment this using NEW parameters > of H.323 QOS. > > We need a new protocol for signalling QoS requirements and authorisations > to > the network operator. > [RRR] The pre-call setup and call setup phase that will use H.323 QOS > messages (as shown in Appendix of H.323 QOS) will meet the QOS > requirements. > I do not think that we should "INVENT" any new security mechanisms ONLY > specific to H.323 QOS. Security should be dealt for H.323 in general. This > work MUST be de-coupled from H.323 QOS. > > > Let's continue the debate on this lists - this is the best way of arriving > at an agreed approach. Documenting it once we have agreement on what the > problem is and how we are going to solve it should be quite > straightforward. > I hope we will have something to determine in November. > [RRR] Yes, this has been the main purpose of my email. Moreover, emails go > to all people throughout the whole world. Each one of us can participate. > This is the MOST convenient way for resolving issues. I appreciate your > response. > > Mike > > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Friday, August 11, 2000 5:09 PM > Subject: Re: H.323 QOS > > > Hi, Mike: > > Please note the following: > > Table 1 shows all parameters that are observed in digitization form. > (There > may be similarity with some transport level parameters, but these are > expressed in a transport independent way.) > > A given codec/data (appln.) may or may have all the parameters. If not, > those parameters will be NOT be used. > > Each parameter contain: Yes/No and Value. > > So, the first problem is to express performance/QOS parameters that do NOT > contain any values. That is, it will have only the parameters without any > value. For example, all audio/video codecs will have their parameters > expressed that will have only a limited set (in the previous case as can > be > seen in Appendix of Annex N - there has been only 4 sets, etc.). These are > universal sets and does not matter what the codec type is. > > In H.323, we are NOT defining values of the parameters because values are > subjective and implementation dependent. The values of any given QOS > parameter or a set of QOS parameters are beyond the scope of H.323 > (Q.13/16). The values are being defined in other SGs or organizations > (e.g., > TIPHON, IMTC, etc.). > > You are right that the values for each codec will be different. People may > define many classes based on values as well. For example, 100ms delay is > gold service, 150ms delay is silver service, etc. In Annex N, we will not > be > addressing those values. > > The same is also true for data. > > Defining of QOS values of any given parameters is OUT of scope of H.323. > > It appears that there is a mis-understanding. I do not any intention for > any > personal attack other than to complete the work on time (if it appears so, > I > apologize for this). > > Hope this clarifies your questions. > > Best regards, > Radhika R. Roy > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Friday, August 11, 2000 11:08 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > > Radhika, > > >The basic problem is to express the end-to-end H.323 QOS parameters of > each > >medium (audio, video, data) that are applicable no matter what the > >underlying transport network (or networks) is. > > >The answer of this problem is Table 1 that I have provided. > > We agree on the first paragraph. The problem I have with your Table 1 > relates to media statistics (see my earlier comments). Incidentally the > columns are the properties of transport media streams. the values will > be > dependent on media type, codec, packetisation etc. So I am not sure what > the relevance of codec or T.120 is in the heading. The parameters in each > column are what I regard as the generic bearer descriptor. > > >Now we have to group those parameters in different combinations for each > >medium that makes sense from the enduser point of view to satisfy their > >requirements. > > >This is the simple problem. > > The values follow from the users QoS service request, and the choices made > by the application in achieving this (codec type, packetisation, jitter > buffer design). Once the application has figured out what these > parameters > are then the entries in your table can be computed by the application and > flagged to the transport operator on a domain by domain basis or > end-to-end > if there is one homogeneous transport space. > > >A by-product of this solution needs to satisfy RSVP and ATM QOS as > >H.323v2/v3/v4 spec is doing today. > > I see no conflict with the use of these transport mechanisms in the > transport plane. You seem terribly worried about this. What is the > problem? > > >I am surprised to see that you are still saying that your are NOT > familiar > >with H.323. If it is so, we have problems. An editor needs to be on the > top > >of everything because the last editor did a good amount of job in a very > >short period of time addressing all issues. We are now going backward and > >losing our valuable time just because the editor is NOT familiar with > H.323. > >If you ask questions, I would be happy to answer as much as I can. > > You are putting words into my mouth here that I never used. Why the > personal attack? I thought the discussion had been quite constructive up > to this point. > > Mike > > > > > > > > > > > > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Friday, August 11, 2000 2:41 PM > Subject: Re: H.323 QOS > > > Hi, Mike: > > The basic problem is to express the end-to-end H.323 QOS parameters of > each > medium (audio, video, data) that are applicable no matter what the > underlying transport network (or networks) is. > > The answer of this problem is Table 1 that I have provided. > > Now we have to group those parameters in different combinations for each > medium that makes sense from the enduser point of view to satisfy their > requirements. > > This is the simple problem. > > A by-product of this solution needs to satisfy RSVP and ATM QOS as > H.323v2/v3/v4 spec is doing today. > > I am surprised to see that you are still saying that your are NOT familiar > with H.323. If it is so, we have problems. An editor needs to be on the > top > of everything because the last editor did a good amount of job in a very > short period of time addressing all issues. We are now going backward and > losing our valuable time just because the editor is NOT familiar with > H.323. > If you ask questions, I would be happy to answer as much as I can. > > I like to see other members also provide comments on this. > > Best regards, > Radhika > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Friday, August 11, 2000 9:01 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > > Radhika, > > I think we are in total agreement until your last two paragraphs. Lets > figure out what problem we are solving and what we need to do to achieve > this, then examine the issues of backward compatibility. > > You are a lot more familiar than I am with the existing H.323 mechansims. > Why are these not transport mechansm independent as per your model? > > Mike > > > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Friday, August 11, 2000 12:58 PM > Subject: Re: H.323 QOS > > > Hi, Mike: > > Let me try again. > > What is the reference point of H.323 QOS? Is it not H.323? If it is so, > what > do we mean by H.323? > > The answer is: Audio (different codecs), Video (different codecs), and > Data > (T.120 applications) that are used by H.323. > > What are the QOS/performance characteristics of audio, video, and data > from > the application point of view that is generated by audio codecs, video > codecs, and data (T.120) applications? > > These QOS/performance characteristics come from the SOURCE codecs and data > applications. Per transport independent H.323 specifications, an enduser > express their QOS/performance requirements on end-to-end basis purely from > application point of view irrespective of the transport network (e.g., IP, > ATM, etc.). > > Moreover, H.323 is meant for the packet network, not for any > circuit-switched network like PSTN or ISDN. > > Let us NOT go beyond this before we start debating transport layer QOS or > service provider requirements. These are NOT the concern of H.323. H.323 > is > the transport independent application. > > H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be > used > for H.323 audio, video, and data. So, H.323 QOS that will be defined in > H.323 Annex N MUST provide mapping for the backward compatibility. It is a > requirement that MUST be met per the norm of ITU-T. > > So, what is left for mapping? Mapping is simply a by-product of the above > requirement. Mapping is simply a table, nothing else. > > Did I miss anything? > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Thursday, August 10, 2000 10:19 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > > Radhika, > > Thanks for the input which I welcome as I will unfortunately not be > present > at Portland. > > Let me ask a few questions and make a few comments hopefully with the > intent > of opening up the debate. > > 1. I am not sure I understand your concept of a mapping table between the > H.323 QOS and the transport layer QoS. My understanding is that QoS is on > three levels: > > a) that specified from a service point of view between the user and > service > provider (e.g PSTN quality, conference quality etc) This is the domain of > the speech experts and can be characterised by Listener Speech Quaklity > (MOS), end to end delay, and absolute category rating, R. > > b) application specific parameters, (e.g. equipment delays, codec choice > and performance, codec frame size, packetisation arrangements, jitter > buffer > design, overall packet loss etc.) Optimisation of all these will > determine > what can be delivered in a). > > c) transport parameters for a given choice of application parameters. > This > boils down only to three parameters as far as I cna see: tranport network > delay, packet delay variation in the transport network and packet loss in > the transport network. Again these parameters will determine the results > in > a) for a given choice of the parameters in b). These parameters are > generic > from the perspective of the transport network. i.e the transport network > does not need to know the details of the application. > > So the sequence of cause and effect and control is: > > a) User requests QoS class from service provider, > b) Service provider determines application specific parameters in > conjunction with users equipment and other service providers, > c) Service provider requests required delay, delay variation and packet > loss from network provider. > > I see no need for mapping here. The only QoS info flows within the > application are specific to the application and those between the > application (service provider) and the transport network are generic. i.e. > delay, jitter and packet loss. Have I missed something? > > 2. The issue of bit rate and media stream statistics I think need to be > decoupled from QoS. These are specified to enable optimisation of > resources > within the transport network. They have no QoS significance from an > application point of view. i.e the apllication does not care about the > media stream bit rate and statistics but the transport network provider > does > as it eats up his resource. They may be used for policy enforcement > however > in the transport network so they do need to be agreed between service > provider and network operator. i.e the network operator agrees to provide > a > given QoS level (delay, jitter, packet loss) provided the media properties > are within an agreed profile (bit rate, flow statistics). > > 3. The next point is how can the service provider know the statistics of > a > particular VBR stream? These can only be specified over a large number of > similar calls and will depend, for instance, on who is speaking, the > nature > of the speech interaction etc etc. They can only be measured not > calculated. The service provider is in no better position to measure > these > than the transport network operator and, in fact, where no gateways are > involved, may not be able to. On the other hand the class of signal would > have to be signalled to the network operator for him to be able to > distinguish which class a particular measurement belonged to. e.g > voice/speech/data, codec type, conference, multicast etc. So I see no > purpose in trying to exchange statistics between the service provider > (application) and transport operator. I think peak bit rate is all that > can > be meaningfully excanged. The specification of media class is however > perhaps worth exploring. > > 4. The controlled category has always puzzled me. I only see two > possibilities. Either the requested QoS level is guaranteed (on a > statistical basis e.g 95% of all connections over a specified period) or > not > guaranteed. Is your controlled category a way of saying guaranteed, not > to > 95% but to some lower figure? If you can't put a percentage on it then it > seems it is plain and simple not guaranteed. Anything that is not > guaranteed to some specified statistical level is best effort and you > can't > say anything more about it. So I only see two categories here. > > In summary, I think we need to do three things in Annex N. > > a) Figure out the QoS information to be exchanged within the Application > between service providers and end users. This will go in H.225.0 and > H.245. > > b) Figure out how we are going to signal QoS and media information between > the application (service providers) and transport domains (IP or ATM > networks etc). The info is basically delay, jitter, packet loss > requirements and peak bit rate. We need a protocol for this. > > c) we need to work out the interactions between the application QoS > signal > flows and the application/transport signal flows. I don't think we need > worry about how the transport network mechanisms assure the requested QoS > paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all > possibilities. > > Would welcome comments and views on the above. > > Mike > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Thursday, August 10, 2000 10:15 PM > Subject: H.323 QOS > > > Hi, Mike and All: > > It is time to discuss about H.323 QOS. > > I believe that we have an agreement as follows: > > · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it > exists for H.323v2/v3/v4 > · Like H.323 spec, the application level H.323 QOS MUST be independent of > the transport layer QOS and should support all transport networks (e.g., > IP, > ATM) > · A mapping table between the H.323 QOS and the transport layer QOS (e.g., > IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.]) > should be provided. > > From the H.323 multimedia application point of view, there are following > performance parameters can be used to characterize the traffic > characteristics: > > · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR), > Sustained > bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum > rate > (MR), and mean bust size (MBS) > · Delay and loss characteristics: end-to-end delay (EED) or delay, > end-to-end delay variation (EEDV) or delay variation (DV), and > bit-error-rate (BER) or (packet) loss rate (LR) > > We can now form a table with all parameters as follows: > > Table 1: H.323 Multimedia Application Performance Matrix > Audio (codecs)--- Video (codecs)--- Data > (T.120) > PBR/PR Yes/No/Value Yes/No/Value Yes/No/value > SBR/AR Yes/No/Value Yes/No/Value Yes/No/value > MBR/MR Yes/No/Value Yes/No/Value Yes/No/value > MBS Yes/No/Value Yes/No/Value Yes/No/value > EED/Delay Yes/No/Value Yes/No/Value Yes/No/value > EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value > BER/LR Yes/No/Value Yes/No/Value Yes/No/value > > From the above table we will have the opportunity to choose each parameter > for each medium (audio, video, data) that makes sense from the > application's > and enduser's point of view. Again, these parameters can be specified as > follows: > > · Guaranteed: The value specified for each parameter MUST be guaranteed. > · Controlled: The value specified for each parameter MAY be satisfied as > far > as practicable (possibly with certain range), but definitely NOT > guaranteed. > · Best effort: No commitment will be made. > > Now each medium (e.g., audio, video, or data) will have different > categories > of performance matrix depending on its selection criteria and this can > also > be mapped to RSVP, ATM QOS, and others, if needed. > > Once we agree on this format, the next step is to create H.323 QOS > signaling > messages. > > This is my input for discussion in the upcoming Portland Q.13 meeting for > H.323 QOS. > > I like to see the comments from other members as well. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 14 Aug '00

14 Aug '00

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

2 1

APC-1938
by Dave Walker 14 Aug '00

14 Aug '00

All, I've uploaded APC-1938 (H.323 Annex L) to Incoming. Regards, Dave Walker SS8 Networks Ottawa, Canada ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 14 Aug '00

14 Aug '00

Hi, Mike: I went through all of your replies. I wanted to send another reply for each point of yours, but it may be too long and may not be understandable. My suggestion is that you should bring contributions against the exiting Appendix of H.323 Annex N. This appendix has been created based on contributions that were submitted. So, it is better that you should make your point against that appendix leaving no ambiguity so that you can make your points. I feel that your are describing QOS without limiting in the framework of H.323. The most serious problems that I have with your reply is that you are mixing the H.323 QOS with implementation issues. With respect to pre-call setup QOS scenarios (i.e., QOS discovery), please see Appendix of H.323 Annex H.323. QOS works are established facts in ITU-T, IETF, and ATM Forum. Appendix of H.323 Annex N has shown clearly how H.323 application layer QOS can be integrated over all heterogeneous network layer QOS if one does the mapping using the table for the network layer QOS. Best regards, Radhika R. Roy > -----Original Message----- > From: Mike Buckley [SMTP:mikebuckley@44COMMS.COM] > Sent: Friday, August 11, 2000 8:13 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > [RRR] Certainly it is NOT the case. It is H.323, and nothing to do with > service providers or network operators. H.323 spec only deals with the > application on end-to-end basis. > > [PMB] The problem is ALL to do with service providers and network > operators > and their business relations with each other and their customers. See my > comments below on architecture. H.323 is > signalling between a user and an IP telephony service provider (assuming > we > use the gatekeeper model). If a network operator provides H.323 support > he > is by definition also a service provider. A network operator's role by my > definition is to provide generic IP Transport. There are QoS issues to be > resolved in both the application layer (service provider) and transport > layer (IP transport network). There needs to be co-ordination between the > two although the two must be mechanism independent. > > [RRR] It is NOT true. Please see H.245 spec how each medium is signaled > along with QOS parameters (e.g., RSVP, ATM QOS). It already exits in > H.323/H.245 on end-to-end basis if there is only one kind of network. We > are > just extending the same concept on end-to-end basis if there is one or > multiple networks. If there is only one network either IP or ATM, H.323 > QOS > does NOT need any additional work per se. For IP network, H.323 provides > the > support of RSVP and more work may be needed if DiffServ or MPLS needs to > be > supported. For ATM QOS, H.323 QOS spec is also complete. But if there are > combinations of IP and ATM (and/or other networks), there is no end-to-end > H.323 QOS signaling mechanism that can be used as an universal set across > all networks. In fact, as I told before, we are SOLVING this problem in > H..323 Annex N. > > [PMB] There are a lot of issues here. In the multiple network case there > is > no point in signalling properties related to the transport QoS mechanisms. > You yourself agreed that the apllication signalling should be independent > of > transport mechanism. This can also be the case for the single domain > which > is just a special case of the multiple domain situation. The existing > H.323 > mechanisms make a number of simplifying assumptions that would not work > in > practice. There are issues of control, trust, policy enforcement and > business relations that are not taken into account in the existing model. > I > believe Annex N is about solving the general case and providing an H.323 > solution for ends to end control in mixed multi-domain networks where > multiple operators are involved and multiple service providers. If we > don't solve the general case I believe the Standard will be failing the > market. > > Incidentally you say my comments about media stream statistics are not > true > but the points you make are orthogonal to the points I am making. > > [RRR] Please see the Appendix of H.323 Annex N how the QOS classes and the > corresponding signaling messages have been created, and how the signaling > will be done. There are two stages of H.313 QOS signaling: 1. Pre-call > setup > phase and 2. Call setup phase. In pre-call setup, it is the empty > signaling > messages sets that will be sent to determine whether these kind of QOS > classes are supported on end-to-end basis. It is called the discovery > phase. > So far, it has been the ONLY goal for H.323 QOS. > > [PMB] Could you eloborate on the objectives at the discovery phase. Is > this > done on a per call basis? If you are saying there needs to be signalling > end to end between service providers to find out whether a particular QoS > request can be supported before the call can be set up I am in basic > agreement. I don't see this as an issue of QoS classes however but one of > QoS budgets. > > [RRR] For the call setup phase, the actual values of all those parameters > are needed. We expect that the values can be chosen by endusers if there > are > no standards. However, if other SGs or forums (e.g., TIPHON, IMTC, SLA > agreements, etc.) define those values, people can also use those specific > values. Then the H.323 QOS signaling messages can use those implementation > specific values. H.323 QOS will only have the place holder for those > values. > > [PMB] Yes, I agree in principle. But the user will usually only specify > the QoS class he wants as agreed between him and his service provider. He > will not be specifying end to end delay, jitter and packet loss, although > I > agree he could. In either case these parameters can only be calculated > once > a compatible codec has been chosen. > > The next problem is allocating budgets across domains once the end to end > budgets have been extablished. This has to be done by some network or > service provider based entity. > > [RRR] H.245 is currently using RSVP and ATM QOS and we will use the > similar > approach. No new work is needed here. > > [PMB] This is a contradiction of your axiom that the application level > techniques must be independent of the transport domain QoS mechanism. You > can't signal the transport QoS mechanism where there are multiple domains. > And I think there are a lot of unresolved issues in doing this in the > single > domain case. I thought you had made this point yourself above. > > [RRR] the order of events are shown in Appendix of > H.323 Annex N. > > [PMB] Please could you explain in words what is happening. Once we close > on > the principles we can start to look at the code. > > [RRR] H.323 does not define anything related to service providers, > application providers, or network providers. It is implementation > specific. > It will only deal with the H.323 QOS signaling messages on end-to-end > basis > as it has been dong for RSVP and ATM QOS. Let other SGs or forums do some > implementation specific agreement/standard for H.323 QOS. > > [PMB] We have to resolve the roles of these parties to figure out what we > are going to put in H.323 messages. You are bundling them all together > and > pretending there is only one entity to coinsider - the network. This > approach will not provide the solutions we are looking for in the multiple > domain case or where there are business relations and issues of trust and > control to take into account between different entities. This is not just > an issue of implementation. Terminal registration is a real issue and > some > QoS elements will almost certainly have to be added to RAS. > > [RRR] Again a GK can signal QOS parameters, but H.323 does not recognize > service providers, applications providers, or network providers. However, > the GK will signal using the H.323 QOS messages. The QOS signaling > messages > will contain many parameters (I do not think that it will contain QOS > level > per se). > > [PMB] H.323 is a protocol. But you can't decide how you are going to use > a > protocol to solve a problem until you have an architecture in mind. > That's > what we are discussing. Service providers and network operators > inevitably > enter into the architecture. I agree with your last two sentences. My > previous comments have been addressing what goes into the H.323 QoS > fields. > > [RRR] H.245 has well established negotiation capabilities. We do not need > to > do any additional work here. > > [PMB] Agreed. But we need to take into account when this info is > available > because the decision effects QoS budgets. > > [RRR] Please see my answers provided above. Currently, Appendix of H.323 > Annex N has it completed how the pre-call setup signaling messages can be > exchanged. The call setup phase will use the same mechanism as it exists > today for RSVP and ATM QOS. We will only augment this using NEW parameters > of H.323 QOS. > > [PMB] Again you seem to be contradicting yourself here. How can we use > the > same approach across heterogeneous domains and be transport mechanism > independent? > > [RRR] The pre-call setup and call setup phase that will use H.323 QOS > messages (as shown in Appendix of H.323 QOS) will meet the QOS > requirements. > I do not think that we should "INVENT" any new security mechanisms ONLY > specific to H.323 QOS. Security should be dealt for H.323 in general. This > work MUST be de-coupled from H.323 QOS. > > [PMB] I believe we have to invent something new here if we are to solve > the > problem of multiple domains. Authorisation is not new however. Policy > decision on > H.323 QoS is in the application and policy enforcement in the transport > network. They have to talk to one another. We don't have a solution to > this today. Without a solution to this we have not solved the problem we > have set ourself on controlling end to ends QoS. > > Mike > > > > > > > > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Friday, August 11, 2000 7:46 PM > Subject: Re: H.323 QOS > > > Hi, Mike: > > Please see my response stated below [RRR]. > > Best regards, > Radhika > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Friday, August 11, 2000 1:24 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > > Radhika, > > Sorry , I am not following your arguments here. I thought your Table 1 > was > a description of the QoS requirements and media stream properties that > would > be signalled by the application/service provider to the network operator. > This is transport QoS mechansm independent. > [RRR] Certainly it is NOT the case. It is H.323, and nothing to do with > service providers or network operators. H.323 spec only deals with the > application on end-to-end basis. > > I maintain that the media statistic parameters can not in general be > signalled on a per media stream basis. Only peak bit rate has any meaning > to the application and derives from the choice of codec and packetisation > arrangements. > [RRR] It is NOT true. Please see H.245 spec how each medium is signaled > along with QOS parameters (e.g., RSVP, ATM QOS). It already exits in > H.323/H.245 on end-to-end basis if there is only one kind of network. We > are > just extending the same concept on end-to-end basis if there is one or > multiple networks. If there is only one network either IP or ATM, H.323 > QOS > does NOT need any additional work per se. For IP network, H.323 provides > the > support of RSVP and more work may be needed if DiffServ or MPLS needs to > be > supported. For ATM QOS, H.323 QOS spec is also complete. But if there are > combinations of IP and ATM (and/or other networks), there is no end-to-end > H.323 QOS signaling mechanism that can be used as an universal set across > all networks. In fact, as I told before, we are SOLVING this problem in > H..323 Annex N. > > In agree the values in the Table do not need to be specified in the > protocol. I am happy with YES/NO/Value with Value being optional in the > case of YES. > [RRR] I am glad to hear that we are in agreement here. > > >So, the first problem is to express performance/QOS parameters that do > NOT > >contain any values. That is, it will have only the parameters without any > >value. For example, all audio/video codecs will have their parameters > >expressed that will have only a limited set (in the previous case as can > be > >seen in Appendix of Annex N - there has been only 4 sets, etc.). These > are > >universal sets and does not matter what the codec type is. > > You have lost me here. What is the point signalling empty sets? > [RRR] Please see the Appendix of H.323 Annex N how the QOS classes and the > corresponding signaling messages have been created, and how the signaling > will be done. There are two stages of H.313 QOS signaling: 1. Pre-call > setup > phase and 2. Call setup phase. In pre-call setup, it is the empty > signaling > messages sets that will be sent to determine whether these kind of QOS > classes are supported on end-to-end basis. It is called the discovery > phase. > So far, it has been the ONLY goal for H.323 QOS. > > [RRR] For the call setup phase, the actual values of all those parameters > are needed. We expect that the values can be chosen by endusers if there > are > no standards. However, if other SGs or forums (e.g., TIPHON, IMTC, SLA > agreements, etc.) define those values, people can also use those specific > values. Then the H.323 QOS signaling messages can use those implementation > specific values. H.323 QOS will only have the place holder for those > values. > > The order > of events must surely be: [RRR] the order of events are shown in Appendix > of > H.323 Annex N. > > a) User requests QoS level of service provider: gold, silver etc. > [RRR] Again, this is implementation specific and SG16 is not the right > place > to define gold, silver, etc. for H.323. > > b) Application uses H.225.0 and H.245 to establish compatible codecs and > packetisation arrangements consistent with a), > [RRR] H.245 is currently using RSVP and ATM QOS and we will use the > similar > approach. No new work is needed here. > > c) Application computes delay, delay variation and bit error rate > required > of transport network and signalls these to transport network operator. > [RRR] We do not need to do anything NEW other than the similar thing what > H.245 is doing currently for RSVP and ATM QOS. > > H.225.0 and h.245 will be used to: > > a) register a terminal's QoS characteristics with the service provider > (gatekeeper). > [RRR] H.323 does not define anything related to service providers, > application providers, or network providers. It is implementation > specific. > It will only deal with the H.323 QOS signaling messages on end-to-end > basis > as it has been dong for RSVP and ATM QOS. Let other SGs or forums do some > implementation specific agreement/standard for H.323 QOS. > > b) for user to request gold, silver or bronze or the end to end QoS > parameters from a service provider (gatekeeper), > [RRR] Again, it is an implementation issue, not a H.323 QOS protocol > issue: > gold, silver, etc. My response for item a is applicable. > > c) for service providers (gatekeepers) to signal QoS parameters to each > other to enable end to end QoS levels to be achieved. > [RRR] Again a GK can signal QOS parameters, but H.323 does not recognize > service providers, applications providers, or network providers. However, > the GK will signal using the H.323 QOS messages. The QOS signaling > messages > will contain many parameters (I do not think that it will contain QOS > level > per se). > > d) to establish compatible codecs and packetisation at both ends of a > media > stream. > [RRR] H.245 has well established negotiation capabilities. We do not need > to > > do any additional work here. > > Registration will take place prior to call set up. The rest of the QoS > information flows must take place at call set up. > [RRR] Please see my answers provided above. Currently, Appendix of H.323 > Annex N has it completed how the pre-call setup signaling messages can be > exchanged. The call setup phase will use the same mechanism as it exists > today for RSVP and ATM QOS. We will only augment this using NEW parameters > of H.323 QOS. > > We need a new protocol for signalling QoS requirements and authorisations > to > the network operator. > [RRR] The pre-call setup and call setup phase that will use H.323 QOS > messages (as shown in Appendix of H.323 QOS) will meet the QOS > requirements. > I do not think that we should "INVENT" any new security mechanisms ONLY > specific to H.323 QOS. Security should be dealt for H.323 in general. This > work MUST be de-coupled from H.323 QOS. > > > Let's continue the debate on this lists - this is the best way of arriving > at an agreed approach. Documenting it once we have agreement on what the > problem is and how we are going to solve it should be quite > straightforward. > I hope we will have something to determine in November. > [RRR] Yes, this has been the main purpose of my email. Moreover, emails go > to all people throughout the whole world. Each one of us can participate. > This is the MOST convenient way for resolving issues. I appreciate your > response. > > Mike > > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Friday, August 11, 2000 5:09 PM > Subject: Re: H.323 QOS > > > Hi, Mike: > > Please note the following: > > Table 1 shows all parameters that are observed in digitization form. > (There > may be similarity with some transport level parameters, but these are > expressed in a transport independent way.) > > A given codec/data (appln.) may or may have all the parameters. If not, > those parameters will be NOT be used. > > Each parameter contain: Yes/No and Value. > > So, the first problem is to express performance/QOS parameters that do NOT > contain any values. That is, it will have only the parameters without any > value. For example, all audio/video codecs will have their parameters > expressed that will have only a limited set (in the previous case as can > be > seen in Appendix of Annex N - there has been only 4 sets, etc.). These are > universal sets and does not matter what the codec type is. > > In H.323, we are NOT defining values of the parameters because values are > subjective and implementation dependent. The values of any given QOS > parameter or a set of QOS parameters are beyond the scope of H.323 > (Q.13/16). The values are being defined in other SGs or organizations > (e.g., > TIPHON, IMTC, etc.). > > You are right that the values for each codec will be different. People may > define many classes based on values as well. For example, 100ms delay is > gold service, 150ms delay is silver service, etc. In Annex N, we will not > be > addressing those values. > > The same is also true for data. > > Defining of QOS values of any given parameters is OUT of scope of H.323. > > It appears that there is a mis-understanding. I do not any intention for > any > personal attack other than to complete the work on time (if it appears so, > I > apologize for this). > > Hope this clarifies your questions. > > Best regards, > Radhika R. Roy > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Friday, August 11, 2000 11:08 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > > Radhika, > > >The basic problem is to express the end-to-end H.323 QOS parameters of > each > >medium (audio, video, data) that are applicable no matter what the > >underlying transport network (or networks) is. > > >The answer of this problem is Table 1 that I have provided. > > We agree on the first paragraph. The problem I have with your Table 1 > relates to media statistics (see my earlier comments). Incidentally the > columns are the properties of transport media streams. the values will > be > dependent on media type, codec, packetisation etc. So I am not sure what > the relevance of codec or T.120 is in the heading. The parameters in each > column are what I regard as the generic bearer descriptor. > > >Now we have to group those parameters in different combinations for each > >medium that makes sense from the enduser point of view to satisfy their > >requirements. > > >This is the simple problem. > > The values follow from the users QoS service request, and the choices made > by the application in achieving this (codec type, packetisation, jitter > buffer design). Once the application has figured out what these > parameters > are then the entries in your table can be computed by the application and > flagged to the transport operator on a domain by domain basis or > end-to-end > if there is one homogeneous transport space. > > >A by-product of this solution needs to satisfy RSVP and ATM QOS as > >H.323v2/v3/v4 spec is doing today. > > I see no conflict with the use of these transport mechanisms in the > transport plane. You seem terribly worried about this. What is the > problem? > > >I am surprised to see that you are still saying that your are NOT > familiar > >with H.323. If it is so, we have problems. An editor needs to be on the > top > >of everything because the last editor did a good amount of job in a very > >short period of time addressing all issues. We are now going backward and > >losing our valuable time just because the editor is NOT familiar with > H.323. > >If you ask questions, I would be happy to answer as much as I can. > > You are putting words into my mouth here that I never used. Why the > personal attack? I thought the discussion had been quite constructive up > to this point. > > Mike > > > > > > > > > > > > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Friday, August 11, 2000 2:41 PM > Subject: Re: H.323 QOS > > > Hi, Mike: > > The basic problem is to express the end-to-end H.323 QOS parameters of > each > medium (audio, video, data) that are applicable no matter what the > underlying transport network (or networks) is. > > The answer of this problem is Table 1 that I have provided. > > Now we have to group those parameters in different combinations for each > medium that makes sense from the enduser point of view to satisfy their > requirements. > > This is the simple problem. > > A by-product of this solution needs to satisfy RSVP and ATM QOS as > H.323v2/v3/v4 spec is doing today. > > I am surprised to see that you are still saying that your are NOT familiar > with H.323. If it is so, we have problems. An editor needs to be on the > top > of everything because the last editor did a good amount of job in a very > short period of time addressing all issues. We are now going backward and > losing our valuable time just because the editor is NOT familiar with > H.323. > If you ask questions, I would be happy to answer as much as I can. > > I like to see other members also provide comments on this. > > Best regards, > Radhika > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Friday, August 11, 2000 9:01 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > > Radhika, > > I think we are in total agreement until your last two paragraphs. Lets > figure out what problem we are solving and what we need to do to achieve > this, then examine the issues of backward compatibility. > > You are a lot more familiar than I am with the existing H.323 mechansims. > Why are these not transport mechansm independent as per your model? > > Mike > > > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Friday, August 11, 2000 12:58 PM > Subject: Re: H.323 QOS > > > Hi, Mike: > > Let me try again. > > What is the reference point of H.323 QOS? Is it not H.323? If it is so, > what > do we mean by H.323? > > The answer is: Audio (different codecs), Video (different codecs), and > Data > (T.120 applications) that are used by H.323. > > What are the QOS/performance characteristics of audio, video, and data > from > the application point of view that is generated by audio codecs, video > codecs, and data (T.120) applications? > > These QOS/performance characteristics come from the SOURCE codecs and data > applications. Per transport independent H.323 specifications, an enduser > express their QOS/performance requirements on end-to-end basis purely from > application point of view irrespective of the transport network (e.g., IP, > ATM, etc.). > > Moreover, H.323 is meant for the packet network, not for any > circuit-switched network like PSTN or ISDN. > > Let us NOT go beyond this before we start debating transport layer QOS or > service provider requirements. These are NOT the concern of H.323. H.323 > is > the transport independent application. > > H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be > used > for H.323 audio, video, and data. So, H.323 QOS that will be defined in > H.323 Annex N MUST provide mapping for the backward compatibility. It is a > requirement that MUST be met per the norm of ITU-T. > > So, what is left for mapping? Mapping is simply a by-product of the above > requirement. Mapping is simply a table, nothing else. > > Did I miss anything? > > Best regards, > Radhika R. Roy > AT&T > > -----Original Message----- > From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] > Sent: Thursday, August 10, 2000 10:19 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 QOS > > > Radhika, > > Thanks for the input which I welcome as I will unfortunately not be > present > at Portland. > > Let me ask a few questions and make a few comments hopefully with the > intent > of opening up the debate. > > 1. I am not sure I understand your concept of a mapping table between the > H.323 QOS and the transport layer QoS. My understanding is that QoS is on > three levels: > > a) that specified from a service point of view between the user and > service > provider (e.g PSTN quality, conference quality etc) This is the domain of > the speech experts and can be characterised by Listener Speech Quaklity > (MOS), end to end delay, and absolute category rating, R. > > b) application specific parameters, (e.g. equipment delays, codec choice > and performance, codec frame size, packetisation arrangements, jitter > buffer > design, overall packet loss etc.) Optimisation of all these will > determine > what can be delivered in a). > > c) transport parameters for a given choice of application parameters. > This > boils down only to three parameters as far as I cna see: tranport network > delay, packet delay variation in the transport network and packet loss in > the transport network. Again these parameters will determine the results > in > a) for a given choice of the parameters in b). These parameters are > generic > from the perspective of the transport network. i.e the transport network > does not need to know the details of the application. > > So the sequence of cause and effect and control is: > > a) User requests QoS class from service provider, > b) Service provider determines application specific parameters in > conjunction with users equipment and other service providers, > c) Service provider requests required delay, delay variation and packet > loss from network provider. > > I see no need for mapping here. The only QoS info flows within the > application are specific to the application and those between the > application (service provider) and the transport network are generic. i.e. > delay, jitter and packet loss. Have I missed something? > > 2. The issue of bit rate and media stream statistics I think need to be > decoupled from QoS. These are specified to enable optimisation of > resources > within the transport network. They have no QoS significance from an > application point of view. i.e the apllication does not care about the > media stream bit rate and statistics but the transport network provider > does > as it eats up his resource. They may be used for policy enforcement > however > in the transport network so they do need to be agreed between service > provider and network operator. i.e the network operator agrees to provide > a > given QoS level (delay, jitter, packet loss) provided the media properties > are within an agreed profile (bit rate, flow statistics). > > 3. The next point is how can the service provider know the statistics of > a > particular VBR stream? These can only be specified over a large number of > similar calls and will depend, for instance, on who is speaking, the > nature > of the speech interaction etc etc. They can only be measured not > calculated. The service provider is in no better position to measure > these > than the transport network operator and, in fact, where no gateways are > involved, may not be able to. On the other hand the class of signal would > have to be signalled to the network operator for him to be able to > distinguish which class a particular measurement belonged to. e.g > voice/speech/data, codec type, conference, multicast etc. So I see no > purpose in trying to exchange statistics between the service provider > (application) and transport operator. I think peak bit rate is all that > can > be meaningfully excanged. The specification of media class is however > perhaps worth exploring. > > 4. The controlled category has always puzzled me. I only see two > possibilities. Either the requested QoS level is guaranteed (on a > statistical basis e.g 95% of all connections over a specified period) or > not > guaranteed. Is your controlled category a way of saying guaranteed, not > to > 95% but to some lower figure? If you can't put a percentage on it then it > seems it is plain and simple not guaranteed. Anything that is not > guaranteed to some specified statistical level is best effort and you > can't > say anything more about it. So I only see two categories here. > > In summary, I think we need to do three things in Annex N. > > a) Figure out the QoS information to be exchanged within the Application > between service providers and end users. This will go in H.225.0 and > H.245. > > b) Figure out how we are going to signal QoS and media information between > the application (service providers) and transport domains (IP or ATM > networks etc). The info is basically delay, jitter, packet loss > requirements and peak bit rate. We need a protocol for this. > > c) we need to work out the interactions between the application QoS > signal > flows and the application/transport signal flows. I don't think we need > worry about how the transport network mechanisms assure the requested QoS > paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all > possibilities. > > Would welcome comments and views on the above. > > Mike > > > Mike Buckley > +44-1457-877718 (T) > +44-1457-877721 (F) > mikebuckley(a)44comms.com > > > ----- Original Message ----- > From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> > To: <ITU-SG16(a)MAILBAG.INTEL.COM> > Sent: Thursday, August 10, 2000 10:15 PM > Subject: H.323 QOS > > > Hi, Mike and All: > > It is time to discuss about H.323 QOS. > > I believe that we have an agreement as follows: > > · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it > exists for H.323v2/v3/v4 > · Like H.323 spec, the application level H.323 QOS MUST be independent of > the transport layer QOS and should support all transport networks (e.g., > IP, > ATM) > · A mapping table between the H.323 QOS and the transport layer QOS (e.g., > IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.]) > should be provided. > > From the H.323 multimedia application point of view, there are following > performance parameters can be used to characterize the traffic > characteristics: > > · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR), > Sustained > bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum > rate > (MR), and mean bust size (MBS) > · Delay and loss characteristics: end-to-end delay (EED) or delay, > end-to-end delay variation (EEDV) or delay variation (DV), and > bit-error-rate (BER) or (packet) loss rate (LR) > > We can now form a table with all parameters as follows: > > Table 1: H.323 Multimedia Application Performance Matrix > Audio (codecs)--- Video (codecs)--- Data > (T.120) > PBR/PR Yes/No/Value Yes/No/Value Yes/No/value > SBR/AR Yes/No/Value Yes/No/Value Yes/No/value > MBR/MR Yes/No/Value Yes/No/Value Yes/No/value > MBS Yes/No/Value Yes/No/Value Yes/No/value > EED/Delay Yes/No/Value Yes/No/Value Yes/No/value > EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value > BER/LR Yes/No/Value Yes/No/Value Yes/No/value > > From the above table we will have the opportunity to choose each parameter > for each medium (audio, video, data) that makes sense from the > application's > and enduser's point of view. Again, these parameters can be specified as > follows: > > · Guaranteed: The value specified for each parameter MUST be guaranteed. > · Controlled: The value specified for each parameter MAY be satisfied as > far > as practicable (possibly with certain range), but definitely NOT > guaranteed. > · Best effort: No commitment will be made. > > Now each medium (e.g., audio, video, or data) will have different > categories > of performance matrix depending on its selection criteria and this can > also > be mapped to RSVP, ATM QOS, and others, if needed. > > Once we agree on this format, the next step is to create H.323 QOS > signaling > messages. > > This is my input for discussion in the upcoming Portland Q.13 meeting for > H.323 QOS. > > I like to see the comments from other members as well. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 13 Aug '00

13 Aug '00

Hi, Mike: Further to my earlier (enclosed) email, I like to mention that H.323 QOS is also addressing problems where a single network may have different kinds of network layer QOS signaling schemes. For example, an IP network may have different domains where one domain implements RSVP, the other domain implements DiffServ, and the another domain implements MPLS, etc. H.323 QOS will provide the end-to-end "application" layer QOS signaling mechanism that is universal from end users' point of view no matter whether there are multiple networks (e.g., IP, ATM), or whether one network that implements heterogeneous "network" layer QOS (e.g., RSVP, DiffServ, MPLS, etc.) schemes. By the way, the Appendix of H.323 Annex N has almost all the answers. I strongly believe, as explained in the earlier email per your questions (enclosed), that we have all the solution ready to use. If you have any questions, please also ask me, the past editor Rich Bowen, or others who have been working bringing contributions related to H.323 QOS problems. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Roy, Radhika R, ALCOO Sent: Friday, August 11, 2000 2:47 PM To: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: RE: H.323 QOS Hi, Mike: Please see my response stated below [RRR]. Best regards, Radhika -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, August 11, 2000 1:24 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, Sorry , I am not following your arguments here. I thought your Table 1 was a description of the QoS requirements and media stream properties that would be signalled by the application/service provider to the network operator. This is transport QoS mechansm independent. [RRR] Certainly it is NOT the case. It is H.323, and nothing to do with service providers or network operators. H.323 spec only deals with the application on end-to-end basis. I maintain that the media statistic parameters can not in general be signalled on a per media stream basis. Only peak bit rate has any meaning to the application and derives from the choice of codec and packetisation arrangements. [RRR] It is NOT true. Please see H.245 spec how each medium is signaled along with QOS parameters (e.g., RSVP, ATM QOS). It already exits in H.323/H.245 on end-to-end basis if there is only one kind of network. We are just extending the same concept on end-to-end basis if there is one or multiple networks. If there is only one network either IP or ATM, H.323 QOS does NOT need any additional work per se. For IP network, H.323 provides the support of RSVP and more work may be needed if DiffServ or MPLS needs to be supported. For ATM QOS, H.323 QOS spec is also complete. But if there are combinations of IP and ATM (and/or other networks), there is no end-to-end H.323 QOS signaling mechanism that can be used as an universal set across all networks. In fact, as I told before, we are SOLVING this problem in H..323 Annex N. In agree the values in the Table do not need to be specified in the protocol. I am happy with YES/NO/Value with Value being optional in the case of YES. [RRR] I am glad to hear that we are in agreement here. >So, the first problem is to express performance/QOS parameters that do NOT >contain any values. That is, it will have only the parameters without any >value. For example, all audio/video codecs will have their parameters >expressed that will have only a limited set (in the previous case as can be >seen in Appendix of Annex N - there has been only 4 sets, etc.). These are >universal sets and does not matter what the codec type is. You have lost me here. What is the point signalling empty sets? [RRR] Please see the Appendix of H.323 Annex N how the QOS classes and the corresponding signaling messages have been created, and how the signaling will be done. There are two stages of H.313 QOS signaling: 1. Pre-call setup phase and 2. Call setup phase. In pre-call setup, it is the empty signaling messages sets that will be sent to determine whether these kind of QOS classes are supported on end-to-end basis. It is called the discovery phase. So far, it has been the ONLY goal for H.323 QOS. [RRR] For the call setup phase, the actual values of all those parameters are needed. We expect that the values can be chosen by endusers if there are no standards. However, if other SGs or forums (e.g., TIPHON, IMTC, SLA agreements, etc.) define those values, people can also use those specific values. Then the H.323 QOS signaling messages can use those implementation specific values. H.323 QOS will only have the place holder for those values. The order of events must surely be: [RRR] the order of events are shown in Appendix of H.323 Annex N. a) User requests QoS level of service provider: gold, silver etc. [RRR] Again, this is implementation specific and SG16 is not the right place to define gold, silver, etc. for H.323. b) Application uses H.225.0 and H.245 to establish compatible codecs and packetisation arrangements consistent with a), [RRR] H.245 is currently using RSVP and ATM QOS and we will use the similar approach. No new work is needed here. c) Application computes delay, delay variation and bit error rate required of transport network and signalls these to transport network operator. [RRR] We do not need to do anything NEW other than the similar thing what H.245 is doing currently for RSVP and ATM QOS. H.225.0 and h.245 will be used to: a) register a terminal's QoS characteristics with the service provider (gatekeeper). [RRR] H.323 does not define anything related to service providers, application providers, or network providers. It is implementation specific. It will only deal with the H.323 QOS signaling messages on end-to-end basis as it has been dong for RSVP and ATM QOS. Let other SGs or forums do some implementation specific agreement/standard for H.323 QOS. b) for user to request gold, silver or bronze or the end to end QoS parameters from a service provider (gatekeeper), [RRR] Again, it is an implementation issue, not a H.323 QOS protocol issue: gold, silver, etc. My response for item a is applicable. c) for service providers (gatekeepers) to signal QoS parameters to each other to enable end to end QoS levels to be achieved. [RRR] Again a GK can signal QOS parameters, but H.323 does not recognize service providers, applications providers, or network providers. However, the GK will signal using the H.323 QOS messages. The QOS signaling messages will contain many parameters (I do not think that it will contain QOS level per se). d) to establish compatible codecs and packetisation at both ends of a media stream. [RRR] H.245 has well established negotiation capabilities. We do not need to do any additional work here. Registration will take place prior to call set up. The rest of the QoS information flows must take place at call set up. [RRR] Please see my answers provided above. Currently, Appendix of H.323 Annex N has it completed how the pre-call setup signaling messages can be exchanged. The call setup phase will use the same mechanism as it exists today for RSVP and ATM QOS. We will only augment this using NEW parameters of H.323 QOS. We need a new protocol for signalling QoS requirements and authorisations to the network operator. [RRR] The pre-call setup and call setup phase that will use H.323 QOS messages (as shown in Appendix of H.323 QOS) will meet the QOS requirements. I do not think that we should "INVENT" any new security mechanisms ONLY specific to H.323 QOS. Security should be dealt for H.323 in general. This work MUST be de-coupled from H.323 QOS. Let's continue the debate on this lists - this is the best way of arriving at an agreed approach. Documenting it once we have agreement on what the problem is and how we are going to solve it should be quite straightforward. I hope we will have something to determine in November. [RRR] Yes, this has been the main purpose of my email. Moreover, emails go to all people throughout the whole world. Each one of us can participate. This is the MOST convenient way for resolving issues. I appreciate your response. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Friday, August 11, 2000 5:09 PM Subject: Re: H.323 QOS Hi, Mike: Please note the following: Table 1 shows all parameters that are observed in digitization form. (There may be similarity with some transport level parameters, but these are expressed in a transport independent way.) A given codec/data (appln.) may or may have all the parameters. If not, those parameters will be NOT be used. Each parameter contain: Yes/No and Value. So, the first problem is to express performance/QOS parameters that do NOT contain any values. That is, it will have only the parameters without any value. For example, all audio/video codecs will have their parameters expressed that will have only a limited set (in the previous case as can be seen in Appendix of Annex N - there has been only 4 sets, etc.). These are universal sets and does not matter what the codec type is. In H.323, we are NOT defining values of the parameters because values are subjective and implementation dependent. The values of any given QOS parameter or a set of QOS parameters are beyond the scope of H.323 (Q.13/16). The values are being defined in other SGs or organizations (e.g., TIPHON, IMTC, etc.). You are right that the values for each codec will be different. People may define many classes based on values as well. For example, 100ms delay is gold service, 150ms delay is silver service, etc. In Annex N, we will not be addressing those values. The same is also true for data. Defining of QOS values of any given parameters is OUT of scope of H.323. It appears that there is a mis-understanding. I do not any intention for any personal attack other than to complete the work on time (if it appears so, I apologize for this). Hope this clarifies your questions. Best regards, Radhika R. Roy -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, August 11, 2000 11:08 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, >The basic problem is to express the end-to-end H.323 QOS parameters of each >medium (audio, video, data) that are applicable no matter what the >underlying transport network (or networks) is. >The answer of this problem is Table 1 that I have provided. We agree on the first paragraph. The problem I have with your Table 1 relates to media statistics (see my earlier comments). Incidentally the columns are the properties of transport media streams. the values will be dependent on media type, codec, packetisation etc. So I am not sure what the relevance of codec or T.120 is in the heading. The parameters in each column are what I regard as the generic bearer descriptor. >Now we have to group those parameters in different combinations for each >medium that makes sense from the enduser point of view to satisfy their >requirements. >This is the simple problem. The values follow from the users QoS service request, and the choices made by the application in achieving this (codec type, packetisation, jitter buffer design). Once the application has figured out what these parameters are then the entries in your table can be computed by the application and flagged to the transport operator on a domain by domain basis or end-to-end if there is one homogeneous transport space. >A by-product of this solution needs to satisfy RSVP and ATM QOS as >H.323v2/v3/v4 spec is doing today. I see no conflict with the use of these transport mechanisms in the transport plane. You seem terribly worried about this. What is the problem? >I am surprised to see that you are still saying that your are NOT familiar >with H.323. If it is so, we have problems. An editor needs to be on the top >of everything because the last editor did a good amount of job in a very >short period of time addressing all issues. We are now going backward and >losing our valuable time just because the editor is NOT familiar with H.323. >If you ask questions, I would be happy to answer as much as I can. You are putting words into my mouth here that I never used. Why the personal attack? I thought the discussion had been quite constructive up to this point. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Friday, August 11, 2000 2:41 PM Subject: Re: H.323 QOS Hi, Mike: The basic problem is to express the end-to-end H.323 QOS parameters of each medium (audio, video, data) that are applicable no matter what the underlying transport network (or networks) is. The answer of this problem is Table 1 that I have provided. Now we have to group those parameters in different combinations for each medium that makes sense from the enduser point of view to satisfy their requirements. This is the simple problem. A by-product of this solution needs to satisfy RSVP and ATM QOS as H.323v2/v3/v4 spec is doing today. I am surprised to see that you are still saying that your are NOT familiar with H.323. If it is so, we have problems. An editor needs to be on the top of everything because the last editor did a good amount of job in a very short period of time addressing all issues. We are now going backward and losing our valuable time just because the editor is NOT familiar with H.323. If you ask questions, I would be happy to answer as much as I can. I like to see other members also provide comments on this. Best regards, Radhika -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, August 11, 2000 9:01 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, I think we are in total agreement until your last two paragraphs. Lets figure out what problem we are solving and what we need to do to achieve this, then examine the issues of backward compatibility. You are a lot more familiar than I am with the existing H.323 mechansims. Why are these not transport mechansm independent as per your model? Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Friday, August 11, 2000 12:58 PM Subject: Re: H.323 QOS Hi, Mike: Let me try again. What is the reference point of H.323 QOS? Is it not H.323? If it is so, what do we mean by H.323? The answer is: Audio (different codecs), Video (different codecs), and Data (T.120 applications) that are used by H.323. What are the QOS/performance characteristics of audio, video, and data from the application point of view that is generated by audio codecs, video codecs, and data (T.120) applications? These QOS/performance characteristics come from the SOURCE codecs and data applications. Per transport independent H.323 specifications, an enduser express their QOS/performance requirements on end-to-end basis purely from application point of view irrespective of the transport network (e.g., IP, ATM, etc.). Moreover, H.323 is meant for the packet network, not for any circuit-switched network like PSTN or ISDN. Let us NOT go beyond this before we start debating transport layer QOS or service provider requirements. These are NOT the concern of H.323. H.323 is the transport independent application. H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be used for H.323 audio, video, and data. So, H.323 QOS that will be defined in H.323 Annex N MUST provide mapping for the backward compatibility. It is a requirement that MUST be met per the norm of ITU-T. So, what is left for mapping? Mapping is simply a by-product of the above requirement. Mapping is simply a table, nothing else. Did I miss anything? Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Thursday, August 10, 2000 10:19 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, Thanks for the input which I welcome as I will unfortunately not be present at Portland. Let me ask a few questions and make a few comments hopefully with the intent of opening up the debate. 1. I am not sure I understand your concept of a mapping table between the H.323 QOS and the transport layer QoS. My understanding is that QoS is on three levels: a) that specified from a service point of view between the user and service provider (e.g PSTN quality, conference quality etc) This is the domain of the speech experts and can be characterised by Listener Speech Quaklity (MOS), end to end delay, and absolute category rating, R. b) application specific parameters, (e.g. equipment delays, codec choice and performance, codec frame size, packetisation arrangements, jitter buffer design, overall packet loss etc.) Optimisation of all these will determine what can be delivered in a). c) transport parameters for a given choice of application parameters. This boils down only to three parameters as far as I cna see: tranport network delay, packet delay variation in the transport network and packet loss in the transport network. Again these parameters will determine the results in a) for a given choice of the parameters in b). These parameters are generic from the perspective of the transport network. i.e the transport network does not need to know the details of the application. So the sequence of cause and effect and control is: a) User requests QoS class from service provider, b) Service provider determines application specific parameters in conjunction with users equipment and other service providers, c) Service provider requests required delay, delay variation and packet loss from network provider. I see no need for mapping here. The only QoS info flows within the application are specific to the application and those between the application (service provider) and the transport network are generic. i.e. delay, jitter and packet loss. Have I missed something? 2. The issue of bit rate and media stream statistics I think need to be decoupled from QoS. These are specified to enable optimisation of resources within the transport network. They have no QoS significance from an application point of view. i.e the apllication does not care about the media stream bit rate and statistics but the transport network provider does as it eats up his resource. They may be used for policy enforcement however in the transport network so they do need to be agreed between service provider and network operator. i.e the network operator agrees to provide a given QoS level (delay, jitter, packet loss) provided the media properties are within an agreed profile (bit rate, flow statistics). 3. The next point is how can the service provider know the statistics of a particular VBR stream? These can only be specified over a large number of similar calls and will depend, for instance, on who is speaking, the nature of the speech interaction etc etc. They can only be measured not calculated. The service provider is in no better position to measure these than the transport network operator and, in fact, where no gateways are involved, may not be able to. On the other hand the class of signal would have to be signalled to the network operator for him to be able to distinguish which class a particular measurement belonged to. e.g voice/speech/data, codec type, conference, multicast etc. So I see no purpose in trying to exchange statistics between the service provider (application) and transport operator. I think peak bit rate is all that can be meaningfully excanged. The specification of media class is however perhaps worth exploring. 4. The controlled category has always puzzled me. I only see two possibilities. Either the requested QoS level is guaranteed (on a statistical basis e.g 95% of all connections over a specified period) or not guaranteed. Is your controlled category a way of saying guaranteed, not to 95% but to some lower figure? If you can't put a percentage on it then it seems it is plain and simple not guaranteed. Anything that is not guaranteed to some specified statistical level is best effort and you can't say anything more about it. So I only see two categories here. In summary, I think we need to do three things in Annex N. a) Figure out the QoS information to be exchanged within the Application between service providers and end users. This will go in H.225.0 and H.245. b) Figure out how we are going to signal QoS and media information between the application (service providers) and transport domains (IP or ATM networks etc). The info is basically delay, jitter, packet loss requirements and peak bit rate. We need a protocol for this. c) we need to work out the interactions between the application QoS signal flows and the application/transport signal flows. I don't think we need worry about how the transport network mechanisms assure the requested QoS paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all possibilities. Would welcome comments and views on the above. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Thursday, August 10, 2000 10:15 PM Subject: H.323 QOS Hi, Mike and All: It is time to discuss about H.323 QOS. I believe that we have an agreement as follows: · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it exists for H.323v2/v3/v4 · Like H.323 spec, the application level H.323 QOS MUST be independent of the transport layer QOS and should support all transport networks (e.g., IP, ATM) · A mapping table between the H.323 QOS and the transport layer QOS (e.g., IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.]) should be provided. >From the H.323 multimedia application point of view, there are following performance parameters can be used to characterize the traffic characteristics: · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR), Sustained bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum rate (MR), and mean bust size (MBS) · Delay and loss characteristics: end-to-end delay (EED) or delay, end-to-end delay variation (EEDV) or delay variation (DV), and bit-error-rate (BER) or (packet) loss rate (LR) We can now form a table with all parameters as follows: Table 1: H.323 Multimedia Application Performance Matrix Audio (codecs)--- Video (codecs)--- Data (T.120) PBR/PR Yes/No/Value Yes/No/Value Yes/No/value SBR/AR Yes/No/Value Yes/No/Value Yes/No/value MBR/MR Yes/No/Value Yes/No/Value Yes/No/value MBS Yes/No/Value Yes/No/Value Yes/No/value EED/Delay Yes/No/Value Yes/No/Value Yes/No/value EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value BER/LR Yes/No/Value Yes/No/Value Yes/No/value >From the above table we will have the opportunity to choose each parameter for each medium (audio, video, data) that makes sense from the application's and enduser's point of view. Again, these parameters can be specified as follows: · Guaranteed: The value specified for each parameter MUST be guaranteed. · Controlled: The value specified for each parameter MAY be satisfied as far as practicable (possibly with certain range), but definitely NOT guaranteed. · Best effort: No commitment will be made. Now each medium (e.g., audio, video, or data) will have different categories of performance matrix depending on its selection criteria and this can also be mapped to RSVP, ATM QOS, and others, if needed. Once we agree on this format, the next step is to create H.323 QOS signaling messages. This is my input for discussion in the upcoming Portland Q.13 meeting for H.323 QOS. I like to see the comments from other members as well. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

H.323 Mobility
by Roy, Radhika R, ALCOO 13 Aug '00

13 Aug '00

Hi, Everyone: In addition to uploading of the contributions, I feel that it would be better we could start email discussion on these contributions if possible. It may save time in the upcoming Portland meeting. In this connection, I am enclosing the summary of the two contributions as follows: APC-1932: Comments on H.323 Annex H (MTD-101b) Abstract Comments on H.323 Annex H have been provided to modify the text and figures of MTD-101b. The comments have been provided in two categories: General and Specific. The general comments are applicable for the entire document while the specific comments are to be considered case by case basis for each section. It has been clearly mentioned how AT&T contributions APC-1926, D.354, APC-1770, and others can be used to take care of all comments. These comments were also provided to the SG16 email reflector, and it is believed that these comments were accepted because no counter technical arguments were received in the email reflector explaining the fact why these comments were not acceptable. APC-1926: H.323 Intra-Zone Mobility Management using the AuF and HLF Abstract We have discussed how the network address (e.g., IP address) can be acquired using different mechanisms (e.g., DHCP, mobile IP, or other schemes) by an H.323 mobile entity if it moves from one place to another. Once the network address is obtained after being connected to a network, it can listen to the mobile gatekeeper advertisement (MGA) message for discovering the GK in a well-known multicast port (alternatively, the GRQ message can also be sent to discover the GK). If needed, the MGA can also be unicast to the mobile entity although the process may not be so dynamic as in the case of the multicast. We have shown that a new GK advertisement message (MGA) [3] is the most efficient way of discovering the GK in a highly as well as relatively less mobile environment: Cell-based wireless network, wireless LAN, and/or wire-line network. In addition, the extended GRQ/GCF/GRJ [3] messages can also be used in certain situations when MGA message is not received within certain time interval. The combination of the MGA and GRQ message scheme makes the GK discovery most efficient and reliable for mobile communications environments. It has been clearly depicted how the extended RRQ [3] message needs to be used to take care of many options that a mobile entity may like to use for service provisioning in static mode because the mobility service related parameters need to be stored in the HLF. In this situation, a GK needs to access the HLF directly, and does NOT need to use the VLF. The direct communications between the home GK and the HLF may also be needed for storing and retrieving the mobility related information when the mobile remains in its home network point of attachment (home-NPoA) or if it moves from its home network to a foreign (visiting/target) network in its home zone because an H.323 mobile entity that remains within a home zone is NOT considered a "visitor" or "foreigner" by the home GK. The primary services that are needed are the discovery of the mobile gatekeepers (GKs), registration with the GK by the mobile entities, location updates for mobile's visiting, home, and visited network address along with interaction of the authentication function (AuF) and home location function (HLF) as the mobile entity changes its point of attachments (e.g., network point of attachment). We have discussed some issues as follows: Should we include the service related profile in the RRQ message for dynamically service provisioning in the HLF and new messages between the GK and AuF/HLF? Finally, we have shown communications message flows for location updates for intra-zone communications to mange the mobility of mobile entities. It may be observed that the communications to the AuF and HLF entities are performed via the GK. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com -----Original Message----- From: Roy, Radhika R, ALCOO Sent: Friday, August 11, 2000 9:47 AM To: 'Sakae OKUBO' Subject: APC-1926 and APC-1932 Dear Mr. OKUBO; Kindly upload the enclosed APCs (APC-1926 and APC-1932). 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

1 0

Uploaded contributions 1910, 1911, 1912, 1913, 1914
by Christian Groves 13 Aug '00

13 Aug '00

Dear SG 16 experts, Contributions: 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 Have been uploaded to the incoming directory on the Pictel site. Cheers, Christian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

InterScan eManager Content Management Notification! (Block Html)
by virus-protection＠BOSCH.COM 12 Aug '00

12 Aug '00

******Message from InterScan E-Mail VirusWall NT****** The following mail was blocked by InterScan eManager Content Management. Source mailbox: <ITU-SG16(a)mailbag.cps.intel.com> Destination mailbox(es): <Marek.Przybyszewski(a)DE.BOSCH.COM> Policy: Block Html Action: Delete HTML with active content detected and because of high virus risk deleted; HTML Mail mit aktiven Inhalt gefunden und aufgrund hoher Virengefahr gelöscht. ******************* End of message ******************* Received: (from uucp@localhost) by gwa.fe.bosch.de (8.9.1/8.9.1) id CAA10387 for <Marek.Przybyszewski(a)DE.BOSCH.COM>; Sun, 13 Aug 2000 02:31:13 +0200 (MET DST) Received: from mailbag.cps.intel.com( 192.102.199.72) by gwa.fe.bosch.de via smap (V2.1) id xma010364; Sun, 13 Aug 00 02:31:11 +0200 Received: from mailbag.intel.com (mailbag.cps.intel.com [192.102.199.72]) by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA29954; Sat, 12 Aug 2000 17:25:47 -0700 (PDT) Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 242419 for ITU-SG16(a)MAILBAG.INTEL.COM; Sat, 12 Aug 2000 17:25:46 -0700 Received: from serwer.net2000.pl (serwer.net2000.pl [212.244.211.2]) by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA29931 for <itu-sg16(a)mailbag.cps.intel.com>; Sat, 12 Aug 2000 17:15:44 -0700 (PDT) Received: from host (quincy-ip-3-160.dynamic.ziplink.net [206.15.159.160]) by serwer.net2000.pl (8.9.3/8.9.0) with ESMTP id CAA02743; Sun, 13 Aug 2000 02:06:25 +0200 X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Message-ID: <200008130006.CAA02743(a)serwer.net2000.pl> Date: Sat, 12 Aug 2000 18:45:14 -0500 Reply-To: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> Sender: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> From: Randy Gregory <yyz83(a)MAIL1ST.COM> Subject: Our Top List #6C73 Comments: To: join39k(a)serwer.net2000.pl To: ITU-SG16(a)mailbag.cps.intel.com

1 0

InterScan eManager Content Management Notification! (Block Html)
by virus-protection＠BOSCH.COM 12 Aug '00

12 Aug '00

******Message from InterScan E-Mail VirusWall NT****** The following mail was blocked by InterScan eManager Content Management. Source mailbox: <ITU-SG16(a)mailbag.cps.intel.com> Destination mailbox(es): <Monika.Harwardt(a)TENOVIS.COM>,<Bjoern.Soelch(a)TENOVIS.COM>,<Axel.Niebuhr(a)TENOVIS.COM> Policy: Block Html Action: Delete HTML with active content detected and because of high virus risk deleted; HTML Mail mit aktiven Inhalt gefunden und aufgrund hoher Virengefahr gelöscht. ******************* End of message ******************* Received: (from uucp@localhost) by gwa2.fe.bosch.de (8.9.1/8.9.1) id AAA02759; Sun, 13 Aug 2000 00:28:27 GMT Received: from mailbag.cps.intel.com( 192.102.199.72) by gwa2.fe.bosch.de via smap (V2.1) id xma002752; Sun, 13 Aug 00 00:28:14 GMT Received: from mailbag.intel.com (mailbag.cps.intel.com [192.102.199.72]) by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA29963; Sat, 12 Aug 2000 17:25:50 -0700 (PDT) Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 242419 for ITU-SG16(a)MAILBAG.INTEL.COM; Sat, 12 Aug 2000 17:25:46 -0700 Received: from serwer.net2000.pl (serwer.net2000.pl [212.244.211.2]) by mailbag.cps.intel.com (8.9.3/8.9.1/d: relay.m4,v 1.6 1998/11/24 22:10:56 iwep Exp iwep $) with ESMTP id RAA29931 for <itu-sg16(a)mailbag.cps.intel.com>; Sat, 12 Aug 2000 17:15:44 -0700 (PDT) Received: from host (quincy-ip-3-160.dynamic.ziplink.net [206.15.159.160]) by serwer.net2000.pl (8.9.3/8.9.0) with ESMTP id CAA02743; Sun, 13 Aug 2000 02:06:25 +0200 X-Mailer: DiffondiCool V3,1,6,0 (W95/NT) (Build: Oct 18 1999) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01BDF6C7.FABAC1B0" Content-Transfer-Encoding: 7bit Message-ID: <200008130006.CAA02743(a)serwer.net2000.pl> Date: Sat, 12 Aug 2000 18:45:14 -0500 Reply-To: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> Sender: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> From: Randy Gregory <yyz83(a)MAIL1ST.COM> Subject: Our Top List #6C73 Comments: To: join39k(a)serwer.net2000.pl To: ITU-SG16(a)mailbag.cps.intel.com

1 0

APC-1945 H.248 Annex F fax/text/call discrimination status and white draft submitted
by Gunnar Hellstrom 12 Aug '00

12 Aug '00

Dear all, I have placed document APC-1945 for the Portland Q.12-Q.14 meeting in the Incoming directory of the Pictel avc-site. I hope it will appear soon in the 0008_Por directory for the meeting. Title: H.248 Annex F fax/text/call discrimination, status and white draft. Source: Editor ( Gunnar Hellström, Ericsson ) Document for: Information The document is already sent as a white draft to ITU. The reason to enter the document in this meeting is merely to clarify the status since there are other contributions to H.248 Annex F. ----------------------------Copy of first page of APC-1945:--------------------------------- Status: This document contains the white draft H.248 Annex F. facsimile, text conversation and call discrimination packages. 1. After the determination in February 2000, small modifications have been requested by Q14/16, Q4/8, Q9/16 and Q4/1. They are incorporated. 2. The document was handled by Q.4/8 in a meeting in June. The resulting comments can be found in APC-1890 and APC-1892 issued by Q.4/8 representatives. 3. The document was handled by Q.4/16, Q.9/16 and WP1/16 in a meeting in Edinburgh in June. 4. The contents of documents APC-1890 and APC-1892 proposing modifications for the facsimile parts were available at that meeting and all proposed changes were incorporated. 5. To the knowledge of the editor, also the contents of APC-1891 T.38 Appendix V- is in line with the current edition of H.248 Annex F. 6. Possible extensions to fully cover data modem discrimination, session establishment and transport were briefly discussed in Q.4/16. No action was taken because of lack of contributions. It should be noted that the current document contains full functionality for the modem negotiation and can therefore be extended by other packages to also cover the modulation and transport of data modem traffic. 7. The document has also been converted to pure text format and entered as an Internet Draft to IETF as draft-ietf-megaco-h248f-00.txt Included here is the white draft as sent to the TSB for decision in the Study Group 16 meeting in November. -------------end of excerpt--------------------------------- Regards ------------------------------------------ Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 8 556 002 03 Mob +46 708 204 288 fax +46 8 556 002 06 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: APC for draft H.225.0 v4
by Sakae OKUBO 11 Aug '00

11 Aug '00

Dear contributors and all, APC numbers have been allocated to your contributions as attached. This list is close to final. Please take a look at it and advise me if your contribution is not included. This list is uploaded as /0008_Por/0008_Por.doc and /0008_Por/0008_Por.html 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) ------< 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 { to suggest amendments in the H.323 standard } 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 Cisco Systems Comments on the Object Extensible Framework 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 Cisco Systems Issues with Processing Unsolicited IRRs --------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 11 Aug '00

11 Aug '00

Hi, Mike: Please see my response stated below [RRR]. Best regards, Radhika -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, August 11, 2000 1:24 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, Sorry , I am not following your arguments here. I thought your Table 1 was a description of the QoS requirements and media stream properties that would be signalled by the application/service provider to the network operator. This is transport QoS mechansm independent. [RRR] Certainly it is NOT the case. It is H.323, and nothing to do with service providers or network operators. H.323 spec only deals with the application on end-to-end basis. I maintain that the media statistic parameters can not in general be signalled on a per media stream basis. Only peak bit rate has any meaning to the application and derives from the choice of codec and packetisation arrangements. [RRR] It is NOT true. Please see H.245 spec how each medium is signaled along with QOS parameters (e.g., RSVP, ATM QOS). It already exits in H.323/H.245 on end-to-end basis if there is only one kind of network. We are just extending the same concept on end-to-end basis if there is one or multiple networks. If there is only one network either IP or ATM, H.323 QOS does NOT need any additional work per se. For IP network, H.323 provides the support of RSVP and more work may be needed if DiffServ or MPLS needs to be supported. For ATM QOS, H.323 QOS spec is also complete. But if there are combinations of IP and ATM (and/or other networks), there is no end-to-end H.323 QOS signaling mechanism that can be used as an universal set across all networks. In fact, as I told before, we are SOLVING this problem in H..323 Annex N. In agree the values in the Table do not need to be specified in the protocol. I am happy with YES/NO/Value with Value being optional in the case of YES. [RRR] I am glad to hear that we are in agreement here. >So, the first problem is to express performance/QOS parameters that do NOT >contain any values. That is, it will have only the parameters without any >value. For example, all audio/video codecs will have their parameters >expressed that will have only a limited set (in the previous case as can be >seen in Appendix of Annex N - there has been only 4 sets, etc.). These are >universal sets and does not matter what the codec type is. You have lost me here. What is the point signalling empty sets? [RRR] Please see the Appendix of H.323 Annex N how the QOS classes and the corresponding signaling messages have been created, and how the signaling will be done. There are two stages of H.313 QOS signaling: 1. Pre-call setup phase and 2. Call setup phase. In pre-call setup, it is the empty signaling messages sets that will be sent to determine whether these kind of QOS classes are supported on end-to-end basis. It is called the discovery phase. So far, it has been the ONLY goal for H.323 QOS. [RRR] For the call setup phase, the actual values of all those parameters are needed. We expect that the values can be chosen by endusers if there are no standards. However, if other SGs or forums (e.g., TIPHON, IMTC, SLA agreements, etc.) define those values, people can also use those specific values. Then the H.323 QOS signaling messages can use those implementation specific values. H.323 QOS will only have the place holder for those values. The order of events must surely be: [RRR] the order of events are shown in Appendix of H.323 Annex N. a) User requests QoS level of service provider: gold, silver etc. [RRR] Again, this is implementation specific and SG16 is not the right place to define gold, silver, etc. for H.323. b) Application uses H.225.0 and H.245 to establish compatible codecs and packetisation arrangements consistent with a), [RRR] H.245 is currently using RSVP and ATM QOS and we will use the similar approach. No new work is needed here. c) Application computes delay, delay variation and bit error rate required of transport network and signalls these to transport network operator. [RRR] We do not need to do anything NEW other than the similar thing what H.245 is doing currently for RSVP and ATM QOS. H.225.0 and h.245 will be used to: a) register a terminal's QoS characteristics with the service provider (gatekeeper). [RRR] H.323 does not define anything related to service providers, application providers, or network providers. It is implementation specific. It will only deal with the H.323 QOS signaling messages on end-to-end basis as it has been dong for RSVP and ATM QOS. Let other SGs or forums do some implementation specific agreement/standard for H.323 QOS. b) for user to request gold, silver or bronze or the end to end QoS parameters from a service provider (gatekeeper), [RRR] Again, it is an implementation issue, not a H.323 QOS protocol issue: gold, silver, etc. My response for item a is applicable. c) for service providers (gatekeepers) to signal QoS parameters to each other to enable end to end QoS levels to be achieved. [RRR] Again a GK can signal QOS parameters, but H.323 does not recognize service providers, applications providers, or network providers. However, the GK will signal using the H.323 QOS messages. The QOS signaling messages will contain many parameters (I do not think that it will contain QOS level per se). d) to establish compatible codecs and packetisation at both ends of a media stream. [RRR] H.245 has well established negotiation capabilities. We do not need to do any additional work here. Registration will take place prior to call set up. The rest of the QoS information flows must take place at call set up. [RRR] Please see my answers provided above. Currently, Appendix of H.323 Annex N has it completed how the pre-call setup signaling messages can be exchanged. The call setup phase will use the same mechanism as it exists today for RSVP and ATM QOS. We will only augment this using NEW parameters of H.323 QOS. We need a new protocol for signalling QoS requirements and authorisations to the network operator. [RRR] The pre-call setup and call setup phase that will use H.323 QOS messages (as shown in Appendix of H.323 QOS) will meet the QOS requirements. I do not think that we should "INVENT" any new security mechanisms ONLY specific to H.323 QOS. Security should be dealt for H.323 in general. This work MUST be de-coupled from H.323 QOS. Let's continue the debate on this lists - this is the best way of arriving at an agreed approach. Documenting it once we have agreement on what the problem is and how we are going to solve it should be quite straightforward. I hope we will have something to determine in November. [RRR] Yes, this has been the main purpose of my email. Moreover, emails go to all people throughout the whole world. Each one of us can participate. This is the MOST convenient way for resolving issues. I appreciate your response. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Friday, August 11, 2000 5:09 PM Subject: Re: H.323 QOS Hi, Mike: Please note the following: Table 1 shows all parameters that are observed in digitization form. (There may be similarity with some transport level parameters, but these are expressed in a transport independent way.) A given codec/data (appln.) may or may have all the parameters. If not, those parameters will be NOT be used. Each parameter contain: Yes/No and Value. So, the first problem is to express performance/QOS parameters that do NOT contain any values. That is, it will have only the parameters without any value. For example, all audio/video codecs will have their parameters expressed that will have only a limited set (in the previous case as can be seen in Appendix of Annex N - there has been only 4 sets, etc.). These are universal sets and does not matter what the codec type is. In H.323, we are NOT defining values of the parameters because values are subjective and implementation dependent. The values of any given QOS parameter or a set of QOS parameters are beyond the scope of H.323 (Q.13/16). The values are being defined in other SGs or organizations (e.g., TIPHON, IMTC, etc.). You are right that the values for each codec will be different. People may define many classes based on values as well. For example, 100ms delay is gold service, 150ms delay is silver service, etc. In Annex N, we will not be addressing those values. The same is also true for data. Defining of QOS values of any given parameters is OUT of scope of H.323. It appears that there is a mis-understanding. I do not any intention for any personal attack other than to complete the work on time (if it appears so, I apologize for this). Hope this clarifies your questions. Best regards, Radhika R. Roy -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, August 11, 2000 11:08 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, >The basic problem is to express the end-to-end H.323 QOS parameters of each >medium (audio, video, data) that are applicable no matter what the >underlying transport network (or networks) is. >The answer of this problem is Table 1 that I have provided. We agree on the first paragraph. The problem I have with your Table 1 relates to media statistics (see my earlier comments). Incidentally the columns are the properties of transport media streams. the values will be dependent on media type, codec, packetisation etc. So I am not sure what the relevance of codec or T.120 is in the heading. The parameters in each column are what I regard as the generic bearer descriptor. >Now we have to group those parameters in different combinations for each >medium that makes sense from the enduser point of view to satisfy their >requirements. >This is the simple problem. The values follow from the users QoS service request, and the choices made by the application in achieving this (codec type, packetisation, jitter buffer design). Once the application has figured out what these parameters are then the entries in your table can be computed by the application and flagged to the transport operator on a domain by domain basis or end-to-end if there is one homogeneous transport space. >A by-product of this solution needs to satisfy RSVP and ATM QOS as >H.323v2/v3/v4 spec is doing today. I see no conflict with the use of these transport mechanisms in the transport plane. You seem terribly worried about this. What is the problem? >I am surprised to see that you are still saying that your are NOT familiar >with H.323. If it is so, we have problems. An editor needs to be on the top >of everything because the last editor did a good amount of job in a very >short period of time addressing all issues. We are now going backward and >losing our valuable time just because the editor is NOT familiar with H.323. >If you ask questions, I would be happy to answer as much as I can. You are putting words into my mouth here that I never used. Why the personal attack? I thought the discussion had been quite constructive up to this point. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Friday, August 11, 2000 2:41 PM Subject: Re: H.323 QOS Hi, Mike: The basic problem is to express the end-to-end H.323 QOS parameters of each medium (audio, video, data) that are applicable no matter what the underlying transport network (or networks) is. The answer of this problem is Table 1 that I have provided. Now we have to group those parameters in different combinations for each medium that makes sense from the enduser point of view to satisfy their requirements. This is the simple problem. A by-product of this solution needs to satisfy RSVP and ATM QOS as H.323v2/v3/v4 spec is doing today. I am surprised to see that you are still saying that your are NOT familiar with H.323. If it is so, we have problems. An editor needs to be on the top of everything because the last editor did a good amount of job in a very short period of time addressing all issues. We are now going backward and losing our valuable time just because the editor is NOT familiar with H.323. If you ask questions, I would be happy to answer as much as I can. I like to see other members also provide comments on this. Best regards, Radhika -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, August 11, 2000 9:01 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, I think we are in total agreement until your last two paragraphs. Lets figure out what problem we are solving and what we need to do to achieve this, then examine the issues of backward compatibility. You are a lot more familiar than I am with the existing H.323 mechansims. Why are these not transport mechansm independent as per your model? Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Friday, August 11, 2000 12:58 PM Subject: Re: H.323 QOS Hi, Mike: Let me try again. What is the reference point of H.323 QOS? Is it not H.323? If it is so, what do we mean by H.323? The answer is: Audio (different codecs), Video (different codecs), and Data (T.120 applications) that are used by H.323. What are the QOS/performance characteristics of audio, video, and data from the application point of view that is generated by audio codecs, video codecs, and data (T.120) applications? These QOS/performance characteristics come from the SOURCE codecs and data applications. Per transport independent H.323 specifications, an enduser express their QOS/performance requirements on end-to-end basis purely from application point of view irrespective of the transport network (e.g., IP, ATM, etc.). Moreover, H.323 is meant for the packet network, not for any circuit-switched network like PSTN or ISDN. Let us NOT go beyond this before we start debating transport layer QOS or service provider requirements. These are NOT the concern of H.323. H.323 is the transport independent application. H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be used for H.323 audio, video, and data. So, H.323 QOS that will be defined in H.323 Annex N MUST provide mapping for the backward compatibility. It is a requirement that MUST be met per the norm of ITU-T. So, what is left for mapping? Mapping is simply a by-product of the above requirement. Mapping is simply a table, nothing else. Did I miss anything? Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Thursday, August 10, 2000 10:19 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, Thanks for the input which I welcome as I will unfortunately not be present at Portland. Let me ask a few questions and make a few comments hopefully with the intent of opening up the debate. 1. I am not sure I understand your concept of a mapping table between the H.323 QOS and the transport layer QoS. My understanding is that QoS is on three levels: a) that specified from a service point of view between the user and service provider (e.g PSTN quality, conference quality etc) This is the domain of the speech experts and can be characterised by Listener Speech Quaklity (MOS), end to end delay, and absolute category rating, R. b) application specific parameters, (e.g. equipment delays, codec choice and performance, codec frame size, packetisation arrangements, jitter buffer design, overall packet loss etc.) Optimisation of all these will determine what can be delivered in a). c) transport parameters for a given choice of application parameters. This boils down only to three parameters as far as I cna see: tranport network delay, packet delay variation in the transport network and packet loss in the transport network. Again these parameters will determine the results in a) for a given choice of the parameters in b). These parameters are generic from the perspective of the transport network. i.e the transport network does not need to know the details of the application. So the sequence of cause and effect and control is: a) User requests QoS class from service provider, b) Service provider determines application specific parameters in conjunction with users equipment and other service providers, c) Service provider requests required delay, delay variation and packet loss from network provider. I see no need for mapping here. The only QoS info flows within the application are specific to the application and those between the application (service provider) and the transport network are generic. i.e. delay, jitter and packet loss. Have I missed something? 2. The issue of bit rate and media stream statistics I think need to be decoupled from QoS. These are specified to enable optimisation of resources within the transport network. They have no QoS significance from an application point of view. i.e the apllication does not care about the media stream bit rate and statistics but the transport network provider does as it eats up his resource. They may be used for policy enforcement however in the transport network so they do need to be agreed between service provider and network operator. i.e the network operator agrees to provide a given QoS level (delay, jitter, packet loss) provided the media properties are within an agreed profile (bit rate, flow statistics). 3. The next point is how can the service provider know the statistics of a particular VBR stream? These can only be specified over a large number of similar calls and will depend, for instance, on who is speaking, the nature of the speech interaction etc etc. They can only be measured not calculated. The service provider is in no better position to measure these than the transport network operator and, in fact, where no gateways are involved, may not be able to. On the other hand the class of signal would have to be signalled to the network operator for him to be able to distinguish which class a particular measurement belonged to. e.g voice/speech/data, codec type, conference, multicast etc. So I see no purpose in trying to exchange statistics between the service provider (application) and transport operator. I think peak bit rate is all that can be meaningfully excanged. The specification of media class is however perhaps worth exploring. 4. The controlled category has always puzzled me. I only see two possibilities. Either the requested QoS level is guaranteed (on a statistical basis e.g 95% of all connections over a specified period) or not guaranteed. Is your controlled category a way of saying guaranteed, not to 95% but to some lower figure? If you can't put a percentage on it then it seems it is plain and simple not guaranteed. Anything that is not guaranteed to some specified statistical level is best effort and you can't say anything more about it. So I only see two categories here. In summary, I think we need to do three things in Annex N. a) Figure out the QoS information to be exchanged within the Application between service providers and end users. This will go in H.225.0 and H.245. b) Figure out how we are going to signal QoS and media information between the application (service providers) and transport domains (IP or ATM networks etc). The info is basically delay, jitter, packet loss requirements and peak bit rate. We need a protocol for this. c) we need to work out the interactions between the application QoS signal flows and the application/transport signal flows. I don't think we need worry about how the transport network mechanisms assure the requested QoS paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all possibilities. Would welcome comments and views on the above. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Thursday, August 10, 2000 10:15 PM Subject: H.323 QOS Hi, Mike and All: It is time to discuss about H.323 QOS. I believe that we have an agreement as follows: · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it exists for H.323v2/v3/v4 · Like H.323 spec, the application level H.323 QOS MUST be independent of the transport layer QOS and should support all transport networks (e.g., IP, ATM) · A mapping table between the H.323 QOS and the transport layer QOS (e.g., IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.]) should be provided. >From the H.323 multimedia application point of view, there are following performance parameters can be used to characterize the traffic characteristics: · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR), Sustained bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum rate (MR), and mean bust size (MBS) · Delay and loss characteristics: end-to-end delay (EED) or delay, end-to-end delay variation (EEDV) or delay variation (DV), and bit-error-rate (BER) or (packet) loss rate (LR) We can now form a table with all parameters as follows: Table 1: H.323 Multimedia Application Performance Matrix Audio (codecs)--- Video (codecs)--- Data (T.120) PBR/PR Yes/No/Value Yes/No/Value Yes/No/value SBR/AR Yes/No/Value Yes/No/Value Yes/No/value MBR/MR Yes/No/Value Yes/No/Value Yes/No/value MBS Yes/No/Value Yes/No/Value Yes/No/value EED/Delay Yes/No/Value Yes/No/Value Yes/No/value EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value BER/LR Yes/No/Value Yes/No/Value Yes/No/value >From the above table we will have the opportunity to choose each parameter for each medium (audio, video, data) that makes sense from the application's and enduser's point of view. Again, these parameters can be specified as follows: · Guaranteed: The value specified for each parameter MUST be guaranteed. · Controlled: The value specified for each parameter MAY be satisfied as far as practicable (possibly with certain range), but definitely NOT guaranteed. · Best effort: No commitment will be made. Now each medium (e.g., audio, video, or data) will have different categories of performance matrix depending on its selection criteria and this can also be mapped to RSVP, ATM QOS, and others, if needed. Once we agree on this format, the next step is to create H.323 QOS signaling messages. This is my input for discussion in the upcoming Portland Q.13 meeting for H.323 QOS. I like to see the comments from other members as well. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 11 Aug '00

11 Aug '00

Hi, Mike: Please note the following: Table 1 shows all parameters that are observed in digitization form. (There may be similarity with some transport level parameters, but these are expressed in a transport independent way.) A given codec/data (appln.) may or may have all the parameters. If not, those parameters will be NOT be used. Each parameter contain: Yes/No and Value. So, the first problem is to express performance/QOS parameters that do NOT contain any values. That is, it will have only the parameters without any value. For example, all audio/video codecs will have their parameters expressed that will have only a limited set (in the previous case as can be seen in Appendix of Annex N - there has been only 4 sets, etc.). These are universal sets and does not matter what the codec type is. In H.323, we are NOT defining values of the parameters because values are subjective and implementation dependent. The values of any given QOS parameter or a set of QOS parameters are beyond the scope of H.323 (Q.13/16). The values are being defined in other SGs or organizations (e.g., TIPHON, IMTC, etc.). You are right that the values for each codec will be different. People may define many classes based on values as well. For example, 100ms delay is gold service, 150ms delay is silver service, etc. In Annex N, we will not be addressing those values. The same is also true for data. Defining of QOS values of any given parameters is OUT of scope of H.323. It appears that there is a mis-understanding. I do not any intention for any personal attack other than to complete the work on time (if it appears so, I apologize for this). Hope this clarifies your questions. Best regards, Radhika R. Roy -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, August 11, 2000 11:08 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, >The basic problem is to express the end-to-end H.323 QOS parameters of each >medium (audio, video, data) that are applicable no matter what the >underlying transport network (or networks) is. >The answer of this problem is Table 1 that I have provided. We agree on the first paragraph. The problem I have with your Table 1 relates to media statistics (see my earlier comments). Incidentally the columns are the properties of transport media streams. the values will be dependent on media type, codec, packetisation etc. So I am not sure what the relevance of codec or T.120 is in the heading. The parameters in each column are what I regard as the generic bearer descriptor. >Now we have to group those parameters in different combinations for each >medium that makes sense from the enduser point of view to satisfy their >requirements. >This is the simple problem. The values follow from the users QoS service request, and the choices made by the application in achieving this (codec type, packetisation, jitter buffer design). Once the application has figured out what these parameters are then the entries in your table can be computed by the application and flagged to the transport operator on a domain by domain basis or end-to-end if there is one homogeneous transport space. >A by-product of this solution needs to satisfy RSVP and ATM QOS as >H.323v2/v3/v4 spec is doing today. I see no conflict with the use of these transport mechanisms in the transport plane. You seem terribly worried about this. What is the problem? >I am surprised to see that you are still saying that your are NOT familiar >with H.323. If it is so, we have problems. An editor needs to be on the top >of everything because the last editor did a good amount of job in a very >short period of time addressing all issues. We are now going backward and >losing our valuable time just because the editor is NOT familiar with H.323. >If you ask questions, I would be happy to answer as much as I can. You are putting words into my mouth here that I never used. Why the personal attack? I thought the discussion had been quite constructive up to this point. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Friday, August 11, 2000 2:41 PM Subject: Re: H.323 QOS Hi, Mike: The basic problem is to express the end-to-end H.323 QOS parameters of each medium (audio, video, data) that are applicable no matter what the underlying transport network (or networks) is. The answer of this problem is Table 1 that I have provided. Now we have to group those parameters in different combinations for each medium that makes sense from the enduser point of view to satisfy their requirements. This is the simple problem. A by-product of this solution needs to satisfy RSVP and ATM QOS as H.323v2/v3/v4 spec is doing today. I am surprised to see that you are still saying that your are NOT familiar with H.323. If it is so, we have problems. An editor needs to be on the top of everything because the last editor did a good amount of job in a very short period of time addressing all issues. We are now going backward and losing our valuable time just because the editor is NOT familiar with H.323. If you ask questions, I would be happy to answer as much as I can. I like to see other members also provide comments on this. Best regards, Radhika -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, August 11, 2000 9:01 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, I think we are in total agreement until your last two paragraphs. Lets figure out what problem we are solving and what we need to do to achieve this, then examine the issues of backward compatibility. You are a lot more familiar than I am with the existing H.323 mechansims. Why are these not transport mechansm independent as per your model? Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Friday, August 11, 2000 12:58 PM Subject: Re: H.323 QOS Hi, Mike: Let me try again. What is the reference point of H.323 QOS? Is it not H.323? If it is so, what do we mean by H.323? The answer is: Audio (different codecs), Video (different codecs), and Data (T.120 applications) that are used by H.323. What are the QOS/performance characteristics of audio, video, and data from the application point of view that is generated by audio codecs, video codecs, and data (T.120) applications? These QOS/performance characteristics come from the SOURCE codecs and data applications. Per transport independent H.323 specifications, an enduser express their QOS/performance requirements on end-to-end basis purely from application point of view irrespective of the transport network (e.g., IP, ATM, etc.). Moreover, H.323 is meant for the packet network, not for any circuit-switched network like PSTN or ISDN. Let us NOT go beyond this before we start debating transport layer QOS or service provider requirements. These are NOT the concern of H.323. H.323 is the transport independent application. H.323v2/v3/v4 has also provided mechanisms how RSVP and ATM QOS can be used for H.323 audio, video, and data. So, H.323 QOS that will be defined in H.323 Annex N MUST provide mapping for the backward compatibility. It is a requirement that MUST be met per the norm of ITU-T. So, what is left for mapping? Mapping is simply a by-product of the above requirement. Mapping is simply a table, nothing else. Did I miss anything? Best regards, Radhika R. Roy AT&T -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Thursday, August 10, 2000 10:19 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 QOS Radhika, Thanks for the input which I welcome as I will unfortunately not be present at Portland. Let me ask a few questions and make a few comments hopefully with the intent of opening up the debate. 1. I am not sure I understand your concept of a mapping table between the H.323 QOS and the transport layer QoS. My understanding is that QoS is on three levels: a) that specified from a service point of view between the user and service provider (e.g PSTN quality, conference quality etc) This is the domain of the speech experts and can be characterised by Listener Speech Quaklity (MOS), end to end delay, and absolute category rating, R. b) application specific parameters, (e.g. equipment delays, codec choice and performance, codec frame size, packetisation arrangements, jitter buffer design, overall packet loss etc.) Optimisation of all these will determine what can be delivered in a). c) transport parameters for a given choice of application parameters. This boils down only to three parameters as far as I cna see: tranport network delay, packet delay variation in the transport network and packet loss in the transport network. Again these parameters will determine the results in a) for a given choice of the parameters in b). These parameters are generic from the perspective of the transport network. i.e the transport network does not need to know the details of the application. So the sequence of cause and effect and control is: a) User requests QoS class from service provider, b) Service provider determines application specific parameters in conjunction with users equipment and other service providers, c) Service provider requests required delay, delay variation and packet loss from network provider. I see no need for mapping here. The only QoS info flows within the application are specific to the application and those between the application (service provider) and the transport network are generic. i.e. delay, jitter and packet loss. Have I missed something? 2. The issue of bit rate and media stream statistics I think need to be decoupled from QoS. These are specified to enable optimisation of resources within the transport network. They have no QoS significance from an application point of view. i.e the apllication does not care about the media stream bit rate and statistics but the transport network provider does as it eats up his resource. They may be used for policy enforcement however in the transport network so they do need to be agreed between service provider and network operator. i.e the network operator agrees to provide a given QoS level (delay, jitter, packet loss) provided the media properties are within an agreed profile (bit rate, flow statistics). 3. The next point is how can the service provider know the statistics of a particular VBR stream? These can only be specified over a large number of similar calls and will depend, for instance, on who is speaking, the nature of the speech interaction etc etc. They can only be measured not calculated. The service provider is in no better position to measure these than the transport network operator and, in fact, where no gateways are involved, may not be able to. On the other hand the class of signal would have to be signalled to the network operator for him to be able to distinguish which class a particular measurement belonged to. e.g voice/speech/data, codec type, conference, multicast etc. So I see no purpose in trying to exchange statistics between the service provider (application) and transport operator. I think peak bit rate is all that can be meaningfully excanged. The specification of media class is however perhaps worth exploring. 4. The controlled category has always puzzled me. I only see two possibilities. Either the requested QoS level is guaranteed (on a statistical basis e.g 95% of all connections over a specified period) or not guaranteed. Is your controlled category a way of saying guaranteed, not to 95% but to some lower figure? If you can't put a percentage on it then it seems it is plain and simple not guaranteed. Anything that is not guaranteed to some specified statistical level is best effort and you can't say anything more about it. So I only see two categories here. In summary, I think we need to do three things in Annex N. a) Figure out the QoS information to be exchanged within the Application between service providers and end users. This will go in H.225.0 and H.245. b) Figure out how we are going to signal QoS and media information between the application (service providers) and transport domains (IP or ATM networks etc). The info is basically delay, jitter, packet loss requirements and peak bit rate. We need a protocol for this. c) we need to work out the interactions between the application QoS signal flows and the application/transport signal flows. I don't think we need worry about how the transport network mechanisms assure the requested QoS paramerters. RSVP/Intserv, Diffserv, MPLS, ATM, over provisioning are all possibilities. Would welcome comments and views on the above. Mike Mike Buckley +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Thursday, August 10, 2000 10:15 PM Subject: H.323 QOS Hi, Mike and All: It is time to discuss about H.323 QOS. I believe that we have an agreement as follows: · H.323 QOS MUST be backward compatible to support RSVP and ATM QOS as it exists for H.323v2/v3/v4 · Like H.323 spec, the application level H.323 QOS MUST be independent of the transport layer QOS and should support all transport networks (e.g., IP, ATM) · A mapping table between the H.323 QOS and the transport layer QOS (e.g., IP QOS [DiffServ, RSVP, etc.], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, etc.]) should be provided. >From the H.323 multimedia application point of view, there are following performance parameters can be used to characterize the traffic characteristics: · Bitrate characteristics: Peak bit rate (PBR) or peak rate (PR), Sustained bit rate (SBR) or average rate (AR), minimum bit rate (MBR) or minimum rate (MR), and mean bust size (MBS) · Delay and loss characteristics: end-to-end delay (EED) or delay, end-to-end delay variation (EEDV) or delay variation (DV), and bit-error-rate (BER) or (packet) loss rate (LR) We can now form a table with all parameters as follows: Table 1: H.323 Multimedia Application Performance Matrix Audio (codecs)--- Video (codecs)--- Data (T.120) PBR/PR Yes/No/Value Yes/No/Value Yes/No/value SBR/AR Yes/No/Value Yes/No/Value Yes/No/value MBR/MR Yes/No/Value Yes/No/Value Yes/No/value MBS Yes/No/Value Yes/No/Value Yes/No/value EED/Delay Yes/No/Value Yes/No/Value Yes/No/value EEDV/DV Yes/No/Value Yes/No/Value Yes/No/value BER/LR Yes/No/Value Yes/No/Value Yes/No/value >From the above table we will have the opportunity to choose each parameter for each medium (audio, video, data) that makes sense from the application's and enduser's point of view. Again, these parameters can be specified as follows: · Guaranteed: The value specified for each parameter MUST be guaranteed. · Controlled: The value specified for each parameter MAY be satisfied as far as practicable (possibly with certain range), but definitely NOT guaranteed. · Best effort: No commitment will be made. Now each medium (e.g., audio, video, or data) will have different categories of performance matrix depending on its selection criteria and this can also be mapped to RSVP, ATM QOS, and others, if needed. Once we agree on this format, the next step is to create H.323 QOS signaling messages. This is my input for discussion in the upcoming Portland Q.13 meeting for H.323 QOS. I like to see the comments from other members as well. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

APC document number request
by Barry Aronson 11 Aug '00

11 Aug '00

Dear Mr. Okubo, Could you please allocate a document number for the following: Title: "Draft H.323 Annex I" Source: Editor Thanking you in advance. Sincerely yours, Barry Aronson Barry Aronson Toshiba Corporation 33 Lake Shore Ave. Beverly, MA 01915-1907 USA E-mail: baronson(a)ieee.org Voice: +1 978-232-3994 Fax: +1 978-232-9220 Video: H.320, H.323, and H.324 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0