Wireshark-users: [Wireshark-users] Lost packet, Retransmitted packet & Duplicated packet
From: Becky Vict <becky_vict@xxxxxxxxx>
Date: Tue, 9 Oct 2007 21:48:01 -0700 (PDT)
Hi everyone,
I was looking at my server and client captures to compare the TCP retransmissions of packets. I'm using Wireshark and tcptrace to analyse. And found the followings:
1. Some packets from the server are 'truly lost', i.e. never received by the client and the server retransmits them. This is deduced from: Server capture - the server retransmits a particular packet twice, after receiving no acknowledgment (RTO) for the first transmission. Client capture - the client only received the particular retransmitted packet from the server once, (i.e. the second time round the server retransmits). So, on client side, this is 'not marked as retransmission' and treated as the ordinary packet received after a long idle time. But on the server side, this is 'marked as lost packet or retransmission'.
2. Some packets are 'truly lost' also when the client issues dupacks for the expected packet that has not arrived yet and SACKS for the out of order packets that come after the expected one. This is deduced from: Server capture - receives dupacks and doing fast retransmit after 3 are received. So the server retransmits the packet twice, the first time never arrives at the client. Client capture - issues dupacks and SACKS and receives the retransmitted packet from the server after 3 dupacks, and this packet occurs once only in server capture. Again, on client side, this will 'not be marked as retransmission' and treated as out of order packet. But on the server side, this is 'marked as lost packet or retransmission'.
3. Some packets are 'duplicated' when the client receives a particular packet twice. This happens when ACK from the client for successfully receives packet 'is lost' and does not reach the server. This is deduced from: Client capture - client receives the same packet twice. Server capture - retransmit after no ACK for the particular packet is received (RTO). So on the server side this is 'not marked as lost packet' because in actual it is not. On the client side, this will be 'marked as duplicated packet' since it is and I thought of marking the lost ACK from client based on how many packets are duplicated as 'lost packet'. I tend to think packet is the one with actual data in it, and not the one which carry flags only though I guess this is wrong thinking.
So in summary, there is a difference between packet lost from the server side and from the client side. 1) and 2) above are from the server side, and 3) from the client.
I welcome any comment/feedback.
Thanks.
Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.
I was looking at my server and client captures to compare the TCP retransmissions of packets. I'm using Wireshark and tcptrace to analyse. And found the followings:
1. Some packets from the server are 'truly lost', i.e. never received by the client and the server retransmits them. This is deduced from: Server capture - the server retransmits a particular packet twice, after receiving no acknowledgment (RTO) for the first transmission. Client capture - the client only received the particular retransmitted packet from the server once, (i.e. the second time round the server retransmits). So, on client side, this is 'not marked as retransmission' and treated as the ordinary packet received after a long idle time. But on the server side, this is 'marked as lost packet or retransmission'.
2. Some packets are 'truly lost' also when the client issues dupacks for the expected packet that has not arrived yet and SACKS for the out of order packets that come after the expected one. This is deduced from: Server capture - receives dupacks and doing fast retransmit after 3 are received. So the server retransmits the packet twice, the first time never arrives at the client. Client capture - issues dupacks and SACKS and receives the retransmitted packet from the server after 3 dupacks, and this packet occurs once only in server capture. Again, on client side, this will 'not be marked as retransmission' and treated as out of order packet. But on the server side, this is 'marked as lost packet or retransmission'.
3. Some packets are 'duplicated' when the client receives a particular packet twice. This happens when ACK from the client for successfully receives packet 'is lost' and does not reach the server. This is deduced from: Client capture - client receives the same packet twice. Server capture - retransmit after no ACK for the particular packet is received (RTO). So on the server side this is 'not marked as lost packet' because in actual it is not. On the client side, this will be 'marked as duplicated packet' since it is and I thought of marking the lost ACK from client based on how many packets are duplicated as 'lost packet'. I tend to think packet is the one with actual data in it, and not the one which carry flags only though I guess this is wrong thinking.
So in summary, there is a difference between packet lost from the server side and from the client side. 1) and 2) above are from the server side, and 3) from the client.
I welcome any comment/feedback.
Thanks.
Moody friends. Drama queens. Your life? Nope! - their life, your story.
Play Sims Stories at Yahoo! Games.
- Prev by Date: Re: [Wireshark-users] Issue with LDAP protocol?
- Next by Date: [Wireshark-users] Where is the wireshark 0.99.6a source code?
- Previous by thread: Re: [Wireshark-users] Issue with LDAP protocol?
- Next by thread: [Wireshark-users] Where is the wireshark 0.99.6a source code?
- Index(es):