Re: about wireshark SRT statistics confusion

[Bo Xu <xubo.leo () gmail com>]

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 () gmail com> 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.
>
>
> On Wed, Jun 2, 2010 at 8:31 AM, Bo Xu <xubo.leo () gmail com> wrote:
>
> > Hello Ronnie
> >
> >    PFA :)
> >
> > BR
> > Xu Bo
> >
> >   On Wed, Jun 2, 2010 at 11:19 AM, ronnie sahlberg <
> > ronniesahlberg () gmail com> wrote:
> >
> > > That looks like a bug in the Diameter protocol SRT.
> > >
> > > Most likely it can not handle if the transaction id is "reused" so it
> > > ends up matching a reply from one transaction with a request that
> > > happened for a different transaction much later.
> > >
> > >
> > > Do you have an example trace where this happens ?
> > > If so I can fix that issue.
> > >
> > >
> > > regards
> > > ronnie sahlberg
> > >
> > >
> > > On Wed, Jun 2, 2010 at 12:47 PM, Bo Xu <xubo.leo () gmail com> wrote:
> > > > Hello Guys ,
> > > >
> > > >   SRT statistic is a really fantastic function of Wireshark .  I am
> > > doing
> > > > the Diameter SRT.  But the Output is really confusion
> > > >
> > > >   For this pcap file <nocaaa.tcpdump.201006021007.pcap> , i got such
> > > result
> > > > :
> > > > index    procedure         calls       MinSRT              MaxSRT
> > > AvgSRT
> > > > 1          Credit-control    3132       -123.-68142        0.17384
> > > > 58897650236.50013
> > > >
> > > > It looks very strange about MinSRT/AvgSRT value , and btw : the unit is
> > > > second ?
> > > > My Wireshark version is :Version 1.2.8 (SVN Rev 32676)
> > > >
> > > > BR
> > > > Xu Bo
> > > ___________________________________________________________________________
> > > > Sent via:    Wireshark-users mailing list <
> > > wireshark-users () wireshark org>
> > > > Archives:    http://www.wireshark.org/lists/wireshark-users
> > > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > > >             mailto:wireshark-users-request () wireshark org
> > > ?subject=unsubscribe
> > > >
> > >
> > > ___________________________________________________________________________
> > > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org
> > > >
> > > Archives:    http://www.wireshark.org/lists/wireshark-users
> > > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> > >             mailto:wireshark-users-request () wireshark org
> > > ?subject=unsubscribe
> >
> >
> >
> > ___________________________________________________________________________
> > Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> > Archives:    http://www.wireshark.org/lists/wireshark-users
> > Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
> >             mailto:wireshark-users-request () wireshark org
> > ?subject=unsubscribe
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe

Attachment: ismpdump.rar
Description:

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe