TCP Selective Ack TCP Dup Ack TCP Previous Segment Lost

TCP Selective Ack is a TCP Option that reduces packet retransmissions of data already sent and received. If only one packet is lost, only one packet is retransmitted. When Selective Ack is not used lost data is sent from the first packet lost even if the node received subsequent packets. Selective Ack allows the recipient to notify the sender of what data “holes” are lost and only those holes are resent.

Transcript:
Another problem that’s brand new out there in the IT environment, and one that we’re seeing more and more because we’ve got OSPF links that are being load bounced across what people believe to be equal path costs. Well, when you have truly equal paths, a wide area network rarely gives you equal paths in latency. So, you may have BGP or OSPF load balancing going on inside your infrastructure or inside the internet and you may have two parallel paths going to the same place that you’re load balancing across. Where packet number one is getting there after packet number two because we’ve got what we call SKU delay or one path is faster than the other path. We’re putting packets in a queue, where they’re going one path one time, one path another time. What I’m seeing, because of that, is the following manifestation, and we’re seeing lots of use of selective acknowledgements.

Now, a selective acknowledgement is an advanced TCP function wherein we show the sequence number here, that’s the native sequence number, and we’re sending out 448 bytes here of data. What we’re finding is that down here that this packet, the smaller packet, the 448 byte packet, sent after the larger packet, the 1460 byte packet. Believe it or not, the second packet is arriving before the first packet. Consequently, what happens is TCP says, nope, I can’t acknowledge the receipt of those 448 bytes, because I have not received the 1460. So, the native sequence number plus length equals acknowledgement is not going to work for us. And the reason is, that until it gets the 1460 and plus the 448, it’s not going to acknowledge it appropriately. But we have a mechanism so that we don’t have to retransmit everything that’s been transmitted. We can say I’ve got this part of the transaction. I got a forward sequence number, but I didn’t get the past sequence number and I’m missing and I have a hole in my TCP data.

I can tell you about it using a TCP option called selective acknowledgement- this something that is set up in the TCP SynSynAck options, when the session first begins. And you can go in and look at those packets and you’ll see that these options are being set-up. Selective ACK is one of them that is very popular. It works quite well; however, you’re going to see the manifestation of the receiving protocol stack, kind of complaining a lot that it’s getting packets out of sequence. I kind of want to show you what that looks like. So, here we have 1460 plus 448, and here you that this is the same left edge of that data. So, this is the left edge. So, we didn’t get this 1460. We didn’t get 1601 plus 1460. We are missing, in fact, this packet right here. But it’s telling me, although, I didn’t ACK that packet, I am selectively acknowledgement. This stands for selective left edge of the data, which starts at 3281,which is 3281 and I’ve got 448 bytes there and so the right selected right edge of that data is up here, which would be the end.

So, if you take the 448, plus the 281, it’s going to equal 729. Okay, it’s all very simple math, but this is the way the TCP protocol stack works, for selective acknowledgements. Now, once the node does, indeed, get that packet, then we see the acknowledgement going up to 729 down here. It all recovers. But notice the chattiness of your session. You’ve got a recipient of a bunch of data who got information out of sequence. So, he sends one, two, three, four selective acknowledgements. I got this, but I didn’t get the one before it. So, consequently, we need to be on the watch. We need to see if some of theses fancy features that we’re turning on and all of these routers and gizmos and widgets, because we went to router school and they said you can turn on this load balancing option. Well, be careful that after you turn that thing on, that you go out and put a packet capturing analyzer before, and you put a packet capturing analyzer afterwards, to validate what you just did to your customers or your packets. This is happening a lot out there, because people are turning on these links or turning on these features and they’re not turning on an analyzer to find out what was going on. So, that’s another example of stuff that’s happening out there in the field that you need to know about on a regular basis.