4 ms·
I don’t have numbers off hand, but from a feeling I have from memory, I would think it is extremely unlikely that TCP checksums are consistently failing to trig
by willis936 6y ago
I don’t have numbers off hand, but from a feeling I have from memory, I would think it is extremely unlikely that TCP checksums are consistently failing to trigger retransmission. Someone must be altering packets along the way.
- _-___________-_ 6y agoIt is triggering retransmission. It just retransmits until it gets lucky with the (pretty weak) TCP checksum.
- cranekam 6y agoTCP checksums are notoriously weak: https://www.evanjones.ca/tcp-checksums.html https://www.evanjones.ca/tcp-checksums.html With enough packets passing the dodgy RAM a noticeable number will manage to get mangled in such a way that the checksum is still correct.
- ericbarrett 6y agoChecksums are also often recomputed on transit if the packet is intercepted, e.g. to limit TTL, unflag odd/unused TCP features, that kind of ISP-ish preening. So if it was a software error or even a hardware problem in the right (wrong) spot it’s possible to get this kind of corruption without retransmits.
- noncoml 6y agoI think you are confusing the IP header with TCP header. Routers don’t touch the TCP header at all
- Avery3R 6y agoif your router does NAT it touches the tcp header
- noncoml 6y agoYou are right, although NAT could be classified as a firewall feature, that runs on routers. But in any case it's irrelevant in this context as ATT shouldn't be doing any NAT
- ericbarrett 6y agoNo. URG, “Christmas tree” packets, etc. all can be mangled by the ISP. Or more commonly dropped
- deleted 6y ago[deleted]
- bytesandbots 6y agoIn that case, won't there be significant packet loss causing throughput to be very slow? I don't know if this is possible without something messing with TCP headers.