[Robustness] End to End Acknowledgement Contribution
Paul E. Jones
paul.jones at ties.itu.ch
Tue May 9 01:21:15 EDT 2000
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?) ;-)
----- Original Message -----
From: "Tim Chen" <scc at trillium.com>
To: "'Mailing list for parties associated with ITU-T Study Group 16'"
<ITU-SG16 at mailbag.cps.intel.com>
Cc: "Chinmay Padhye" <chinmay at trillium.com>; "Srini Beereddy"
<srini at trillium.com>; "Mahesh Bhan" <mbhan at trillium.com>; "Archana Nehru"
<archie at trillium.com>; "Manoj Paul" <mpaul at trillium.com>; "'Paul E. Jones'"
<paul.jones at ties.itu.ch>
Sent: Monday, May 08, 2000 11:37 PM
Subject: [Robustness] End to End Acknowledgement Contribution
> 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.
> Tim Chen
> Tim Chen Trillium Digital Systems, Inc.
> Phone: +1 310 442 9222 Fax: +1 310 442 1162
> email: tim at trillium.com http://www.trillium.com
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd