3 ms·

I have a 500mbit/sec wan link. Unless I'm careful I can lose packets with a stream running at 100mbit (send at 1gbit for 100ms, 0mbit for 900ms - see this with

I have a 500mbit/sec wan link. Unless I'm careful I can lose packets with a stream running at 100mbit (send at 1gbit for 100ms, 0mbit for 900ms - see this with iperf3 for example) I need to buffer that 50mbit of traffic, which could be 100,000 packets. It also introduces delay. I can still use qos to ensure packets I want with less jitter get through in front of the 100k queue. The latency over the second will vary from zero to 50ms, even with 20% network utilisation (or I get lost packets)

AnthonyMouse 9y ago
> I have a 500mbit/sec wan link. Unless I'm careful I can lose packets with a stream running at 100mbit (send at 1gbit for 100ms, 0mbit for 900ms - see this with iperf3 for example) Sending at gigabit for 100ms implies a 12.5MB buffer. A lot of routers sensibly won't (or just can't) buffer that much data, so sending in such large bursts is a good way to get your packets dropped. Which is why sensible programs (and the TCP stacks in major operating systems) don't do that. Instead they'll either use a smaller time slice or use the event-based TCP "ACK clock" where packets are sent in response to receiving acknowledgements of previous packets, which spreads the transmissions more uniformly. Moreover, notice that the thing you're describing still shouldn't happen within an ISP's network, because it's caused by an individual stream sending faster than the path bandwidth. That can happen when you go from 1Gbps LAN to <1Gbps WAN, which is why QoS can be helpful on the customer's edge router, but that isn't part of the ISP's network. It shouldn't happen when you go from a 500Mbps customer link to an unsaturated 40Gbps peering link. The 500Mbps link can't saturate the 40Gbps link, and if some combination of them do, it's not because of the sending pattern, it's because the uplink is too over-subscribed.

AnthonyMouse 9y ago

> I have a 500mbit/sec wan link. Unless I'm careful I can lose packets with a stream running at 100mbit (send at 1gbit for 100ms, 0mbit for 900ms - see this with iperf3 for example) Sending at gigabit for 100ms implies a 12.5MB buffer. A lot of routers sensibly won't (or just can't) buffer that much data, so sending in such large bursts is a good way to get your packets dropped. Which is why sensible programs (and the TCP stacks in major operating systems) don't do that. Instead they'll either use a smaller time slice or use the event-based TCP "ACK clock" where packets are sent in response to receiving acknowledgements of previous packets, which spreads the transmissions more uniformly. Moreover, notice that the thing you're describing still shouldn't happen within an ISP's network, because it's caused by an individual stream sending faster than the path bandwidth. That can happen when you go from 1Gbps LAN to <1Gbps WAN, which is why QoS can be helpful on the customer's edge router, but that isn't part of the ISP's network. It shouldn't happen when you go from a 500Mbps customer link to an unsaturated 40Gbps peering link. The 500Mbps link can't saturate the 40Gbps link, and if some combination of them do, it's not because of the sending pattern, it's because the uplink is too over-subscribed.