Hi, Audet:

For the existing ATM QOS and RSVP in H.323, there should be the exact mapping (please see TD-57) because exact parameters are known. There should not be any place for ambiguity to provide the backward compatibility as a minimum. Per your suggestion, if needed, we can also extend our mapping in ATM beyond what H.323 Annex C currently does.

For DiffServ, the PHB parameters need to be known to provide the mappings. There are possibilities for ambiguity in DiffServ if the parameters are not well defined. For now, PHBs are yet to be defined clearly in the IETF. More importantly, there is no backward compatibility issue in H.323 for DiffServ. I am not worried about this for now. We may keep this as a place holder (please also see TD-57) for our future work.

Best regards, Radhika R. Roy AT&T

-----Original Message----- From: Francois Audet [SMTP:audet@NORTELNETWORKS.COM] Sent: Tuesday, February 22, 2000 2:35 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: H.323 Annex N draft

...

H.323 standard has already defined how the lower network layer QOS (e.g., RSVP [guaranteed, controlled, best effort], ATM QOS [CBR, rt-VBR, nrt-VBR, ABR, UBR]).

Now, if we define H.323 application layer QOS only without defining the mapping, this will not provide backward compatibility to the existing H.323 standard.

This is the concern.

So, the "scope" should include the "mapping" of the H.323 QOS to the lower network layer QOS.

I don't think we can define such a mapping. There are many ways to use ATM. The one we used in Annex C is based on CBR AAL5. AAL1 or AAL2 could be candidates. VBR is also something to consider. We alse did single channel adaptation. We could multiplex. There is no reason why we need to specify the ATM transport and associated QoS mechanism.

On the diffserv side, I am also not convinced that there is much to say since network operators are free to use diffserv in any way they see fit.