UDP Packet dropping

[WoodlandsLane]

One for the network infrastructure team:

I'm sending a file via UDP packets of 1536 bytes (I know this fragments) from home to an AWS EC2 instance in Utah. When the packet is received I then build up a table of received blocks and when that is a datagram full I send it back, client then acknowledges that and keeps looping until all the packets are sent. Works fine, up to a point. On a 186Mb file it was always missing about 200Kb. On checking it was always the same packets missing. I then delved deeper and started altering the packet data and after a couple of hours I narrowed it down to two bytes, 1330 and 1331, in the faulty packets it would always be 1330 == 0 & 1331 == 0x87 0x89 or 0x8b. I could fill the packet with random junk, but as long as I set those two specific bytes I would get 100% packet loss. I must be triggering some QoS of bad routing on a Cisco somewhere. Just wondered if you have ever come across anything similar before?  

Incidentally if I do the test across the Zen network it all transfers fine with no packet drops.

Note, I know very well that UDP isn't a reliable protocol and that I get many packet drops anyway which is why I constantly resend until acknowledged but it's always these packets and they never get through, always 100% dropped. Fault must be on the Three network as Zen and Three go out on the same transatlantic pipe.

Tim

[WoodlandsLane]

Thanks for the reply, the connection works fine via Zen so imagine it's the actual packet. I've performed the same test over a VPN and it works fine.

Tim

[PeteG]

Much appreciated. It sounds like you're onto something, I've forwarded the details to one of our IT people. Hopefully the issue can be identified quickly. 

Pete. 

[PeteG]

Hey there. 

Welcome to Three Community. 

Gosh that is a weird issue. I haven't come across that before. A good way to test this would be to repeat the test while using a VPN if possible. This would encrypt the data and wrap it in a new packet. The same data pattern would no longer exists. If the issue went away, this could potentially confirm that something is going on with how Three is handling that data, it'll also give the team a good place to start when I feed it back to them. Would you mind doing that test if possible? 

While it's being looked into, if possible, it might be worth trying to avoid fragmentation by lowering the payload size to something like 1400 bytes.

Pete.