Minimal TCP/IP overhead (over Ethernet frames)

It really depends on how you define overhead. This answer will assume overhead is the number of bytes that you need to transmit in addition to the data itself.

For Ethernet, assuming the 5000 byte payload is not encapsulated in an IP + TCP/UDP frame, you will have 18 bytes of overhead for every packet sent. That means each transmission with an MTU of 1500 will be able to hold 1482 bytes. To transmit 5000 bytes, this means 4 packets must be transmitted, which means an overhead of 72 bytes (18 * 4). Note that the overhead becomes bigger when you include things like the IP frame which contains a TCP frame.

For PPP, as you've already shown, you can send 492 bytes per frame. Eleven frames means 88 bytes of overhead (11 * 8) - again, not including any additional protocol frames within the payload.

In both these examples any protocols that build on top of these link layer protocols will contribute to overhead. For example, an Ethernet packet sent with an IPv4 frame which contains a UDP datagram will have an additional 28 bytes consumed by headers and not data (20 bytes in an IPv4 header and 8 in a UDP header, assuming no IP options). Considering the original Ethernet example, this means the amount of data per packet becomes 1454 bytes, which luckily still comes to 4 packets (the extra spills over into the smaller 4th packet), with 144 bytes of overhead.

You can read more here (I find that page a little hard to read though).

The client receives a packet with sequence number greater than expected (seq: 2801, acked: 1), so there is a lost packet possibly. The client signals this by sending the ack with the expected byte (1), but the server keeps sending from sequence 2801, thus the endless loop.

Either that first (two-three?) segments always drop out, or there is some buggy TCP implementation alogn the server-routers-client line? I'm interested if you got this sorted.