Retransmission of packets 1

[dozier]

Hello folks,

I've got a sniffer on a local segment monitoring a tcp/ip connection between a couple of devices and I'm seeing something I don't understand.

The connection is between 10.1.1.1 and 172.16.1.1 and it established and working.

At one point I see 10.1.1.1 send a packet with sequence # 2467993460, Ack # 452117883, and size 376. Then in a relatively short amount of time it resends this packet 4 more times because no Ack was recieved from 172.16.1.1. But there is then a 6th packet (1st being the initial, then 4 resends, then this one), with the same sequence and Ack but a larger size (570).

So, my question is, is that normal TCP behaviour? If it sends a packet, doesn't get a response, and while it's in the process of resending notices that additional application data needs to be sent,will it do a retrasmission with additional data? Wouldn't that throw it off because it's referenced exactly the same with sequence and Ack but a different size?

Thanks for any input.

 

[JasonDeckard]

Yes, that's normal behavior. If the 376 bytes weren't acknowledged, and more data is available to send on the retry, the additional data will be sent as well.

An exception to this is if the current window size would not allow all of the available data to be sent.

 

[dozier]

Jason, thanks for your reply. I have another question directly related to this:

Once the remote end receives one of these packets, it sends out an Ack. What is it supposed to do when it receives the resends that have the same sequence # and Ack #? Should it not realize that it is an invalid packet since its sequence # is lower than the last Ack # it sent out?

What I saw in the given example was 4 exactly-the-same Ack packets in a row Ack'ing the original 376 byte size packets and not one for the 570 byte size packet.

Why would it send more than one Ack?

And am I correct in guessing that since the device at 10.30.1.1 finally received Ack packets for the 376 byte size packets it realized it needed to resend the extra data that it had appended in the 570 byte packet?


I think I'm starting to get this..

 

[JasonDeckard]

Hi dozier,

When one end of the connection receives bytes it has already acknowledged, it will discard those bytes and send an ACK indicating what byte it expects next.

The sender will resend packets until the receiving end acknowledges the data, or until the session times out (the sender has resent the data a few times, usually five, and never received an ACK, so it gives up).

The reason we need ACKs in the first place is data doesn't always arrive at its destination. Consider a scenario where system A sends 376 bytes to system B. B sends the ACK, but A never gets it (the ACK got lost on the way). Since A didn't receive an ACK, it resends the 376 bytes. B has already acknowledged this data, but resends the ACK. A receives the ACK the second time.

If the first ACK got lost and B never resent the ACK, then A would be stuck resending until it gave up. A has no way of knowing if B got the data until it receives an ACK. Since ACKs can get lost in transmission just like other data, it is important to resend ACKs when needed.

 

[dozier]

Makes sense, Jason, thanks very much!

 

[bierhunter]

Not sure what type of equipment you're using, but you may want to also check the memory buffers in your router(s). Overworked buffers can also cause retransmissions. They may need adjusting.

BierHunter
CNE, MCSE, CCNP

 

[pacerla]

In a windows server class I saw a video on how email is created and passes thru the ISO model and finally reaching it's destination. It is in a "cartoon format" but I can't fins anything like it. The profeesor has moved on so that's no help. Any ideas?