[Date Prev][Date Next][Date Index]
[etc] Analysis of tcpdump output (contd.)
Hi All,
In last fridays meeting, I had pointed out the huge variations in the
values of the inst. BW. I managed to find out the reason for this.
What tcptrace does is, calculate the sending BW. This means it calulates
the inst. BW for every packet sent..
for e.g.
if I send a packet A at time t1.
and then i send another packet at time t2,
then the Inst. BW will be calulated as
INSt. BW = (Size of A) / (t2 - t1)
for .eg. here is a packet trace for 2 packets.
12:08:43.183923 172.21.21.23.1081 > 172.22.22.24.5555: .26625:34817(8192)
12:08:43.183968 172.21.21.23.1081 > 172.22.22.24.5555: . 34817:43009(8192)
Here Packet A is transmitted at 12:08:43.18392 and paket B is transmitted
at 12:08:43.183968 .. Packet A contains 8192 bytes. Thus the inst. BW
calculated in this case will be.
8192 / (12:08:43.183968 - 12:08:43.183923)
==> 8192 / (0.000045) ==> 182.044 Mbytes/sec..
If u do the same for consecutive packets, u will see huge
variations...becasue sometimes there are ACK to be taken care of.
I do not know if we are intereseted in this kind of Inst. BW or not.
please let me know if anyone has some other ideas.
Regards
Shashank
P.S: I have done some baseline experiments and plotted some graphs to
prove this hypothesis. Please let me know if anyone is interested in
verifying the results.
----- Original Message -----
From: "Shashank Khanvilkar" <shashank@evl.uic.edu>
To: "papers" <papers@mia.ece.uic.edu>
Sent: Monday, August 26, 2002 9:57 PM
Subject: [etc] Analysis of tcpdump output
> HI All,
>
> Below is the TCPdump o/p for the packets that I captured during the
> transfer.
>
> I will try to explain the meaning of each packet as I go thru the trace
and
> try to explain, how Tcptrace calculates the Inst. BW.
>
> 1. The first three Packets are for the 3-way Handshake.. reqd for
> establishing a TCP connection, as given below.
>
****************************************************************************
>
****************************************************************************
> **********
>
> 1. 12:08:42.470844 172.21.21.23.1081 > 172.22.22.24.5555: S
> 3728479044:3728479044(0) win 16384 <mss 9140,nop,wscale
0,nop,nop,timestamp
> 850846 0,[|tcp]> (DF)
>
> 2. 12:08:42.677585 172.22.22.24.5555 > 172.21.21.23.1081: S
> 617395557:617395557(0) ack 3728479045 win 65535 <mss 9140,nop,wscale
> 2,nop,nop,timestamp 5238018 850846,[|tcp]> (DF)
>
> 3. 12:08:42.677630 172.21.21.23.1081 > 172.22.22.24.5555: . ack 1 win
16384
> <nop,nop,timestamp 850847 5238018,nop,nop,cc 157> (DF)
>
>
****************************************************************************
>
****************************************************************************
> **********
>
> Observe that the sender advertises a window of 16384 bytes, while the
> receiver advertises a window pf 65535 bytes.. (I had increased the Buffer
> space).
>
> 2. The next packet (4) is a of 2048 bytes sent by the sender.. this is
due
> to slow start.
>
>
****************************************************************************
>
****************************************************************************
> **********
>
> 4. 12:08:42.678666 172.21.21.23.1081 > 172.22.22.24.5555: P 1:2049(2048)
ack
> 1 win 16384 <nop,nop,timestamp 850847 5238018,nop,nop,cc 157> (DF)
>
> 5. 12:08:42.884153 172.22.22.24.5555 > 172.21.21.23.1081: . ack 1 win
51200
> <nop,nop,timestamp 5238019 850847,nop,nop,cc 284> (DF)
>
> 6. 12:08:42.947523 172.22.22.24.5555 > 172.21.21.23.1081: . ack 2049 win
> 51200 <nop,nop,timestamp 5238019 850847,nop,nop,cc 284> (DF)
>
>
****************************************************************************
>
****************************************************************************
> **********
>
> The packet (5) is sent by the recv to reduce the window size from 65535
> bytes to 51200 bytes.. (This is due to some internal mechanics of TCP).
>
> The packet (6) is an ack for the packet (4)... Since an ACk has been
> received, tcptrace calculates the inst. BW as
>
> 2048 / (12:08:42.947523 - 12:08:42.678666) ==> 2048/0.288857 ==> 7.617
> KBYTES/sec
>
>
>
> 3. Now observe the next set of packets....
>
>
****************************************************************************
>
****************************************************************************
> **********
>
> 7. 12:08:42.947595 172.21.21.23.1081 > 172.22.22.24.5555: .
2049:10241(8192)
> ack 1 win 16384 <nop,nop,timestamp 850847 5238019,nop,nop,cc 157> (DF)
>
> 8. 12:08:42.947647 172.21.21.23.1081 > 172.22.22.24.5555: .
> 10241:18433(8192) ack 1 win 16384 <nop,nop,timestamp 850847
> 5238019,nop,nop,cc 157> (DF)
>
> 9. 12:08:43.183786 172.22.22.24.5555 > 172.21.21.23.1081: . ack 18433 win
> 51200 <nop,nop,timestamp 5238019 850847,nop,nop,cc 284> (DF)
>
>
****************************************************************************
>
****************************************************************************
> **********
>
> Again here the sender sends packets 7 and 8 , each of 8192 bytes and waits
> for an ACK.. It receives an ACK in packet 9.. Now again tcptrace
calculates
> the Inst. BW..
>
> 8192*2 / (12:08:43.183786 - 12:08:42.947595) ==> 8192 * 2 / 0.236191 ==>
> 69.367 KBytes/sec
>
> 4. Now observe the next set of packets.
>
>
****************************************************************************
>
****************************************************************************
> **********
>
> 10. 12:08:43.183860 172.21.21.23.1081 > 172.22.22.24.5555: .
> 18433:26625(8192) ack 1 win 16384 <nop,nop,timestamp 850848
> 5238019,nop,nop,cc 157> (DF)
>
> 11. 12:08:43.183923 172.21.21.23.1081 > 172.22.22.24.5555: .
> 26625:34817(8192) ack 1 win 16384 <nop,nop,timestamp 850848
> 5238019,nop,nop,cc 157> (DF)
>
> 12. 12:08:43.183968 172.21.21.23.1081 > 172.22.22.24.5555: .
> 34817:43009(8192) ack 1 win 16384 <nop,nop,timestamp 850848
> 5238019,nop,nop,cc 157> (DF)
>
> 13. 12:08:43.420480 172.22.22.24.5555 > 172.21.21.23.1081: . ack 34817 win
> 51200 <nop,nop,timestamp 5238020 850848,nop,nop,cc 284> (DF)
>
> 14. 12:08:43.420563 172.21.21.23.1081 > 172.22.22.24.5555: .
> 43009:51201(8192) ack 1 win 16384 <nop,nop,timestamp 850848
> 5238020,nop,nop,cc 157> (DF)
>
> 15. 12:08:43.420615 172.21.21.23.1081 > 172.22.22.24.5555: .
> 51201:59393(8192) ack 1 win 16384 <nop,nop,timestamp 850848
> 5238020,nop,nop,cc 157> (DF)
>
> 16. 12:08:43.420657 172.21.21.23.1081 > 172.22.22.24.5555: .
> 59393:67585(8192) ack 1 win 16384 <nop,nop,timestamp 850848
> 5238020,nop,nop,cc 157> (DF)
>
> 17. 12:08:43.547472 172.22.22.24.5555 > 172.21.21.23.1081: . ack 43009 win
> 51200 <nop,nop,timestamp 5238020 850848,nop,nop,cc 284> (DF)
>
>
****************************************************************************
>
****************************************************************************
> **********
>
> again sender sends packets 10, 11, 12 each of 8192 bytes of data and then
> waits for an ACk.. It receives an ACK in the 13th packet but it only
covers
> packet 10 and 11 and hence ttcptrace again calculates the BW as
>
> 8192 * 2 / (12:08:43.420480 - 10. 12:08:43.183860) ==> 8192*2 / 0.23662
==>
> 69.241 Kbytes.
>
>
>
>