8

Out of curiosity, I connected my laptop with an ethernet cable to the router and fired up Wireshark to understand and 'visualize' what's going on.

Some packets caught my attention.

I was having some TCP retransmissions from time to time to and from WAN traffic, I don't have meaningful LAN traffic btw.

I started to become worried knowing that I'm having retransmissions, but thinking it's coming from and to the internet it is to be expected from time to time... I guess? Although I find it hard to quantify if it's too much and how much is acceptable.

PS: Just to say it is not about TCP retransmissions with TCP Port numbers reused.

Improve this question
2
  • 2
    I read something years ago that said up to 5% of wire/ethernet packets were received with a mismatched crc32. I'm surprised that TCP would retry that often though because that layer uses a simple checksum rather than CRC. I worked on low level stuff like that for years and never had a TCP retry issue that wasn't hardware related.
    – Neil
    Commented Mar 24, 2023 at 9:21
  • 1
    Relevant: en.wikipedia.org/wiki/Random_early_detection
    – jpa
    Commented Mar 25, 2023 at 10:19

2 Answers 2

Reset to default
15

TCP retransmissions are perfectly normal and expected as long as there aren't too many. It should probably be less than 1% of your TCP segments that get retransmitted.

Retransmissions are normal because dropped packets are normal. Dropped packets are actually used as a signal between routers and senders' TCP stacks that network congestion is happening, so the sending TCP stack needs to use its congestion control algorithm to back off its transmission speed for a moment.

Improve this answer
4
  • 3
    Indeed. If you have no dropped packets anywhere, you're consistently under-utilising the available bandwidth. You need a certain rate of droppage if your network stack is to measure the transmission capacity and to keep that measure up to date. Obviously there's a cost to that measurement, and that's why Linux provides a choice of congestion-control algorithms to tune the behaviour to your needs (I don't know whether other OSes provide the same flexibility, but they really ought to).
    – Toby Speight
    Commented Mar 24, 2023 at 10:45
  • 3
    @TobySpeight That's true for traditional TCP, but modern congestion control algorithms, particularly the default in modern versions of Windows, macOS and Linux, TCP CUBIC, use latency increase as a sign of congestion, avoiding packet drops.
    – user71659
    Commented Mar 24, 2023 at 19:23
  • 2
    Sorry, I misremembered, CUBIC is loss-based, its Windows predecessor, CTCP is delay and so is BBR used by QUIC.
    – user71659
    Commented Mar 24, 2023 at 22:02
  • 1
    @user71659 It’s also worth noting that BBRv2 added the use of packet loss as a signal. There has long been a back-and-forth between latency-based and loss-based congestion control algorithms. Now that ECN is getting some love, maybe ECN will mark (heh) the end of loss-based signaling, but I think it’s it’s still too soon to call.
    – Spiff
    Commented Mar 25, 2023 at 0:54
2

A certain amount of Network Retransmission is entirely normal.

You would have to track it to see if increasing or level.

I see this here.

Comm View trace

Improve this answer
3
  • 2
    Can you describe what can be seen in your screenshot and how it related to the amount of retransmissions that are usual for a TCP connection? Currently your answer is incomplete to answer the original question.
    – allo
    Commented Mar 24, 2023 at 12:06
  • The question is about TCP retransmission not "Ethernet retransmission"
    – R.. GitHub STOP HELPING ICE
    Commented Mar 24, 2023 at 12:16
  • I changed the word to network retransmission . I took the screenshot from a network session.
    – anon
    Commented Mar 24, 2023 at 13:49

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .