Revision history  [back]

Hi,

Sorry that the TRANSUM documentation is not accessible at the moment. I'll try to get it uploaded somewhere else and make the link available.

The client, intermediate and server settings change the way that TRANSUM accounts for the time taken for retransmissions. There are several scenarios, but I'll give you two to explain.

With the Client setting and a capture on or close to the client, if we transmit an HTTP request and then need to retransmit it, TRANSUM assigns the retransmission additional time to Request Spread. This is reasonable if we assume that the retransmission was needed because the first instance of the request did not make it to the server. Importantly, we don't assign the retransmission time to Service Time.

Now consider the same scenario but where we are capturing on or adjacent to the server. If we see both the original request packet and the retransmitted request, with the Client setting we would include the retransmission time as request spread. However, it would be more reasonable to assume that the service saw the first request and either there was a prolonged delay in the ACK or the ACK got lost, resulting in the retransmission. Whatever the reason, the Service Time should be judged to start from the receipt of the first instance of the request packet, and so Service Time is increased, rather than the Request Spread. This is the way TRANSUM behaves if you use the Service setting.

The inverse of the above is used for responses from the service:

• With the Service setting, time for retransmitted responses seen at the service is allocated to Response Spread
• With the Client setting, time for retransmitted responses seen at the client is ignored

If you choose the intermediate setting, all retransmission time is allocated to Request or Response spread depending on the direction of data flow.

There are many reasons why this treatment is not perfect, but it's a reasonable compromise.

Best regards...Paul