Wireshark by default shows not the real sequence numbers but the relative ones – this can be changed in menu

When troubleshooting HTTP long responds – be aware that by default Allow subdisector to reassemble TCP stream in Wireshark is enabled – which could bring a lot of confusion as it reasembles the packets and wait of full web page load, instead of getting the picture in 1ms you can see it wireshark as getting in 30 seconds, despite that there was no problem at all. Recomending to view a video on this : Wireshark Tutorial Series #2. Tips and tricks used by insiders and veterans

Sequence Numbers

Built to count the bytes in segment

When segment sent only with ACK without the data you might see that seq# is not incrementing – as there is nothing to count

Also it might increment even while empty – this called phantom byte – add +1 to seq#

About the Missed ACKs

Not each sent segment will receive an ACK for it – might be we will be acking each 5 segments

RTO – Re-transmission timeout value – depends on RTT, also so called SRTT Smooth RTT – when we are comparing multiple RTT values and taking the average.

Why TCP is reliable ? Because before and after sending the Segment it puts it into the Re-transmission Queue and only after receiving an ACK it removes the segment from there.

Duplicate ACKs are appearing after one of the segments has been delivered but other one was lost – then we are repeating the last ACKed segment – selective repeat here comes into play with option field which helps to retransmit only what is missing.

Sliding Window Rules :

Bytes sent and acknowledged – removing from retransmission queue.

Bytes sent but not yet acknowledged

Bytes not yet sent for which receiver is ready – usable window

Bytes not sent and receiver is not ready to receive them

Urgent Bit

No priorities here, just flagging the segment about it’s urgency – TCP does nothing special here, only allows to upper layer APP to identify the urgent packet.

If QoS is enabled and you like to prioritize the traffic, flow control needs to be disabled,as it doesn’t care about any higher level prioritization, just when ingress traffic is coming in faster than receiver can accept it, flow control will kick in and send pause frames until the ingress-egress rate will be equalized or ingress rate is lower than egress of that interface.

A bit more info from Dell FTOS 9 documentation about flow control :

I would use it only for storage – for example iscsi traffic, in separated network, then it won’t do any harm.. probably 🙂

But of course no way of using it on trunk links, other switch facing links and etc.