Hi Xu Bo,
While I agree that the SRT (and request response tracking in the Diameter dissector can be improved, for example to detect duplicates), I think there is something wrong with the requests in the capture.
When I wrote these two features, I had based the request tracking on the hop-by-hop identifier based on this description in the Diameter Base Protocol RFC (
http://www.faqs.org/rfcs/rfc3588.html).
Hop-by-Hop Identifier
The Hop-by-Hop Identifier is an unsigned 32-bit integer field (in
network byte order) and aids in matching requests and replies.
The sender MUST ensure that the Hop-by-Hop identifier in a request
is unique on a given connection at any given time, and MAY attempt
to ensure that the number is unique across reboots. The sender of
an Answer message MUST ensure that the Hop-by-Hop Identifier field
contains the same value that was found in the corresponding
request. The Hop-by-Hop identifier is normally a monotonically
increasing number, whose start value was randomly generated. An
answer message that is received with an unknown Hop-by-Hop
Identifier MUST be discarded.
However, most of the requests and responses in the trace seem to have the same Hop-By-Hop Identifier, which looks a bit strange to me and is what is causing the problem.
The hop-by-hop identifier seemed to be the best field to choose, in addition to the TCP
endpoints of course, to measure SRT because the end-to-end identifier
can be unique across multiple hops if proxies are involved and one would
rather measure (in my opinion) SRT between two adjacent points to get a
true picture instead of across multiple hops (if the trace is taken on a machine which sees both legs).
I am sure someone else will have comments as well.
Regards,
Abhik.
