["ronnie sahlberg" <ronniesahlberg@xxxxxxxxx>]

PSH is a flag in the TCP layer.
It essentially means : dont do any delays on this packet and send back an ACK immediately.
This is different from normal tcp segments that can be and often are deliberately delayed and queued in both the transmitter and the receiver for potentially hundreds of miliseconds and also that there can be a delay before a host will acknowledge teh data.

These artificial delays will make any rtt measurement unreliable.

The good thing though is that special packets will have the PSH bit set and these packets must be immediately delivered and immediately acknowledged which makes these packets a good choice  when picking which packets to use for rtt measurement.
this is also why all implementations of tcp use these PSH packets for these measurements and why rfc2988 describes these should be used.

On 9/12/06, Andreina Toro <andreina.toro@xxxxxxxxx> wrote:

Hi ronnie, thanks for helping me...

 

I´m a little lost.. In general I undestand what you mean.. the total latency A <-> B will be the sum of the latencies. But what does it mean PSH when you said...  TCP PSH to A? 

 

Another thing, I´ll be taking the measures somewhere on the path between A and B but I´m not sure if I can find  TCP sessions for both A and B in the trace?... Here I attach you a file with a picture of where I´ll be measuring, if you could take a look I´ll be thankfull.. I´ll be listening to everything that goes trhough and I will only save to a file VoIP traces, I`ll filter them with RTP Streams. How can I measure the latency as you said? because wireshark already gives me the % of packet loss, jitter, etc, but not latency.

 

Thanks so much,

Regards,

Andreina

 

On 9/8/06, ronnie sahlberg <ronniesahlberg@xxxxxxxxx > wrote:

while you can not find the end to end latency between the peers A and
B by looking at RTP traffic there may be other ways to measure it.

IF the analyzer is somewhere on the path between A and B and IF you
can also find  TCP sessions for both A and B in the trace you can :

Measure the time between a TCP PSH to A  and the time until you find
an ACK coming back from A  for the data of that PSH segment.
That will give you the latency between the sniffer and A

Do the same for a TCP session for B which gives you the latency
between the sniffer and B.


With some luck the latency A <-> B will be the sum of the latencies
you measured above.


On 9/8/06, Andreina Toro < andreina.toro@xxxxxxxxx> wrote:
> Hi Miha, now I understand why only analyzing RTP streams I can`t get the
> information I need.
>
> Thank you to all for your time.. it´s amaizing your dedication and good will
> helping me!..
>
> Regards,
>
> Andreina (a venezuelan student)
>
>
>
>
> On 9/7/06, Miha Jemec < m.jemec@xxxxxxxxxxx> wrote:
> >
> >
> > > " looking at the
> > > packets you could see a delay of 100ms, which is long but
> > > acceptable"....where in the RTP Streams window you look at the
> > > delay? The only parameters I see are:
> > >       * Src IP addr,Src port,Dest IP addr,Dest
> > >         port,SSRC,Payload,Packets,Lost,Max Delta (ms),Max Jitter
> > >         (ms),Mean Jitter (ms),Pb?,
> >
> > Hi Angelina,
> >
> > wireshark can not measure end-to-end delay, nor the
> > end-to-capture_destination delay. At least not using the RTP protocol or
> > better said, this information is not provided inside RTP protocol.
> >
> > The timestamp inside RTP header increments monotonically, that is true,
> > but this is the information for the receiver side, to know when a sample
> > should be played. This is not (absolute!) time reference.
> >
> > If you take a look inside whole RTP packet you can see, there is no
> > other time information. Nor in the RTP header nor in the ETH/IP/UDP
> > headers. It means you can not know when this packet was sent on the
> > wire. And you can not know when the voice sample was made. And even if
> > this information would be there, would you trust it? How would you know
> > that the clock inside VoIP transmitter and your capture device are well
> > synchronized? Don't forget, we are talking about milliseconds here.
> >
> > Of course there are procedures how to measure ONE WAY END TO END DELAY
> > and all include devices on both sides which are time synchronized (using
> > GPS clock f.e.) but using only wireshark and RTP protocol this is not
> > possible.
> >
> > A simple demonstration of this problem would be:
> >
> > I can send you over the Internet an RTP stream from my VoIP phone or PC.
> > Speech coded with g.711 and 20ms packetization. Let's say, the network
> > will work perfectly today and no jitter will be inserted. It means you
> > will receive one packet every 20ms. No jitter, what about the delay?
> >
> > Now, where do you come from? I'm from Europe, if you live somewhere near
> > me, the delay (the difference in the time between my PC will put a
> > packet on the link and the time you will receive this packet) will be
> > relatively small, let's say 50ms. What about if you come from the other
> > part of the world. Just because of the distance the propagation time
> > will increase and the delay will be higher. In both cases, if you
> > capture this RTP stream and analyze it, you will get exactly the same
> > values inside RTP stream analysis. And if I put a special device after
> > my phone, which will delay every packet for exact 3s before sending it
> > over to you, you will still get exactly the same results. And in all
> > three cases, there is now way for you to know, how much time a packet
> > needed from me to you.
> >
> > I hope this clarifies why only analyzing RTP streams can not give you
> > the information you want. As some already said, there are other ways how
> > to get it.
> >
> > Regards, Miha
> >
> > > Now I understand what end-to-end means, so I can calculate an average
> > > for maximum delay looking at the packages depending on the jitter
> > > buffer in order to get a delay<150ms?, would  that be a good estimate?
> > >
> > > thanks!
> > > Regards,
> > > Andreina
> > >
> > >
> > > On 9/6/06, Jaap Keuter < jaap.keuter@xxxxxxxxx> wrote:
> > >         Hi,
> > >
> > >         "End-to-End" means from the speech source (mic) to the speech
> > >         destination
> > >         (loudspeaker). Now Wireshark can capture half way in that
> > >         path, so it
> > >         cannot predict how the destination endpoint will deliver the
> > >         speech to the
> > >         listner. This is due to the fact that the destination endpoint
> > >         has a
> > >         jitter buffer which delays playout of the media stream. This
> > >         is internal
> > >         to the destination endpoint and not known to Wireshark. So
> > >         looking at the
> > >         packets you could see a delay of 100ms, which is long but
> > >         acceptable. But
> > >         if the jitter buffer is another 70ms you end up with 170ms
> > >         End-to-End
> > >         delay which is too long....
> > >
> > >         Thanx,
> > >         Jaap
> > >
> > >
> > >         On Wed, 6 Sep 2006, Andreina Toro wrote:
> > >
> > >         > Thanks Miha for your answers, they were really helpful, I
> > >         have a different
> > >         > question now. You said that *"Wireshark can not calculate
> > >         this end-to-end
> > >         > delay since the only information is has are the timestamps
> > >         of the packets as
> > >         > they were captured", *I´ve read that in the RTP Header in
> > >         bytes 5 to 8 there
> > >         > is the timestamp which "reflects the sampling instant of
> > >         the* first* octet
> > >         > in the RTP data packet. The sampling instant must be derived
> > >         from a clock
> > >         > that increments monotonically and linearly in time to allow
> > >         synchronization
> > >         > and jitter calculations", so I don´t have clear why there is
> > >         no way to
> > >         > calculate the end-to-end Delay, the timestamp you refered to
> > >         is the same I´m
> > >         > talking about? or we can access manually the time of
> > >         creation of tha package
> > >         > and wireshark has the time of capture?. Sorry for my
> > >         confusion.. maybe the
> > >         > answer is very simple.. but I don´t see it..
> > >         >
> > >         > My problem is that for part of my thesis (to graduate of
> > >         Electronical
> > >         > Engineering) I have to mesure the Quality of Service
> > >         parameters of VoIP, and
> > >         > then when there is bad QoS activate some alarms and so on...
> > >         So I need to be
> > >         > able to calculate or manipulate the "delay, jitter and
> > >         packet loss" of a
> > >         > call (it can be a summary or an average). Do you have an
> > >         idea how can I
> > >         > solve this problem of getting the Delay information?
> > >         >
> > >         > Thanks so much for your time,
> > >         >
> > >         > Regards,
> > >         > Andreina
> > >         >
> > >         >
> > >         > On 9/5/06, Miha Jemec <m.jemec@xxxxxxxxxxx > wrote:
> > >         > >
> > >         > >
> > >         > >
> > >         > > > In Wireshark the Max Delta represents the DELAY?, are
> > >         these concepts
> > >         > > all right?
> > >         > >
> > >         > > No, what you mean with DELAY is end-to-end delay which
> > >         should be under
> > >         > > 150ms to have good quality. Wireshark can not calculate
> > >         this end-to-end
> > >         > > delay since the only information is has are the timestamps
> > >         of the
> > >         > > packets as they were captured. Max Delta just represents
> > >         the maximum gap
> > >         > > between two consecutive packets. In case of g.711 codec
> > >         and 20ms
> > >         > > packetization this would mean, that packets should come in
> > >         gap of 20ms
> > >         > > and in the ideal case, without any jitter, also the Max
> > >         Delta would be
> > >         > > 20ms. But because of the jitter one packet will come later
> > >         and the Max
> > >         > > delta will increase.
> > >         > >
> > >         > > Regarding the Max and Mean jitter be aware that jitter
> > >         calculations
> > >         > > follows the specification of RFC1889 saying:
> > >         > >
> > >         > > "The interarrival jitter is calculated continuously as
> > >         each data
> > >         > >   packet i is received from source SSRC_n, using this
> > >         difference D for
> > >         > >   that packet and the previous packet i-1 in order of
> > >         arrival (not
> > >         > >   necessarily in sequence), according to the formula
> > >         > >
> > >         > >                    J=J+(|D(i-1,i)|-J)/16
> > >         > > "
> > >         > >
> > >         > > in other words, what you see in the table for jitter are
> > >         not absolute
> > >         > > values of last two packets. Max jitter is the highest
> > >         jitter which
> > >         > > appeared.
> > >         > >
> > >         > > This is how the first implementation of this function in
> > >         ethereal
> > >         > > worked. I didn't look in the code, but I think it is still
> > >         more or less
> > >         > > the same (otherwise someone will hopefully correct me).
> > >         > >
> > >         > > Regards, Miha
> > >         > >
> > >         > > _______________________________________________
> > >         > > Wireshark-dev mailing list
> > >         > > Wireshark-dev@xxxxxxxxxxxxx
> > >         > > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> > >         > >
> > >         >
> > >
> > >
> > >
> > >         _______________________________________________
> > >         Wireshark-dev mailing list
> > >         Wireshark-dev@xxxxxxxxxxxxx
> > >         http://www.wireshark.org/mailman/listinfo/wireshark-dev
> > >
> > >
> > >
> > > _______________________________________________
> > > Wireshark-dev mailing list
> > > Wireshark-dev@xxxxxxxxxxxxx
> > > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> > _______________________________________________
> > Wireshark-dev mailing list
> > Wireshark-dev@xxxxxxxxxxxxx
> > http://www.wireshark.org/mailman/listinfo/wireshark-dev
> >
>
>
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev

_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev