Resolution:
Description:
============

Here are some high level rules of thumb which might help to decide which Protocol (TRDP or PGM) to use.

1). The first question to ask is: “is TRDP currently deployed?” (i.e., are you already using RV?).

2). If TRDP is not currently deployed on the LAN, one may as well go straight to using PGM since it will benefit from PGM-enabled network elements which are probably bound to be prevalent sooner or later.

3). If TRDP is not currently deployed but the customer wants to deploy TIBCO Rendezvous on operating systems others than UNIX, Windows 2000/XP or HP Tru64, they should be aware that PGM is PGM and TRDP is only supported on those operating systems. Therefore a TRDP deployment would be more appropriate.

4). If TRDP is currently deployed, considering the impact of transitioning to PGM, the second question to ask is: “am I going to benefit from PGM?”

5). In most cases current customers will probably not see much benefit from migrating to PGM since TRDP performs very similarly to PGM most of the time and migrating an already established TRDP deployment would require more effort than it is worth. For example, a TIBCO Rendezvous customer should not migrate to PGM just because “it’s an open protocol”.

6). If you have PGM-enabled network elements you could benefit from migrating to PGM.

7). You will not necessarily benefit from PGM because PGM-enabled network elements will only bring improvements to the retransmission of data. If the network is very clean and the number of dropped packets is very slow, PGM and PGM-enabled network elements will probably not bring any noticeable improvement over TRDP.

8). If the number of packets being dropped and the number of retransmissions is high then PGM could make a difference. PGM could make a difference in the following examples: packets being dropped by network elements, packet loss limited to some subnets. PGM would not make a difference in the case that some hosts are dropping packets. Of course, fixing the network to reduce the number of dropped packets may be a better solution than migrating to PGM. Measuring the amount of packet retransmissions, where and why the packets are being dropped (using the RVD’s HTTP administrative interface, or a package like Rvtrace) and compare this with the impact of migrating from TRDP to PGM should help the decision process. In order for PGM to be beneficial you need to have significant loss correlation (network elements dropping packets rather than hosts), have loss detection time spread be less than the round trip window or have your loss limited to one segment. If you don't have these conditions TRDP would be beneficial because it uses fewer packets. In order do decide if PGM would help or hurt you need to have a thorough understanding of the network topology, of when the loss occurs and where loss occurs.

9). If you do not have PGM-enabled network elements, then PGM will probably not bring any improvements over TRDP and given the fact that TRDP is already deployed and that there is an impact to migrating from TRDP to PGM, you should probably stick with TRDP. At least until the time when the network elements are PGM-enabled at which point the impact of migrating versus potential benefit to using PGM should be re-evaluated.

Environment:
===========
All Supported RV 7.x+ versions