Issue in H.323 robustness not addressed by SCTP/DDP
Hello,
We think that SCTP/DDP by itself is not a complete solution for robustness (see PROBLEM B below) and certain changes need to be made in the H.323 layer to achieve robustness. For the sake of clarity, we restate the issues we need to address in order to achieve robustness:
In the current H.323 specs, if the TCP connection for a H.323 call goes down, the call is lost. To overcome this problem, we need:
A. Fail over mechanism
Whenever an endpoint detects that the other side is down (e.g.: TCP connection failure/ no ACKs received in Annex E) the endpoint can save an active H.323 call, if it knows about a "recovery H.323 address".
The "recovery address" is the back-up address that the endpoint can use to re-establish a TCP connection (for TCP) or to resend Annex E data (UDP). From the endpoint's point of view, the "recovery address" represents a node that has enough information about the H.323 call to continue processing as if the failure had never occurred
The failure in the node could have been one of the following types:
1. Transport failure: e.g. failed NIC, congested network.
2. Node failure: e.g. the entire gatekeeper fail. In this case, we need a synchronization mechanism between the gatekeeper and its backup so the active calls can be saved.
B. Handle Call State Synchronization We need to make sure that both legs of a H.323 call are in sync. When an intermediate node (e.g. Gk) fails, messages from an endpoint can get lost. e.g.: Take the example of a lost RELEASE COMPLETE in the following scenario:
(CRASH) RELCOMPLETE EP2 <-------------- GK <------------ EP1
EP1 sends a RELCOMPLETE to EP2 via the GK. The GK crashes, before forwarding the RELCOMPLETE from EP1 to EP2. As a result EP1 thinks the call is released, while as the EP2 thinks the call is up.
As Paul has pointed out: several H.245 messages are problematic-- especially those related to conferencing, such as chair control, terminal join/left, terminal you are seeing, etc. UserInputIndication and any other "indication" message that does not require a response is an issue.
POSSIBLE SOLUTION(s): ---------------------
Solution to Problem A: ---------------------- This problem can be solved using SCTP/DDP or modifying Annex E to include alternate addresses.
Solution to PROBLEM B: ----------------------
This problem cannot be solved using SCTP/DDP as it is inherent in the H.323 protocol. If we take the same example as above:
(CRASH) RELCOMPLETE EP2 <-------------- GK <------------ EP1 (SCTP/DDP) (SCTP/DDP) (SCTP/DDP)
what happens if the GK fails just after its SCTP layer finished sending an SCTP-ACK for the RELCOMPLETE message to EP1. EP1 receives the SCTP-ACK and therefore considers the call released but EP2 never receives the RELCOMPLETE message. It is important to note here that "checkpointing" in the H.323 layer of the GK will not help since the ACK at the SCTP level is generated before RELCOMPLETE message is delivered to the H.323 layer of the GK.
So we can solve the problem by having an "END-to-END acknowledgement mechanism" to make sure that EP1 and EP2 are in sync even when the intermediate node fails.
One approach as suggested by Paul is to modify Annex E to have end-to-end acknowledgement. We want to point out that actually this is a H.323 layer problem. By introducing end-to-end ack into Annex E, we will be trying to solve a protocol layer problem by making modifications in the transport layer mechanisms. The problem of synchronization comes from the fact that the H.323 layer does not have an ACK for every message that is sent out.
Alternatively, if we introduce an ACK packet for every H.323 message that currently has no ACK (e.g: H.245 commands/indications or H.225 RELEASE COMPLETE), we can address the problem cleanly. This ACK message will be supported only by the nodes that support robustness. Unlike the Annex-E approach, this approach is independent of the transport layer protocol layer below H.323, and can also be applied to SCTP/DDP.
Comments are welcome on this issue.
Regards, Archana
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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.
I want to change direction just a bit. I have been pushing for Annex E, but I got resistance: people want to be able to use TCP or another transport. I understand that desire. People have also expressed concerns that we're not clearly separating the transport and application layers. To some extent, that is true. However, I believe that with Annex E, we can draw that line a little clear-- but it means modifications to Annex E. Another issue is that some people have disagreed with modifying Annex E :-)
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.
When robustness is not available end-to-end, this layer in the middle would send and receive messages as normal. However, when robustness is available end to end, it would "get in the middle" and transparently handle robustness issues for the H.323 application.
The goal, of course, is to minimize the application changes and to minimize changes to the transports below.
Certainly, this is a shift from my previous thinking, but it represents an attempt to address all of the concerns people have raised. What is your opinion on this type of approach?
Paul
----- Original Message ----- From: "Archana Nehru" archie@trillium.com To: 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; "'Paul E. Jones'" paul.jones@ties.itu.ch Sent: Tuesday, April 25, 2000 9:19 PM Subject: Issue in H.323 robustness not addressed by SCTP/DDP
Hello,
We think that SCTP/DDP by itself is not a complete solution for robustness (see PROBLEM B below) and certain changes need to be made in the H.323 layer to achieve robustness. For the sake of clarity, we restate the issues we need to address in order to achieve robustness:
In the current H.323 specs, if the TCP connection for a H.323 call goes down, the call is lost. To overcome this problem, we need:
A. Fail over mechanism
Whenever an endpoint detects that the other side is down (e.g.: TCP connection failure/ no ACKs received in Annex E) the endpoint can save an active H.323 call, if it knows about a "recovery H.323 address".
The "recovery address" is the back-up address that the endpoint can use to re-establish a TCP connection (for TCP) or to resend Annex E data (UDP). From the endpoint's point of view, the "recovery address" represents a node that has enough information about the H.323 call to continue processing as if the failure had never occurred
The failure in the node could have been one of the following types:
Transport failure: e.g. failed NIC, congested network.
Node failure: e.g. the entire gatekeeper fail. In this case, we
need a synchronization mechanism between the gatekeeper and its backup so the active calls can be saved.
B. Handle Call State Synchronization We need to make sure that both legs of a H.323 call are in sync. When an intermediate node (e.g. Gk) fails, messages from an endpoint can get lost. e.g.: Take the example of a lost RELEASE COMPLETE in the following scenario:
(CRASH) RELCOMPLETE EP2 <-------------- GK <------------ EP1EP1 sends a RELCOMPLETE to EP2 via the GK. The GK crashes, before forwarding the RELCOMPLETE from EP1 to EP2. As a result EP1 thinks the call is released, while as the EP2 thinks the call is up.
As Paul has pointed out: several H.245 messages are problematic-- especially those related to conferencing, such as chair control, terminal join/left, terminal you are seeing, etc. UserInputIndication and any other "indication" message that does not require a response is an issue.
POSSIBLE SOLUTION(s):
Solution to Problem A:
This problem can be solved using SCTP/DDP or modifying Annex E to include alternate addresses.
Solution to PROBLEM B:
This problem cannot be solved using SCTP/DDP as it is inherent in the H.323 protocol. If we take the same example as above:
(CRASH) RELCOMPLETE EP2 <-------------- GK <------------ EP1 (SCTP/DDP) (SCTP/DDP) (SCTP/DDP)what happens if the GK fails just after its SCTP layer finished sending an SCTP-ACK for the RELCOMPLETE message to EP1. EP1 receives the SCTP-ACK and therefore considers the call released but EP2 never receives the RELCOMPLETE message. It is important to note here that "checkpointing" in the H.323 layer of the GK will not help since the ACK at the SCTP level is generated before RELCOMPLETE message is delivered to the H.323 layer of the GK.
So we can solve the problem by having an "END-to-END acknowledgement mechanism" to make sure that EP1 and EP2 are in sync even when the intermediate node fails.
One approach as suggested by Paul is to modify Annex E to have end-to-end acknowledgement. We want to point out that actually this is a H.323 layer problem. By introducing end-to-end ack into Annex E, we will be trying to solve a protocol layer problem by making modifications in the transport layer mechanisms. The problem of synchronization comes from the fact that the H.323 layer does not have an ACK for every message that is sent out.
Alternatively, if we introduce an ACK packet for every H.323 message that currently has no ACK (e.g: H.245 commands/indications or H.225 RELEASE COMPLETE), we can address the problem cleanly. This ACK message will be supported only by the nodes that support robustness. Unlike the Annex-E approach, this approach is independent of the transport layer protocol layer below H.323, and can also be applied to SCTP/DDP.
Comments are welcome on this issue.
Regards, Archana
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
See my comments below...
-Qiaobing
"Paul E. Jones" wrote:
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.
I want to change direction just a bit. I have been pushing for Annex E, but I got resistance: people want to be able to use TCP or another transport. I understand that desire. People have also expressed concerns that we're not clearly separating the transport and application layers. To some extent, that is true. However, I believe that with Annex E, we can draw that line a little clear-- but it means modifications to Annex E. Another issue is that some people have disagreed with modifying Annex E :-)
I'd count myself as one of those disagreeing with modifying Annex E. With the proposed end-to-end ack and Annex E level keeping call state changes as we discussed in the last two robustness conf. calls, the line btw transport and application will be further blurred.
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.
When robustness is not available end-to-end, this layer in the middle would send and receive messages as normal. However, when robustness is available end to end, it would "get in the middle" and transparently handle robustness issues for the H.323 application.
The goal, of course, is to minimize the application changes and to minimize changes to the transports below.
DDP is exactly a session layer protocol btw the transport and the application. It is designed to perform all the functions you just described and more. You get network level redundancy with SCTP replacing TCP (multi-homing and fast fail-over) and node level redundancy from DDP (transparent server pooling at GKs). All this can be achieved with little change to H.323 protocol. Randy Stewart and myself at Motorola are going to have a contribution to details this architecture at the coming Osaka SG16 meeting this May.
Certainly, this is a shift from my previous thinking, but it represents an attempt to address all of the concerns people have raised. What is your opinion on this type of approach?
Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Qiaobing,
It sounds like DDP might serve most of the functions we need. However, as Archana has pointed out, an ACK is needed end to end for certain messages and I believe an issue still exists with DDP.
Also, I was not proposing that endpoints have to share call state information with other endpoints-- I have not been at all concerned with checkpointing. This might be quite valuable between alternate gatekeepers (or other redundant entities), but I see this as a different issue to "keeping a call alive".
Specifically, I see two issues we need to solve with robustness: 1) Preventing the loss of a call-- even when a signaling point fails 2) Preventing the loss of call billing information
(1) is my primary focus and I believe that (2) can either be considered as a secondary issue or even an "implementation" issue. Actually, V4 introduces much of the information we need in order to bill for calls, as it can convey the start/end time of a call in the DRQ. If additional information is necessary, the DRQ might be the logical place to put that to address (2).
(Personally, I'd be more than happy to have some call details lost-- especially after I got my last AT&T bill where I was billed at 80.6 cents per minute to call from home to Canada on one of our conference calls. I thought I was going to fall over dead when I saw that bill! And there was no hope arguing with the AT&T customer service rep over it, either. I actually asked for a published list of rates so I can make sure I don't do something like that again. There is no published list, I was told! Hmmm....)
Paul
----- Original Message ----- From: "Qiaobing Xie" xieqb@CIG.MOT.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Wednesday, April 26, 2000 4:12 PM Subject: Re: Issue in H.323 robustness not addressed by SCTP/DDP
See my comments below...
-Qiaobing
"Paul E. Jones" wrote:
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.
I want to change direction just a bit. I have been pushing for Annex E,
but
I got resistance: people want to be able to use TCP or another
transport. I
understand that desire. People have also expressed concerns that we're
not
clearly separating the transport and application layers. To some
extent,
that is true. However, I believe that with Annex E, we can draw that
line a
little clear-- but it means modifications to Annex E. Another issue is
that
some people have disagreed with modifying Annex E :-)
I'd count myself as one of those disagreeing with modifying Annex E. With the proposed end-to-end ack and Annex E level keeping call state changes as we discussed in the last two robustness conf. calls, the line btw transport and application will be further blurred.
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.
When robustness is not available end-to-end, this layer in the middle
would
send and receive messages as normal. However, when robustness is
available
end to end, it would "get in the middle" and transparently handle
robustness
issues for the H.323 application.
The goal, of course, is to minimize the application changes and to
minimize
changes to the transports below.
DDP is exactly a session layer protocol btw the transport and the application. It is designed to perform all the functions you just described and more. You get network level redundancy with SCTP replacing TCP (multi-homing and fast fail-over) and node level redundancy from DDP (transparent server pooling at GKs). All this can be achieved with little change to H.323 protocol. Randy Stewart and myself at Motorola are going to have a contribution to details this architecture at the coming Osaka SG16 meeting this May.
Certainly, this is a shift from my previous thinking, but it represents
an
attempt to address all of the concerns people have raised. What is your opinion on this type of approach?
Paul
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Archana,
One thing you might have missed is that the DDP/SCTP fault-tolerance model is designed to provide robustness to the application in a *transparent* fashion. The state synchronization issue (your PROBLEM B) is a no-issue to DDP/SCTP model. In our model, a back-up GK will automatically kick in and continue forwarding the RELCOMPLETE to EP2, without either EP even noticing that the failure ever happened at all! There is NO application involvment required in this scenario.
-Qiaobing
Archana Nehru wrote:
Hello,
We think that SCTP/DDP by itself is not a complete solution for robustness (see PROBLEM B below) and certain changes need to be made in the H.323 layer to achieve robustness. For the sake of clarity, we restate the issues we need to address in order to achieve robustness:
In the current H.323 specs, if the TCP connection for a H.323 call goes down, the call is lost. To overcome this problem, we need:
A. Fail over mechanism
Whenever an endpoint detects that the other side is down (e.g.: TCP connection failure/ no ACKs received in Annex E) the endpoint can save an active H.323 call, if it knows about a "recovery H.323 address".
The "recovery address" is the back-up address that the endpoint can use to re-establish a TCP connection (for TCP) or to resend Annex E data (UDP). From the endpoint's point of view, the "recovery address" represents a node that has enough information about the H.323 call to continue processing as if the failure had never occurred
The failure in the node could have been one of the following types:
Transport failure: e.g. failed NIC, congested network.
Node failure: e.g. the entire gatekeeper fail. In this case, we
need a synchronization mechanism between the gatekeeper and its backup so the active calls can be saved.
B. Handle Call State Synchronization We need to make sure that both legs of a H.323 call are in sync. When an intermediate node (e.g. Gk) fails, messages from an endpoint can get lost. e.g.: Take the example of a lost RELEASE COMPLETE in the following scenario:
(CRASH) RELCOMPLETE EP2 <-------------- GK <------------ EP1EP1 sends a RELCOMPLETE to EP2 via the GK. The GK crashes, before forwarding the RELCOMPLETE from EP1 to EP2. As a result EP1 thinks the call is released, while as the EP2 thinks the call is up.
As Paul has pointed out: several H.245 messages are problematic-- especially those related to conferencing, such as chair control, terminal join/left, terminal you are seeing, etc. UserInputIndication and any other "indication" message that does not require a response is an issue.
POSSIBLE SOLUTION(s):
Solution to Problem A:
This problem can be solved using SCTP/DDP or modifying Annex E to include alternate addresses.
Solution to PROBLEM B:
This problem cannot be solved using SCTP/DDP as it is inherent in the H.323 protocol. If we take the same example as above:
(CRASH) RELCOMPLETE EP2 <-------------- GK <------------ EP1 (SCTP/DDP) (SCTP/DDP) (SCTP/DDP)what happens if the GK fails just after its SCTP layer finished sending an SCTP-ACK for the RELCOMPLETE message to EP1. EP1 receives the SCTP-ACK and therefore considers the call released but EP2 never receives the RELCOMPLETE message. It is important to note here that "checkpointing" in the H.323 layer of the GK will not help since the ACK at the SCTP level is generated before RELCOMPLETE message is delivered to the H.323 layer of the GK.
So we can solve the problem by having an "END-to-END acknowledgement mechanism" to make sure that EP1 and EP2 are in sync even when the intermediate node fails.
One approach as suggested by Paul is to modify Annex E to have end-to-end acknowledgement. We want to point out that actually this is a H.323 layer problem. By introducing end-to-end ack into Annex E, we will be trying to solve a protocol layer problem by making modifications in the transport layer mechanisms. The problem of synchronization comes from the fact that the H.323 layer does not have an ACK for every message that is sent out.
Alternatively, if we introduce an ACK packet for every H.323 message that currently has no ACK (e.g: H.245 commands/indications or H.225 RELEASE COMPLETE), we can address the problem cleanly. This ACK message will be supported only by the nodes that support robustness. Unlike the Annex-E approach, this approach is independent of the transport layer protocol layer below H.323, and can also be applied to SCTP/DDP.
Comments are welcome on this issue.
Regards, Archana
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (3)
-
Archana Nehru -
Paul E. Jones -
Qiaobing Xie