[Robustness] DDP Checkpointing

Terry L Anderson tla at lucent.com
Wed Apr 12 13:55:15 EDT 2000


Randy Stewart -

You described a "checkpointing" mechanism for DDP during last week's
robustness call but it is not in the current DDP draft.  However, you
have evidently thought about this some and stated (in private mail) that
you had built such mechanism on top of DDP using the SEND_TO_ALL
mechanism.  How would you envision something like this being done to
synch state for a pool of H.323 entities?  Would this be a application
level library that could be called from H.323 software at appropriate
checkpoint times?  Could you describe this checkpointing idea in some
more detail?

It would seem preferable to either break up state information into a
number of subsets (to avoid resending large amounts each time) or to
only send differences.  Since DDP gives reliable delivery to the other
members of the pool, perhaps only changes need be sent.  Did your trials
solve this problem.  Perhaps each call would be a separate subset.

One issue is how to solve reliable end-to-end delivery.  SCTP would
guarantee delivery to other end of connection but  the H.225 and H.245
protocols may pass through intermediate nodes (e.g., routing GKs).  If a
node fails after acknowledging the message but before sending it on,
end-to-end delivery fails and no live element knows.  Either we need far
end acknowledgement or backup elements must accept delivery
reponsibility once acknowledgement has been sent by its later failed
peer.  DDP would guarantee delivery but the recipient would have to
checkpoint this message before acknowledgement to guarantee that a peer
taking over whould know that there was an outstanding message that it
must deliver and receive acknowledgement for.  This mechanism would
require checkpoint after receipt of but before sending acknowledgement
of a message and again after receiving acknowledgement from its next
neighbor.  Does this seem reasonable?  Unless the amount of data sent in
such checkpointing is kept very small this would seem to add too much
network activity to be acceptible.


--
------------------------------------------------------------
Terry L Anderson              mailto:tla at lucent.com
Tel:908.582.7013   Fax:908.582.6729
Pager:800.759.8352 pin 1704572   1704572 at skytel.com
Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla


-------------- next part --------------
A non-text attachment was scrubbed...
Name: tla.vcf
Type: text/x-vcard
Size: 548 bytes
Desc: Card for Terry L Anderson
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000412/6c3b5afe/attachment-0003.vcf>


More information about the sg16-avd mailing list