Tim,

Do you not believe that by adding a sequence number to various H.245 messages will unnecessarily increase the complexity of the H.323 application? If you look at what you have proposed, it puts a much heaver burden on the application logic-- new timers, "re-tries" (possibly), etc. The application will have to handle connection tear-down and re-establishment-- and the procedure for re-establishment is not clear.

What happens if a routing entity in the network re-routes the call and now there is no longer end-to-end robustness? Do you care or do you just continue thinking that such robustness is in place?

What about re-transmission of H.225.0 messages that might be used for tunneling or performing some other type of service (e.g., Annex L services)? Do those not also need acknowledgement?

Would it not be cleaner to have a separate layer between the application and the transport to handle these issues? I've suggested that before-- essentially, we could have a robustness wrapper around H.323 messages, which isolates the application from the underlying complexity. I realize that one concern with such a "generic" approach is that there may be more messages on the wire. However, I believe we have to give somewhere and reach a compromise between application complexity and signaling noise.

Of course, I say that and then you can immediate say that "we're only requiring ACKs to a small set of messages", so the complexity is minimized. That's true, but it does require additional state and timers, re-tries, and connection re-establishment logic in the application layer.

Some were arguing for a "bulletin board" approach. I missed the last meeting, so I missed much of that discussion. From the e-mail, I gather that the intent is that for every message that arrives at a signaling point, it will send that message to a peer before forwarding in on. I need some of the gaps filled in, but it seems like that scheme will result in no fewer messages, but I can see some benefits, because the communication between the two signaling points could done in such ways as to prevent "flooding" the network with excess signaling-- there are several proprietary communication mechanisms that can be employed for this task.

I don't know if the "bulletin board" approach is better or worse, but hopefully we can try to cover all of these issues tomorrow.

BTW, thanks for writing this document-- this was very much needed as a starting point for discussion. I know that my e-mail doesn't seem to be terribly friendly to the idea, but that was not my intent. My e-mails are often terse and it's getting late (or early?) ;-)

Paul

----- Original Message ----- From: "Tim Chen" scc@trillium.com To: "'Mailing list for parties associated with ITU-T Study Group 16'" ITU-SG16@mailbag.cps.intel.com Cc: "Chinmay Padhye" chinmay@trillium.com; "Srini Beereddy" srini@trillium.com; "Mahesh Bhan" mbhan@trillium.com; "Archana Nehru" archie@trillium.com; "Manoj Paul" mpaul@trillium.com; "'Paul E. Jones'" paul.jones@ties.itu.ch Sent: Monday, May 08, 2000 11:37 PM Subject: [Robustness] End to End Acknowledgement Contribution

Hi,

Please find attached our write-up on end to end acknowledgement. As discussed in our last Robustness Group Conference Call, adding these acknowledgements at H.323 level to messages which invoke no responses will prevent call state mismatch should these messages be lost.

We hope the group will give some response during Tuesday's conference call. The list of messages that need to be acknowledged shown in the document is preliminary and we would welcome comments and suggestions.

Regards, Tim Chen

---

Tim Chen Trillium Digital Systems, Inc. Phone: +1 310 442 9222 Fax: +1 310 442 1162 email: tim@trillium.com http://www.trillium.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com