Re: QoS in TCP and UDP

[Masonke <masonke () gmail com>]

You merged 2 files, so the packet count would double. 

Find a packet, then look for the duplicate. The delta between them is the delay. 

Do this for several packets and then find the variance, that is jitter. 

The difference in time sync between the devices will be the granularity of time measurement. Make sure you use pcap-ng 
for the capture to gain max granularity. 

Also, the basic accuracy of the clocks on the systems you are using will factor into the delay. 

~ken

> On Dec 31, 2014, at 09:31, Armansah Hs <armansah.hs () gmail com> wrote:
>
> I've been trying to analyze end-to-delay by merging both files but total packet also doubled.
> Is this normal or this prove that the time is not synchronized both devices?
>
> is this correct :
> delay is
> time when a packet sent (192.168.100
> 1 -> 192.168.100.6) in the source device
> and
> time when a packet received (192.168.100.6 -> 192.168.100.1) in the destination device
> ?
>
> how about next packet sent? is that called jitter? latency?
>
> sorry for my bad english.
> thanks
>
> armansah hs
>
> > On Dec 29, 2014 4:12 AM, "masonke" <masonke () gmail com> wrote:
> > use the command line tools to merge the files
> >
> > Files are made of packets, tcp handles the retransmissions.  A successful packet reception is indicated by an ACK.  
> > Kevin Mason
> > ———————
> > masonke () gmail com
> > 912-713-4744
> >
> > > On Dec 28, 2014, at 15:03, Armansah Hs <armansah.hs () gmail com> wrote:
> > >
> > > Thanks kevin.
> > > I will try to analyze it by merging both files.
> > > I just know that there are things like merge file in wireshark.
> > >
> > > Regarding TCP and RTP packet loss, I see there are several lines of retransmissions.
> > > Whether it is possible there is packet loss if the file was successfully sent?
> > > What indicates that the retransmission process is successful or not?
> > >
> > > Armansah Hs
> > >
> > > > On Mon, Dec 29, 2014 at 3:08 AM, masonke <masonke () gmail com> wrote:
> > > > For delay and jitter, your clocks on the 2 devices doing the capture need to be synchronized. Then you need to do 
> > > > the captures merge the files and measure the delta time from the sender to the receiver.
> > > >
> > > > Packet loss is easy, look for retransmissions
> > > > Kevin Mason
> > > > ———————
> > > > masonke () gmail com
> > > > 912-713-4744
> > > >
> > > > > On Dec 28, 2014, at 09:26, Armansah Hs <armansah.hs () gmail com> wrote:
> > > > >
> > > > > Thanks for your response.
> > > > > I'm sorry for giving such a long question, the point of my question is how to get this value based on my scenario
> > > > >
> > > > > TCP end-to-end delay
> > > > > TCP jitter
> > > > > TCP packet loss
> > > > >
> > > > > RTP end-to-end delay
> > > > > RTP jitter and
> > > > > RTP packet loss
> > > > >
> > > > > I've been told that it require captured traffic file on both source and destination.
> > > > > I had it but I don't know how to get it.
> > > > >
> > > > > I'll appreciate any positive response.
> > > > >
> > > > > Thanks 
> > > > >
> > > > > > On Sun, Dec 28, 2014 at 9:42 PM, NITIN GOYAL <nitinkumgoyal () gmail com> wrote:
> > > > > > please avoid reposting your question again and again..
> > > > > >
> > > > > > also, your mail is so long and eve after reading < I am not clear what is your specific question
> > > > > >
> > > > > > also, i dont see much research you have done.
> > > > > >
> > > > > > please send the to the point and specific question and please avoid combining many questions.
> > > > > >
> > > > > > > On Sun, Dec 28, 2014 at 6:40 PM, Armansah Hs <armansah.hs () gmail com> wrote:
> > > > > > > Hello,
> > > > > > > Sorry for repeating my question. I've post this question before but my daily digest was turn on so any replies 
> > > > > > > will be sent via daily digest.
> > > > > > >
> > > > > > > ------------ repost -------------
> > > > > > > I'll attach you example captured traffic (RTP protocol)
> > > > > > > ------------------------------------
> > > > > > >
> > > > > > > I have 4 files of captured traffic in wireshark, both client (192.168.100.6) and server (192.168.100.1) have a 
> > > > > > > captured traffic and time synchronized.
> > > > > > > I want to ask you some questions about how to get the QoS parameters in wireshark (end-to-end delay, jitter, 
> > > > > > > throughput, and packet loss)
> > > > > > >
> > > > > > > I have two scenario
> > > > > > > Transfer file between source and destination (2 files)
> > > > > > > Video streaming using VLC based on RTSP (2 files)
> > > > > > > so far, I've got TCP throughput and RTP Throughput.
> > > > > > >
> > > > > > > Transfer file
> > > > > > > TCP throughput - in the Statistic -> Summary (done)
> > > > > > > TCP e2e delay, jitter, and packet loss. I want to know how to get these parameters.
> > > > > > > Video Streaming
> > > > > > > RTP throughput  - in the Statistic -> Summary (done)
> > > > > > > RTP e2e delay. I want to know how to get this parameter.
> > > > > > > My friend taught me that RTP packet loss and RTP jitter can be found in RTP -> Telephony -> Show all streams.
> > > > > > > but when I go in that menu, there is no jitter and there are 2 detected RTP stream (<5% packet loss and >40% 
> > > > > > > packet loss)
> > > > > > > -------------------------
> > > > > > > this is what Jaap say in the answer section
> > > > > > > TCP throughput: that can be derived from the protocol interaction at a single endpoint, hence is available.
> > > > > > > TCP e2e delay, jitter, packet loss: Hard to do based on a single capture, apart from the packet loss maybe, as 
> > > > > > > retransmissions would indicate as such. Not aware of a ready made analysis function right now.
> > > > > > > RTP throughput: that can be derived from the protocol interaction at a single endpoint, hence is available.
> > > > > > > RTP packet loss: Be aware, you use an Telephony analysis feature for video, that doesn't work. Unfortunately 
> > > > > > > the RTP statistics are not profile aware and geared towards telephony only. And even then only the simplest 
> > > > > > > cases.
> > > > > > > RTP e2e delay: Hard to do based on a single capture.
> > > > > > > -------------------------
> > > > > > > last but not least, Related to packet loss, do I really have a packet loss if the retransmission successfully 
> > > > > > > sent to destination?
> > > > > > >
> > > > > > > how to extract TCP and RTP e2e delay; TCP packet loss; TCP and RTP jitter?
> > > > > > >
> > > > > > > where I can find the RTP packet loss and jitter other than through telephony analysis?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I'm very sorry for flooding mailing list with my questions.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Armansah Hs​
> > > > > > >
> > > > > > >  server_skenario1_stream1.pcapng
> > > > > > > ​​
> > > > > > >  client_skenario1stream1.pcapng
> > > > > > >
> > > > > > >
> > > > > > > ___________________________________________________________________________
> > > > > > > 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
> > >
> > > ___________________________________________________________________________
> > > 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