Hello Ronnie ,
I feel very upset that i can't do the SRT statistic because this field is wrong .
But I checked another trace file , the hop-to-hop looks fine , but still , the result looks strange . I have attached this file.
Can we use another approach to do the Diameter SRT , for example , Sesssion ID ? of course , CER ,DWR will use another approach :)
BR
Xu Bo
On Wed, Jun 2, 2010 at 1:51 PM, Abhik Sarkar
<sarkar.abhik@xxxxxxxxx> wrote:
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.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
Attachment:
ismpdump.rar
Description: Binary data
