Re: Issue in H.323 robustness not addressed by SCTP/DDP
Paul,
Thanks for replying. Please seem my comments below:
-Archana
The ACK packet certainly follows the line of thinking that I had. However, one issue with implementing this approach is that there are no fields in H.323 to provide a "sequence number". I suppose this could easily be overcome.
Well, if you are concerned about retransmissions, may be the endpoints could just look at the "callId" in the ACK, look at the "session-state" and conclude that the packet is just a retransmission.
Here's a thought: how about introducing a new session layer between the transport and below the H.323 application? This session layer would actually encode messages in a special format for transmission on the wire. For example, for TCP, we could modify the TPKT header and the payload to carry not only the H.323 message, but also sequencing data and other information. We can allow fail-over addresses to be carried in this layer and allow this layer to completely handle connection recovery.
Well let me put it this way. What do we gain by doing this?. Wouldnot it be simpler to modify H.323 procedures by introducing an ACK message itself (probably use some modified FACILITY?) and do it in a clean manner. Anyway, all we need in H.323 is an ACK from the peer, if the requester indicates that it needs an ACK. This could be decided as part of the connection set up procedure itself..so an endpoint would know before hand whether "a particular" node supports robustness or not. The message we decide to use will be optional and existing applications would just have to learn to ignore it, if they dont want to support robustness. That is not a big change..is it?..
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Archana,
Putting the list of alternate signaling addresses, indicator that robustness is supported, sequencing value, and the procedure to handle robustness issues within the H.323 application is certainly easy to do. The only reason for separating the two is that people are increasing concerned with the complexity of H.323. Drawing a clear separation between the call signaling layer, the robustness layer, and the application layer may make some people feel more comfortable.
On the other hand, it sounds like you would much rather have that complexity in the application layer. This is certainly something we could do. There are also some advantages to this approach as well. In particular, by allowing the application to drive the robustness, we can failover from a device that supports robustness to a device that does not. (Of course, once this fail-over occurs, we can't fail-over any more and there may be issues with handling what appear to be duplicate messages in such cases, since the sequencing value will be lost in such a switch-over in most cases.)
I would certainly not oppose this direction if others agreed with adding this to the application layer. As far as signaling goes, it's pretty minimal, although actually re-establishing connections will involve more work-- regardless of where that happens. For example, if TCP is the transport and a message is transmitted, the application layer must now retain a copy of the transmitted message until an ACK is received. Some may prefer to move that into a separate layer, but I am really open to this-- I'll support it wherever we put it.
Paul
----- Original Message ----- From: "Archana Nehru" archie@trillium.com To: "'Paul E. Jones'" paul.jones@ties.itu.ch; "Archana Nehru" archie@trillium.com; ITU-SG16@mailbag.cps.intel.com Cc: "Mahesh Bhan" mbhan@trillium.com; "Chinmay Padhye" chinmay@trillium.com; "Archana Nehru" archie@trillium.com; "Tim Chen" scc@trillium.com; "Jill Caugherty" jcaugher@cisco.com; "Rich K. Bowen" rkbowen@cisco.com Sent: Wednesday, April 26, 2000 6:33 PM Subject: RE: Issue in H.323 robustness not addressed by SCTP/DDP
Paul,
Thanks for replying. Please seem my comments below:
-Archana
The ACK packet certainly follows the line of thinking that I had. However, one issue with implementing this approach is that there are no fields in H.323 to provide a "sequence number". I suppose this could easily be overcome.
Well, if you are concerned about retransmissions, may be the endpoints
could
just look at the "callId" in the ACK, look at the "session-state" and conclude that the packet is just a retransmission.
Here's a thought: how about introducing a new session layer between the transport and below the H.323 application? This session layer would actually encode messages in a special format for transmission on the wire. For example, for TCP, we could modify the TPKT header and the payload to carry not only the H.323 message, but also sequencing data and other information. We can allow fail-over addresses to be carried in this layer and allow this layer to completely handle connection recovery.
Well let me put it this way. What do we gain by doing this?. Wouldnot it
be
simpler to modify H.323 procedures by introducing an ACK message itself (probably use some modified FACILITY?) and do it in a clean manner.
Anyway,
all we need in H.323 is an ACK from the peer, if the requester indicates that it needs an ACK. This could be decided as part of the connection set
up
procedure itself..so an endpoint would know before hand whether "a particular" node supports robustness or not. The message we decide to use will be optional and existing applications would just have to learn to ignore it, if they dont want to support robustness. That is not a big change..is it?..
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (2)
-
Archana Nehru -
Paul E. Jones