VDSL has 3-9% overhead, dependent on your situation, then you have TCP overheads.
If you're on cable then sorry, the Superhub is awful
VDSL has a line sync rate, an ISP profile and a 'goodput' of actual usable bandwidth. On a 50 meg line, you'll probably have something like a 48 mbit profile, then you lose more in the TCP overheads, so closer to 44 mbit/sec 'goodput'.
VDSL has about 3.3% overheads, unless you have high interleaving or a G.INP high retransmission profile which makes more like 8 or 9% of sync.
Let's assume you have a good line so lose about 3.3% on ~50mbit sync, and you're on a 48.3 mbit/sec IP profile.
Taking 46 mbit/sec 'goodput' on a 50 mbps connection with a normal 1500 MTU, while maxing the line streaming over TCP you're also working with a ~5% overhead for TCP. 5% of 48.3 mbit is about 2.4 mbit so your usable bandwidth for video chunks is closer to 45.
Upstream is subject to the same overheads; assuming 2.5 mbit/sec sync you end up with ~2.2 usable. If your upstream is slower, from e.g. 2 mbit sync you get ~1.7 usable.
Assuming you can stream reliably at ~45 mbit/sec, without loads of retransmits or packet loss, you're typically generating about 120-180 kilobytes/second of ACKs, around 1 to 1.5 mbit/sec. If ACKs start to queue or get lost you'll notice fast (first the visual quality will drop as the bit rate reduces, as the streaming protocol thinks you don't have enough bandwidth). Starting to get close to the theoretical max upload on your line...
All it needs is some heavy web surfing or YT/twitch at the same time for things to start falling apart, unless you have a router doing some QoS on your outbound traffic. Browsing and gaming speeds might reduce, but you won't totally saturate your upload and 'kill' your connection.
Do you notice the bit rate of the stream fluctuating significantly during these periods, or does it stay locked at the highest bit rate and resolution? (not sure if you can see this with Prime Video)
That sort of cliff-edge packet loss looks to me like you're either being QoSed by your ISP or you're saturating your upload. Another possibility is your router is struggling to maintain throughput for a sustained amount of HD video stream traffic as well as route to the WLAN, if it's not very powerful and is doing everything on the CPU.
Less plausible, but not totally out of the question, is that the iPad is doing something odd at Layer 1 or 2 and causing the router grief. Perhaps making it hit its CPU limit if it doesn't have any hardware IP acceleration.
What's your router? What sort of other traffic is usually on the network around these times, how have you got the router configured and do you have any other uploads running while streaming?
Further reading
https://www.increasebroadbandspeed.co.uk/speed-test
https://superuser.com/a/1323087/25193 said:
Ack packets on ethernet are minimally 64 bytes in size, 'loaded' downstream packets on typical PPPoA DSL deployments are usually 1492 bytes in size.
RFC1122 specifies "in a stream of full-sized segments there SHOULD be an ACK for at least every second segment".
Therefore your minimum ack bandwidth ratio is 64/(1492*2) = 2.15%, or 22,490 bytes of acknowledgements required per 1MB received, or as a bitrate approximately 110kbps (0.1Mbps) up per 5Mbps down.
